ericvhileman · June 18, 2019 01:34
diff --git a/gistfile1.txt b/gistfile1.txt
 @foomanNZ
 34m34 minutes ago
 I am pleased to see that Magento took the initiative and has been working on a unified standard that can be used across the entire Magento ecosystem. http://bit.ly/31B4FgL  #CodingStandards
 	
 @SergiiShymko
 I would not count Cloud as a separate version. It’s rather an infrastructure that hosts Commerce version. All parts of the environment are known: Fastly/Varnish, CDN, Redis cache & sessions, etc.‏
 	
 @IsaiahBollinger
 My concern is more around how big the upgrade changes are in terms of number of files and features added for Magento. Also there are now 3 versions of Magento, Open Source, Commerce, and Cloud so its more work for module vendors to keep up with compatibility.‏
 	
 @SergiiShymko
 Agreed, that would be the design limitation. I was more praising the flexibility of Tax Classes and ability to control taxation of Goods vs Shipping vs Tax Free.
 	
 @SergiiShymko
 The difficulty of upgrades is faily constant. The complexity is in direct relation to the amount of changes/improvements/features shipped. Some versions ship more, some less. I’d recommend more frequent upgrades to keep the change set small. Private visibility causes copy-paste.‏
 	
 @IsaiahBollinger
 Do you think Magento 2 will become harder and harder to maintain in terms of cost? We have seen some expensive upgrades but also some that have been fairly easy. I guess it all depends on how custom the site is and how many modules are used?‏
 	
 @SergiiShymko
 We have a custom #magento2 product type based on bundle. Upgrading from 2.2.x to 2.3.x forced to copy-paste ~650 lines of code (mostly SQL queries) from core indexer class because all visibility changed from protected to private. Please stop the "everything private" initiative!
 	
 @_Talesh
 Ha ha I was planning on doing the same this evening.
 	
 @piotrekkaminski
 is this the only way to read this thread? (using Treeverse)
 	
 @thescottsb
 We upgraded a store from 2.3.0 to 2.3.1 late in the build stage (was released just before we were ready to launch). As I recall it worked without any regressions (probably first one like that).
 	
 @dazzo716
 Look who has the second comment on there. This is actually what set me off on this entire tangent. I am obviously not alone, this comment was posted two days ago:‏
 	
 @JohnHughes1984
 No, but utilising semver to stop non security updates in same release that have major ‘knock on’ effects would help
 We’ve yet to have a security specific fix cause us/our merchants any major issues, the issues are always with the non security based code changes in our experience‏
 	
 @_Talesh
 I think the consistency of effort required for security patches largely depends on the content and vulnerabilities found that need to be patched. Semver wouldn't fix an architectural problem that required a modification to how popular extensions interact with Magento.‏
 	
 @JohnHughes1984
 It was on the same release cadence as 2.2.7-2.2.8 and for us that one was a particular challenge for all our merchants on that version
 	
 @JohnHughes1984
 But you only have to look at the sheer quantity of change between versions to get an idea of the challenge to get 2.3.0-2.3.1 upgraded / tested / deployed without at least some conflict (https://devdocs.magento.com/guides/v2.3/release-notes/ReleaseNotes2.3.1OpenSource.html …)‏
 	
 @JohnHughes1984
 I can’t imagine there will have been a great deal of sites taking this path. Most (agencies at least) would wait until 2.x.1 before considering upgrade to the next major version for any new issues with the initial .0 release to be ironed out‏
 	
 @JohnHughes1984
 In terms of upgrade paths though, do we have any feedback on merchants that have gone from 2.3.0 to 2.3.1? I don’t have any data on this
 	
 @JohnHughes1984
 I’m not saying semver is the definitive answer or some silver bullet, but it seems many are unhappy with the amount of effort it takes to apply the current quarterly releases

 The question around 2.3 and stability, again for me, is a different topic to upgradeability‏
 	
 @JohnHughes1984
 Good example from 2.2.8 was the backporting of changes for how emails are sent that was originally made in 2.3.0 that then broke a third party SMTP module (https://github.com/mageplaza/magento-2-smtp/issues/149 …)‏
 	
 @_Talesh Talesh Seeparsan Retweeted John Hughes  🔜 #MM19UK
 Are you a merchant and did you upgrade from #Magento 2.3.0 ➡️ 2.3.1? Comment or DM (mine are open)
 We have questions to help shape the future of Magento security...Talesh Seeparsan added,
 	
 @JohnHughes1984
 In terms of upgrade paths though, do we have any feedback on merchan…
 	
 @_Talesh
 Talesh Seeparsan Retweeted Magento's past with semver has been... errr... a little storied. I'm linking in my tweet so you can see where we've come from. Do you think the instability of the last few years will keep going forward? 2.3 has had a lot of praise.Talesh Seeparsan added,
 	
 @_Talesh
 There are old reasons why Magento is doing this the way they are now. That doesn't mean it can change going forward.
 https://alankent.me/2014/07/12/magento-2-product-and-composer-version-numbering/ …
 	
 @_Talesh
 I am 100% sure this is not going to be forced on every install. Making SIs immediately tear it out would be tone deaf in a tragic way.
 	
 @JohnHughes1984
 The problem is the lack of true modularity in M2 and the fact every quarterly release we’ve had over the past couple of years has contained major breaking changes. 
 If we can fix the modularity & use semver (or similar principle) we wouldn’t have these issues in the first place.‏
 	
 @JohnHughes1984
 Agreed, but that is adding new functionality in a non backwards compatibility breaking manor and all the GraphQL code is in sepearate modules which you can disable if you don’t need them‏
 	
 @foomanNZ
 Fully agreed. We just need to ensure that we don't lose the ability to progress things like GraphQL coverage quickly.
 	
 @JohnHughes1984
 Keeping the quarterly releases to just security and if absolutely necessary important bug fixes would solve a lot of these issues and not require a fourth point version if new features are released like the above examples and existing features are modified only in 2.x.0 versions‏
 	
 @JohnHughes1984
 Both Google Shopoing Ads Channel & Amazon Sales were released by Magento as core offerings just before Imagine. These are new ‘1st party’ features yet are separate extensions that have to be installed by choice. Minimising upgrade impact does not mean limiting new feature release‏
 	
 @JohnHughes1984
 If we can limit substantial change to existing functional in patch (2.x.x) releases and keep them back for 2.x.0 releases then it’ll make things much smoother. Equally new features have just been released by Magento that have no impact on upgradeability / security... 
 	
 @JohnHughes1984
 Depends on what’s in a feature release. If it’s a new feature that has minimal to no impact on existing code (or can be disabled) then it’s no problem. If it’s an substantial change to existing code then it makes upgrades harder (e.g. wish list changes in 2.2.7 come to mind) 
 	
 @foomanNZ
 If the outcome of this is a recalibration of what goes into each release that would be a win too. One feature release per year is probably not enough though. So either which way one slices it one will end up with more releases to be supported.‏
 	
 @blackbooker
 To be entirely honest with ourselves, would we keep having this problem if Magento actually kept the patch (2.2.x) releases to bug fixes / security patches instead of adding features? Probably not. This is the end result of not wanting to be supporting so many 2.x lines at once.‏
 	
 @blackbooker
 Wholeheartedly agree, there are real issues needing to be solved. But when I hear the words “auto” and “like WP” it scares the heck out of me. What needs to be improved IMO is the release lines and versioning, after which patching/updating becomes far less overhead for everyone.‏
 	
 @DarrylAdie
 Yes, although as per previous tweet, on a balance I think the current release process is a little better this way. Just sometimes delays patching process slightly.
 	
 @foomanNZ
 I think these are all real issues to solve but I am confident any efforts spent on this will be beneficial. It will allow to push out security updates a lot quicker than today even if not automated all the way through to production.‏
 	
 @blackbooker
 Please tell me when this comes out so I can rip it out. Magento is not WP and shouldn’t be auto-updating from the application itself IMO. Would be helpful perhaps for some of the S in the SMB market, but anything bigger than a single-server setup or where compliance requires 1/2‏
 	
 @_Talesh
 So I understand you clearly, the problem you're facing is only occurs when security releases are also wrapped with significant core changes?‏
 	
 @DarrylAdie
 I agree but we almost never waited on third party module vendors to resolve items before pressing ahead. For us the issue is the “transaction cost” of a release (QA, deploy, monitor) not the dev time to unpick issues. Plus you always end up doing the feature release later!
 	
 @DarrylAdie
 When releases were “security only” we worked on the basis of urgency. No customer ever tells you to stand down when it’s relatively simple and security focused. The issue is when it is both significant “core changes” and security, more governance is needed.‏
 	
 @DarrylAdie
 Frequency can be planned if consistent. The issue was that security patches (often rightly) were more often than not released “off schedule”. Cadence is more predictable now.
 	
 @_Talesh
 I really think when we build this we need to stratify/identify the merchant/agency audience and try to ensure we're not making life more difficult for any of them.‏
 	
 @_Talesh
 I think in general, having less changes in a security patch reduces it's complexity and allows you to spend less time in the incompatibilities/bugs sub-cycle.
 ‏	
 @_Talesh
 I do not think trying to build something for "every Magento upgrade" is feasible. 
 CLI help for developers + easy patching for smaller clients (the ones getting hacked anyway) may be the best start.
 	
 @barryvdh
 Well hopefully it would be like - 'update, test, deploy' instead of 'update, test, find incompatibilities/bugs, wait for vendor updates/schedule more work to fix it, repeat until fixed and then deploy'.. 
 	
 @_Talesh
 The frequency is a problem? Magento is dropping updates monthly at best, I think that is something that can be planned for.
 	
 @_Talesh
 Do you think that process is something you'd do differently if you had security patches separate from releases from the beginning?
 	
 @_Talesh
 Yeah I think we're past the point that potential hackers are slowed much by rolled up releases.
 	
 @_Talesh
 I think it's been mentioned elsewhere sometimes security mitigations involve architectural changes or changes to functionality that lots of extensions expect.
 	
 @barryvdh
 Yeah that was the point, I'm all in favor of security-updates only.
 	
 @_Talesh
 I want to participate in the convo. Just dealing with food poisoning and a fever rn. El the ideas are excellent!
 	
 @lukerodgers90
 All in all I'm not convinced the proposed tool would be a one and done for every Magento upgrade, but I'd love to be proved wrong on this.
 If this tool for auto applying patches was released as a CLI that would help speed things up further for many developers.‏
 	
 @lukerodgers90
 Improvements to the CI pipeline alongside our tool for detecting overrides (templates/XML/preference/plugins) seem to be helping speed up things through to QA and then to prod.
 	
 @lukerodgers90
 In that case the inability to properly manage promotions would have been a huge issue for the client. There's been a few things like this which is why we like to spin them through QA and why we're increasing test coverage (phpunit, codeception) and static analysis with phpstan.‏
 	
 @lukerodgers90
 I'd have to go through Jira to find examples. I do recall a while back when EE changed how to_date and from_date worked with cart rules and moved the logic into staging modules. This did not play well with a 3rd party promotion module and was a pain to fix. Was only caught by QA‏
 	
 @lukerodgers90
 I think I've caught up on all the above 🙃 an auto patcher that dealt with only security changes sounds neat, but with every Magento release other things are bundled in. It's often those that cause pains with third party modules and overrides‏
 	
 @nuzil
 Definitely important topic, if I can help somehow - let me know.
 ‏	
 @beejhuff
 Count me in also!
 	
 @tutnix
 Heard that figure also but also indications that medium is 1m to 100m. Quite a large scale it looks like. But nevertheless, the option alone is great for smaller merchants or some with not so dedicated maintainers.
 	
 @maxpchadwick
 Probably yes the actual fix may have been only a few lines. Just wanted to add this to the discussion that fixes arent always just adding validation / sanitization, but can also be at this level‏
 	
 @DarrylAdie
 Just in case you folks haven’t seen this already, we’ve made this available to the community already.
 	
 @SergiiShymko
 I kind of agree. It's a shoplift patch, isn't it? Yeah, the fix was to slightly change the class structure of admin controllers to prohibit their execution. Still was a change in ~5 files if I'm not mistaken. Easy to test: admin must open :)‏
 	
 @SergiiShymko
 Software security vulnerabilities are not discovered, but rather invented. Exploit is a malicious payload that abuses edge cases of technologies that do not manifest themselves in any reasonable scenarios the system was designed for.
 	
 @maxpchadwick
 There are some vulns that exist at an architectural level that lead to massive breakage. Admin routing changes on SUPEE-6788 is first that comes to mind‏
 	
 @DarrylAdie
 For a better answer, I would have to defer to @lukerodgers90 who does a lot of work with @MagentoEngCom on security and manages releases through to production for @AmpersandHQ customers.
 	
 @DarrylAdie
 Agree to the extent I can but we are straying into your nuanced view of the reality and my perception of the feedback I get from the @AmpersandHQ team. For our implementations, which I accept are much more complex than the norm, we have issues and we are super cautious on QA.
 ‏	
 @SergiiShymko
 Security vulnerabilities exploit extreme edge cases of technologies by sending malicious data that the system never ever would receive in any reasonable scenario. Examples: SQL injection - SQL in query string; ../../path in URL. Security fixes patch handling of those edge cases.
 	
 @DarrylAdie
 I meant in a generalised sense, eg. changes to a component with coverage in an “external” API, used by another system. Not internal dependencies/DI etc.
 	
 @DarrylAdie
 Mostly agree. However, we also frequently ended up with blocked promotion pipelines because of the frequency of the security updates. Having more predictable product release schedules (ignoring very significant sec issues) is a big help for planning.‏
 	
 @SergiiShymko
 I personally have not seen a Magento security fix that would require changing any dependencies. Could you please provide an example?
 ‏	
 @DarrylAdie
 That’s fair for many if you look at “tiny” in a code sense but not always tiny when you look at the number of dependent or derivative components. As such, testing is not tiny.‏
 	
 @DarrylAdie
 That being said, it is a little harder for us to unilaterally cycle through security updates where they are part of a 2.x release, as they generally require more consultation with the customer to get them scheduled.‏
 	
 @SergiiShymko
 From my experience absolutely all security fixes are 1-2 line changes in a single file of in a few files at most.‏
 	
 @barryvdh
 Well as an agency you would need to roll out a lot of shops quickly. I don't care for features directly, so security first and then focus on the 'bigger' release. You would have to update the latest version, so just 2.2.7.1 en 2.2.8.1, never 2.2.8.2. just to hotfix fast and safe‏
 	
 @dazzo716
 Security through obscurity rarely works. Chances are that any of these groups are equipped enough to still extract the changes out of a normal point release.‏
 	
 @SergiiShymko
 I think another reason against factoring out pure security releases is dangerous exposure of vulnerable area to potential attackers.
 	
 @DarrylAdie
 It also, to @piotrekkaminski’s point around support, reduces the number of different derivative versions that we have to simultaneously support and understand.
 ‏	
 @dazzo716
 Exactly
 	
 @DarrylAdie
 I would prefer if they were tiny but I don’t think it would be fair to characterise all of them as such. For us, there is a minimum level of testing required on any release and that “transaction cost” of a release is one of the reasons I “prefer” rolling up security and features.
 ‏	
 @SergiiShymko
 Security fixes are expected to be tiny  changes that maintain backward compatibility. Such releases would require minimal testing. It would be also feasible to review the changes to narrow down the testing surface.
 ‏	
 @DarrylAdie
 It’s a trade-off though, right? Decision between doing two cycles of Dev, QA and release (.2.2.7.1 and then .2.8) or one.‏
 	
 @DarrylAdie
 I was against the rolling up of feature releases and patches initially. However, I’d be very reluctant to go back now.
 	
 @dazzo716
 Took me weeks to patch to 2.2.8. Fortunately I was able to mitigate the issues server side.
 	
 @dazzo716
 	
 @dazzo716
 I’d like to see composer based point releases. Not individual patches.
 	
 @JohnHughes1984
 ..., Number of files changed in a ‘security’ release 😉
 	
 @JohnHughes1984
 But it’s equally a nightmare for merchants to stay secure because of not having security only patch releases.
 This might be a bit blunt, but what’s more important to #Magento / #Adobe, committing to the security of merchants or making internal process/support less hassle 🤷‍
 	
 @piotrekkaminski
 Correct. We really don't want to get back to releasing patches unless necessary as it leads to franken-installations, with some patches applied, some not, so new patches conflict and it's a nightmare to support.
 	
 @JohnHughes1984
 That’s like a reverse Turing test, use such ridiculous language that even a computer doesn’t recognise it as human readable language 😂‏
 	
 @foomanNZ
 MT @ericvhileman Had a great calls today with @StevenZurek from @adobe and @_Talesh about building an auto-patcher for M2 security updates (similar to WP).  We would potentially work with @MagentoEngCom and in future into the core.  Please like / retweet if you want this.
 	
 @tutnix
 Really depends on the definitions. Small I agree but what is medium...‏
 	
 @tutnix
 Especially for the ones that are notorious underpatched: smaller merchants without budget for maintenance
 	
 @willwright1
 Your cron module should definitely be core in my opinion
 	
 @piotrekkaminski
 next step: install @Snapchat , the ultimate in confusing UI for anyone over 18
 	
 @DavidLambauer
 Automate Code changes can't be nice can they? 🤔 Looking forward to see implementation details😜
 ‏	
 @DavidLambauer
 Enterprise won't go with a monolith either. M2 is complex but What it keeps alive is the feature set...
 Miguel Balparda
 ‏	
 @mbalparda
 PRs are welcome to the repo, no need to start from scratch or do a separated module like the great cronjob stuff you did that never made it into the core. 	
 @IvanChepurnyi
 Technically possible to implement too. Also by using PHP Parser it is possible to statically analyze places in core where the behavior was customized. As well as simple solution with creating mirrored vendor directory symlinking it to test the patch and doing fast revert.
 ‏	
 @IvanChepurnyi
 As m2 code base is already in composer applying patches as post install hook should be easy, adding a plugin to composer that also ignore patches when you upgrade to release with that patch would be nice too‏
 ‏	
 @_Talesh
 It's my fault for not calling it out then. I was gripped with terrible imposter syndrome at the time.
 Piotr Kaminski
 ‏	
 @piotrekkaminski
 The quality fixes included a lot of customer issues reported via support. A big problem in M1 was that often only the reporting customer got a patch for a given issue. With M2, everyone benefits.
 Piotr Kaminski
 ‏	
 @piotrekkaminski
 Any tool that auto-patches, would have to check for existence of all previous patches being installed (or install them) to avoid this. But we also want people to get access to the quality fixes we release.
 ‏	
 @piotrekkaminski
 Correct. We really don't want to get back to releasing patches unless necessary as it leads to franken-installations, with some patches applied, some not, so new patches conflict and it's a nightmare to support.
 	
 @piotrekkaminski
 i think a reasonable requirement for start would be to:
 - work in like 80% of the cases
 - fail safely (revert or not install if any issues are detected)
 - be loud (detailed output) and specific (clear error messages)
 - provide a dry-run/check option (there is value in only this)
 	
 @kassner
 In the end, as the name suggests, we are just patching broken process, instead of fixing the core issue.
 I'm not putting you off, but rather shinning light at Magento, which should be the one driving this avidly (or enabling community to do so). 
 	
 @Fabian_ikono
 I’m sure there are use cases. But if you want to sell books, shoes or electronics, there is no need for it :)
 I have them too and they are super happy with Magento. But they could saved a lot of money if they didn’t go the complex road.‏
 	
 @CiPHPerCoder
 We did some work for Magento before the Adobe acquisition and would absolutely love to work with them to get secure auto-updates in the next version of M2.
 	
 @Fabian_ikono
 I think the complexity of M2 is too high for SMB. There are far better options. Why fight with that, if you can have an easy start with #Woocommerce, #shopify or #shopware.
 Imho Magento was always for complex project, never for SMB. For M1 it was a lie/wrong for M2 it is as well.
 	
 @_Talesh
 Talesh Seeparsan Retweeted Some history on why it is how it is now:Talesh Seeparsan added,
 	
 @_Talesh
 There are old reasons why Magento is doing this the way they are now. That doesn't mean it can change going forward.
 https://alankent.me/2014/07/12/magento-2-product-and-composer-version-numbering/ …
 ‏	
 @_Talesh
 I don't think this isn't going to make up for Magento complexity, but I have SMB clients that want Magento for specific reasons. This just makes life easier for them.‏
 	
 @_Talesh
 Maybe one less reason to flee? 
 	
 @_Talesh
 No worries, no one has all the answers and the first shot of this isn't going to be perfect for all work flows but it does ease problems where it's really needed and moves big M towards a neater patch process.
 ‏	
 @_Talesh
 There are old reasons why Magento is doing this the way they are now. That doesn't mean it can change going forward.
 https://alankent.me/2014/07/12/magento-2-product-and-composer-version-numbering/ …
 https://alankent.me/2015/10/02/magento-2-version-numbering-update/ …‏
 	
 @_Talesh
 Ha ha, yep. @CiPHPerCoder helped Wordpress get encrypted updates done properly and we'll be analyzing what they did and learning from that.
 ‏	
 @Blue_Bovine
 Ah heck yeah!  @piotrekkaminski and I had discussed this several years ago and id’d several work items.  He’s have more insight if those items got into production.
 	
 @ryanhoerr
 I guess that could just be part of the process, 'hey there's a new patch, make sure to update and deploy with the new packages!', but that doesn't seem different in substance from what composer updates already give us.‏
 	
 @ryanhoerr
 ece-tools is good but I don't think a good general auto-patching solution, at least as it works today.
 You run it at build time, but if a site doesn't do that regularly (or keeps their ece-tools version locked), they're not going to get patches in a timely manner.‏
 	
 @psolovyov
 That will be probably the best thing Magento can do to persuade M1 merchants to move over.
 	
 @mattz_mg
 In addition, eco-tools has a mechanism for auto patching a small set of fixes.  
 Outside of creating a security only oriented patch, we have ideas around application of patching and reporting on incompatibilities (upgrade tester) are other ideas we are pursuing.
 	
 @mattz_mg
 We do have a set of ideas around releasing security fixes on 4th digit versioning (2.3.2.x), and are working through the complexity of the packaging, testing, and release process.
 I hope to have an update on this to share in the next few weeks.  @ChrisHedge4 @piotrekkaminski
 	
 @mbalparda
 A lot. Right now I'm reviewing an article that says 189k but I still have to ask for the source of that number.
 ‏	
 @mbalparda
 Most of this is already coded in ece-tools and there's been a discussion in the #cloud channel on slack to make some of the features usable outside Magento cloud. Didn't @stevenzurek or @MagentoEngCom mention that?
 ‏	
 @fschmengler
 that needs to be changed and it's why getting Magento @MagentoEngCom behind the project would be a smart move‏
 	
 @mrloo
 I don’t think the M2 security release cycle will work for this. There’s too many breaking changes and bugs in the security releases because they’re not isolated from the feature updates and bug fixes.
 	
 @barryvdh
 Before you can auto-patch security updates, there first need to be security patches, instead of new feature releases with security patches included.. So why no 2.2.8.1 with just security patches, without breaking and give some time to fully update to 2.2.9 later?‏
 	
 @kassner
 Fixing security from inside gives them a new selling point that several rivals are missing nowadays.
 But this doesn't matter for this discussion. I just wanted to vent out a bit /end‏
 	
 @kassner
 We only discussed security here, but big M should see bit commercial incentive to do so. Enabling their paid customers for a very short time to market is something that would sell very well in my current demographic (2.3.2 is taking ages and this hurts M's image as slow paced) 
 	
 @Flyingmana
 Just make sure to use proper signature validation, so it does not backfire 😅
 But absolutely yes, thats very usefull‏
 	
 @hd_ng
 yes please. This would be especially helpful for teams who don't have the resource to cope with the maintenance that comes with security patching.
 Tom Harding
 ‏	
 @Fabian_ikono
 My experience with M2 is low. But the complaints about broken backwards compatibility is loud. As long as @magento doesn’t care about that (and wordpress is all about b compatibility) this breaks a lot.
 I want code in git. This is for SMB and they flee m2 due to complexity
 	
 @dx3webs
 This would be a serious step in the right direction
 	
 @kassner
 A bit hard to point specifics because most of the release process is a black box. Making this box transparent as much as possible is definitely the first step.
 	
 @SimonSprankel
 Really mixed feelings here. Need to get merchants updated somehow: yes, definitely. Not knowing what code really runs on the live server for an ecommerce business: no, please not. Not having all code changes in the VCS: no.‏
 	
 @kassner
 I see this as something that Magento should provide, as community has no way to influence their release/distribution process. They already have the infrastructure to do so, if they see value in it, they should give their infrastructure for that, not just their support (1/2)‏
 	
 @kassner
 Infrastructure I meant: You can install marketplace modules without running a composer command, and you are already tied to Magento via composer auth creds. New component releases go there, UI notifies admin to install, just like a regular 3rd party module (2/2) 
 	
 @kassner
 AFAIK, community can't drive that, regardless of how much effort we provide.
 ‏	
 @_Talesh
 I am guessing this is why @ericvhileman started discussions with @StevenZurek and not me. He works for Adobe.
 ‏	
 @kassner
 I would rather invest this time in fixing the release process, to be able to put a new release out of the door in a matter of minutes
 Or better, release new versions of individual components. Also makes people run composer update more often. Win for everyone.
 ‏	
 @kassner
 IMHO, "code released must be tagged". Any other variation of that is regression.
 So if big M fixes or not the release process or not after a tool like this doesn't matter, as long as we have untagged code running around, we will be in pain. 
 	
 @_Talesh
 I agree with that but the problem with patching stores doesn't lie with you nor anyone who agrees with you. This solution is for those who don't have those processes in place. 
 You just benefit from having tighter security releases and an autopatcher for your dev/qa instance.
 ‏	
 @_Talesh
 There are a million scenarios where it wouldn't work well, however, the few very very good scenarios where it will be useful is probably more important than them all.

 For all of those scenarios it wouldn't work, I think a practical default and optional off switch is a good idea. 	
 @_Talesh
 Think of it in reverse. 
 If such a tool exists, do you think Big M would have an excuse to not change the release process? 
 	
 @VinaiKopp
 That’s a project worth investing time and effort in!
 ‏	
 @_Talesh
 We definitely need to hit up Scott to learn from his experience pushing this through properly with Wordpress.‏
 	
 @tutnix
 If somehow you can get an insight in breaking changes, not only core but with installed modules, and ensure it will be working afterwards this sounds like a great idea. Hard move if you use some kind of autoscaling as containers would need fixing too?
 ‏	
 @andrewhowdencom
 Cc @mannersd, @CiPHPerCoder‏
 	
 @web_martin
 Hell yes. Thanks.
 ‏	
 @_Talesh
 Talesh Seeparsan Retweeted We had a long discussion about the nuances of it here. This shouldn't be a forced solution nor should it be on/off. 
 What if for someone like you it reduced your time to test new patches on your dev env before deploy?Talesh Seeparsan added,
 	
 @_Talesh
 Tell us #Magento community: Would you be interested in a secure, pragmatically built auto-patcher for M2 #security patches?
 We can make this happen. Reply to @ericvhileman's original tweet. …‏
 	
 @_Talesh
 Jun 13 Talesh Seeparsan Retweeted Ok I'm about to dip. 
 	
 @_Talesh
 Tell us #Magento community: Would you be interested in a secure, pragmatically built auto-patcher for M2 #security patches?
 We can make this happen. Reply to @ericvhileman's original tweet. …Reply   Retweet   Liked 1   Direct message
 	
 @KernelCall
 Yes, please... thank you and thank you!
 ‏	
 @_Talesh
 For now that would be the best place. 
 Once we start getting deeper into the woods probably an association should managing the liability question etc... 
 P.S. There is already RHISAC but it's hard to talk to them without a room full of lawyers.
 ‏	
 @_Talesh
 ISAC: https://en.wikipedia.org/wiki/Information_Sharing_and_Analysis_Center …
 ‏	
 @_Talesh
 It should be, with sensible defaults out of the box
 Like @philwinkle said, it is possible in most cases to be aware of what may break, and flag conflicting extensions and not patch if we are sure it will break.
 ‏	
 @_Talesh
 This is why I described it as pragmatic. There is not going to be Microsoft style updater taking your site down on Black Friday to auto-patch it. That's horrid UX.
 ‏	
 @psolovyov
 That would be dope. I was thinking to export my block list and just post it so people could use it. But this would be better. Sort of like a security center or something like that. 
 	
 @maxpchadwick
 Absolutely. I also think we'll see attackers get better and better at reversing the patches even without a PoC‏
 	
 @_Talesh
 That's because we're building bigger and better stores for fatter targets.
 ‏	
 @_Talesh
 I've been talking to the @magentoassoc members about spearheading an ISAC for this sort of disclosure.
 ‏	
 @_Talesh
 Ha ha I just tweeted a cruder version of that same thing.
 ‏	
 @psolovyov
 I like when I go through my logs I can block IPs on all of the sites I have under Cloudflare at the same time. That saves a ton of time and helps protect my other sites from the same hackers.
 ‏	
 @_Talesh
 ... or bake sensible defaults of a scaled system into it. .
 .
 ..
 .
 	
 @psolovyov
 Maybe also having a centralized firewall? So when one of the stores sees attempts from IP addresses it uploads those IP's to centralized place and spreads the IP block list to thousands of other stores so they are not affected? 	
 @maxpchadwick
 I like that idea. Maybe there are three options for the auto patchers:

 - Enable (All Fixes)
 - Enable (Critical Only)
 - Disable

 Oh, and lets don't use the broke CVSSv3 score to define critical‏
 	
 @maxpchadwick
 Agreed. Magento would need a security patch only strategy. One click install of an upgrade is infeasible. And even with patch only I'm really not sure how feasible this is for Magento...
 ‏	
 @maxpchadwick
 It's true, but to me it's not about preparing for what most of the vulns are, it's about having your store patched immediately when "MagentoGeddon" drops (it's inevitable someone will find another one)
 ‏	
 @maxpchadwick
 Max Chadwick Retweeted Eric Hileman	
 @ericvhileman beat me to pointing this link outMax Chadwick added,
 Eric Hileman
 	
 @ericvhileman
 https://sansec.io/labs/2019/05/10/magento-2-hacks/ …
 ‏	
 @_Talesh
 I think if something like this exists, conservatively, you'll have to manually patch 50% of your sites instead of 100%. That's a value proposition that makes a lot of sense.‏
 	
 @maxpchadwick
 I agree it should exist. Whether or not to use it is the merchants decision. You're balancing risks:
 Do auto-patch: site might randomly break
 Don't auto-patch: site will be unpatched for longer
 ‏	
 @maxpchadwick
 If you ask me you're better off having your site maybe break (which you can fix) than having your site unpatched longer (meaning you'll maybe get hacked which is very permanent damage), but again it's a judgement call for the merchant
 	
 @psolovyov
 I agree - security patches are more important. I see some stores still unpatched even with big teams working for them - this shouldn't be the case.
 Fooman
 	
 @foomanNZ
 I think it's time we gave auto patching a try. Once we start, we can improve upon it. The current manual approach has been tried for a while and I don't think it's working well enough.
 ‏	
 @_Talesh
 Goddamn I keep replying to this thread and it's always too late for someone else to jump in. 
 Summary: @philwinkle is right, the onus is on us to try, chicken/egg 
 	
 @psolovyov
 Yes, all this patching stuff should really be just applied by one button click. I realize it's not as simple, but I'm sure M2 already matured enough not to have simple vulnerabilities in it like M1 had.‏
 	
 @_Talesh
 In some ways, it'll be offering a big fat carrot instead of stick for smaller merchants and if big M can smoothen the barrier to entry a bit more...
 	
 @_Talesh
 Jun 13 Talesh Seeparsan Retweeted Fooman
 Well if @foomanNZ is getting behind it...Talesh Seeparsan added,
 	
 @foomanNZ
 Yes please. WP has been doing this for years. We have to get better at getting people upgraded. cc @mattz_mg‏
 	
 @_Talesh
 Jun 13 Talesh Seeparsan Retweeted Eric Hileman
 Tell us #Magento community: Would you be interested in a secure, pragmatically built auto-patcher for M2 #security patches?
 We can make this happen. Reply to @ericvhileman's original tweet.Talesh Seeparsan added,
 	
 @ericvhileman
 Had a great calls today with @StevenZurek from @adobe and @_Talesh about building an auto-patcher for M2 security updates (similar to WP).  We would potentially work with @MagentoEngCom and in future into the core.  Please like / retweet if you want this.  Comment if you'd help.
No results found