cancel
Showing results for 
Search instead for 
Did you mean: 

Introducing the New Security-only Patch Release

Adobe Team

With just under 50% of digital merchants reporting some kind of security breach, and online fraud growing at a faster rate than online sales, security is more important now than ever before. Gartner reports that by 2020 companies that are digitally trustworthy will generate 20% more online sales than those that are not.

 

Our model for delivering open and customizable software introduces a particular challenge. ZDNet found that 83.1% of Magento Commerce and Magento Open-source sites that reported hacks were running on outdated versions. While we emphasize security in every release, it is imperative that merchants keep their stores current to leverage those enhancements.

 

With these statistics and trends in mind, 2019 has been our year of security. Our engineers have been hard at work for the last 8 months making Magento Commerce 2 more secure by reducing our security issue backlog by over 93%. In Q2, we shipped 139 security fixes across all active Magento Commerce and Magento Open-source versions. In our upcoming Q3 release we'll ship a record number of 157 fixes! We’ve doubled our prior year’s investment in security and are changing our approach to security work by making broader strategic changes that improve M2 security posture across the board. We have a roadmap for more of these changes in 2020 as we continue our increased investment in security.

 

But wait, there's more! We listened to you at Magento Live, Imagine, and other events, and now we're making it easier to pick up security fixes. In Q3 we'll be shipping a security-only patch release for Magento Commerce and Open-source 2.3.2. The release will be called "2.3.2-p1". It will give you the option to get just the security fixes you need for Black Friday, but delay the less time-sensitive quality, performance, and other changes until later.

 

You might have noticed the unusual naming scheme for the security-only patch release, especially since it’s being released next to the 2.3.3 release. That's because the security-only patch will be based on the latest prior full patch release on our most recent release line to give you a possible upgrade path like this:

 

sec patch paths.png

 

This flexible scheme gives you the familiar continuous path to functional and security fixes, or the option to take a lighter security-only patch release when you need to, which lets you remain secure for as long as six months before picking up a full release.

 

Here are a few examples to help illustrate your options:

Example 1 – A full upgrade:

  • In Q3’19, you upgrade your 2.3.2 instance to 2.3.3.
  • In Q1’20, you can upgrade your 2.3.3 instance to 2.3.4.

 

Example 2 – Security now, full service later:

  • In Q3’19, you upgrade your 2.3.2 instance to 2.3.2-p1.
  • In Q1’20, you can upgrade your 2.3.2-p1 instance to 2.3.4.

 

Example 3 – Security now, then the functional change you really need:

  • In Q3’19, you upgrade your 2.3.2 instance to 2.3.2-p1.
  • Between Q3’19 and Q1’20, you upgrade your 2.3.2-p1 instance to 2.3.3 to get access to the quality updates.
  • In Q1’20, you upgrade your 2.3.3. instance to either 2.3.4 or 2.3.3-p1, depending on the complexity of the upgrade you want to take on.*

 

Example 4 – Security-only update to security-only update:

  • In Q3’19, you upgrade your 2.3.2 instance to 2.3.2-p1.
  • In Q1’20, you can upgrade your 2.3.2-p1 instance to 2.3.3-p1.**

 

Enough chit-chat! How can you get your hands on this security-only patch? We will release it in late September to our technology partners and Commerce customers as a Composer package. 

 

 

We're committed to making our commerce products the most robust and secure choice out there, so give us your feedback. Let us know how we're doing and what you'd like to see more of.

 

 

*Note that you would be taking on an additional upgrade during this span.

 

**Note that we will do its best to support security patch release to security patch release configurations, but we will not fully validate this upgrade path as part of our patch release process.

19 Comments
Core Contributor

Very good job!

 

Next step would be to release a 2.3.2-p2 when 2.3.3-p1 gets released, a 2.3.2-p3 and 2.3.3-p2 when 2.3.4-p1 gets released, and so forth...

I understand this will take some even bigger effort from your side and won't be for the first few months, but going in that direction would be awesome.

So we can just stick with one version and still get the benefits from security fixes, so we don't have to spend ridiculous amounts of time and money on upgrading to a new "quality release".

 

I assume if Magento won't do this themselves, there will be some kind of community effort in backporting security fixes to older versions, as long we can easily seperate them from the "quality updates" it would probably be quite "simple" to do.

 

Thanks again, good job!

Senior Member

Will we be able to work this into CI/CD? Where when a patch is released a feed would be updated and can trigger our CI/CD to dry run the patch to confirm a positive result and then deploy it to production? Thanks!

New Contributor

Great decision made by Magento - The upgrade always takes atleast a month or two (depending on customization on instance or third parties' compatibility for new Magento version) and during that period, the stores are exposed and open to vulnerabilities. 

 

If we say uncompromised service, Security comes first! and if we really mean security as priority-1, the fixes of security must be INDEPENDENT and AVAILABLE handy regardless of major upgrades or dependencies of third parties. 

New Contributor
Brilliant. Fantastic Job guys!
Senior Member

Looking forward to quicker security upgrades!

New Contributor

Very complex shopping cart compared to others that's a lot of upgrades and expense for merchants.

Senior Member

Where can I find M2.3.2-p1 security patch?

Senior Member

Composer patch for existing 2.3.2 installations (resource):

 

Security patches contain security fixes only. They are designed to make the upgrade process faster and easier.

Security patches use the Composer naming convention 2.3.2-px. Use Composer to specify a patch. For example, to download the Magento Commerce 2.3.2-p1 metapackage:

 

composer require magento/product-community-edition=2.3.2-p1 --no-update
New Contributor

I need to understand this new Magento 2 patches.

So I see that security patches are released as 2.3.3-p1.

Let's say my version is Magento 2.3.2. And Magento has released 2.3.2-p1, 2.3.3-p1, 2.3.4-p1, 2.3.5-p1 so far. Is that mean I need to apply only one patch ie. 2.3.2-p1 or all of these?

M1 Certified

As @patrick_sullivan shown in this diagram

 

sec patch paths.png

 

If you are running 2.3.2 then you can apply 2.3.2-p1 and 2.3.2-p2 and this only going to add security related fixes but this will not contain any functional update or fixes for some functionalities that are not working as expected in 2.3.2

 

To see list of releases and release notes about each one of them checkout here

https://github.com/magento/magento2/releases

https://devdocs.magento.com/guides/v2.3/release-notes/ReleaseNotes2.3.2OpenSource.html

Core Contributor

Correction, the "-px" releases no longer contain security only fixes, but can also contain high priority or important bugfixes.

This is what just happened with 2.3.5-p1. It does not contain a security fix (compared to 2.3.5) but only a high priority bug fix.

New Contributor

@Ela Murugan  our installation is already at  patch 2.3.2-p2

So for moving to 2.3.5-p1 do we necessarily have to update the 2.3.4 first or can we directly apply the security patches. The diagram by @patrick_sullivan  isn't clear on this

New Contributor

So is this the process: (especially do I need to run `bin/magento setup:upgrade` on security only patches/updates?)

 

composer require magento/product-community-edition=2.3.3-p1 --no-update
composer update
bin/magento setup:upgrade //do I need to run this on security only patch/updates
bin/magento setup:di:compile
bin/magento setup:static:content:deploy
M2 Certified

Just use https://semver.org/, please!

Given a version number MAJOR.MINOR.PATCH, increment the:

  1. MAJOR version when you make incompatible API changes,
  2. MINOR version when you add functionality in a backward-compatible manner, and
  3. PATCH version when you make backward-compatible bug fixes.

Why the whole science around "security vs quality" patch version? An enterprise-level platform like yourself should not emphasize the difference between "quality" and "security" types of patches - as both are equally important for merchants.

I will never understand why Magento opted to crank massive changes and new features under the third number.

 

Would it not be simpler to just have our composer files targeting 2.3.x with auto-updates and sleep peacefully, knowing that all X is going to be replaced is with safe backward-compatible bug fixes, that can be applied at any time, without any testing whatsoever - thus mitigating plenty of costs for merchants.

Senior Member
Occasional Contributor

We currently run 2.3.2-p2 and we didn't move to 2.3.3 or 2.3.4 or 2.3.5 for some extension issues and would like to just install latest security updates while keeping everything else working same as it is right now on 2.3.2-p2

 

If I upgrade from 2.3.2-p2 to 2.3.3-p1 does that mean essentially I am getting 2.3.3 with security patches? 2.3.4-p2? 2.3.5-p1 ... same question

I ran a test upgrade last night  ... 2.3.3-p1 was fine, 2.3.4-p2 was fine but when I went to 2.3.5-p1 after upgrade one of our extensions broke and it couldn't event run setup:upgrade or di:compile so had to roll to last backup of 2.3.2-p2

Core Contributor

So:

- 2.3.3-p1 is 2.3.3 including security fixes.

- 2.3.4-p1 is 2.3.4 including security fixes

- 2.3.4-p2 is 2.3.4-p1 including a high priority bugfix

- 2.3.5-p1 is 2.3.5 with a high priority bugfix and doesn't contain any security fixes compared to 2.3.5.

 

So if you want to be safe, you can upgrade 2.3.4-p2 and wait a bit until you figured out how to fix that extension and only then upgrade to 2.3.5-p1

 

Magento should really stop calling these -p releases "security releases", because they are not always security-only fixes and can contain high priority bugfixes as well.

Occasional Contributor

I started with 2.2.4. Went up to 2.2.11 and from there to 2.3.4. It took litteraly hundreds of hours and thousands of dollars to get this far. Because with each upgrade tons of problems arose that had to be fixed. VERY VERY VERY frustrating. Even with this new patch policy it still is not possible to stick to a minor release and install security patches ONLY for the next couple of years. I DONT want to be forced to install new features and 'fixes' that I don't need and ruin my shop everytime again. I just want to run my online business in peace without having to worry about security. For more than just half a year. Why is this so hard to understand.

M2 Certified

@rickertyou are absolutely right. Live would be much easier for us as an agency and much cheaper for our customers, if we don't break the existing shops with a new Magento release.