Patch Management

[jimbo5]

I'm very new to Magneto. About Patch Management:

How can one tell what patches are already installed with a given Magento installation? There does not seem to be patch level version numbering.

In addition, after I installed Magento, in the admin panel I saw that there are 4 critcal security patches to install including:

SUPEE-5344 and SUPEE-1533

1533 doesn't install and based on the error message appears that the base install was built with the patch. 5344 did install.

But even after installing, I'm still told there are 4 critical patches within the admin panel and the version remains Magento ver. 1.9.1.0

How does one properly track patches and patch related versioning?

[chiefair]

Every time patches are applied, they append an entry to the app/etc/applied.patches.list file and often list the patched files in additon to the patch version information.

Magento version upgrades overwrite the patched files and therefore remove the patches. You will need to read up on what patches are required for the new version and reapply them in order from oldest to newest. By the time you get through several upgrades, you will have multiple entries in app/etc/applied.patches.list with the older ones included in the code version updates dropping off the listing.

Patch management at its very crudest, its all manual and you should research and put together an archive of every patch you will need before upgrading and be sure to leave your new version of Magento with an .htaccess lockdown by IP and in maintenance mode until fully patched. No need to jump from 1.8.x.x to 1.9.x.x and be shoplifted in minutes by a script kiddie, eh?

Latest word on the street is that 1533 is included in 1.9.1.0, but 5344 must be applied (it's the really critical one).

[sherrie]

Hi @jimbo5, you can check to see if your site is still vulnerable here: http://magento.com/security-patch

[jimbo5]

Thanks chiefair... you've basically confirmed what I suspected, but found incredibly hard to believe for a product in such widespread use, been around for so long and with such a heavy price tag for enterprise.

So basically, there really is no easy patch management, right? If I'm running a given version, the admin panel will continue to tell me I require patches even though they have been applied and it also appears to incorrectly state that patches are required that have already been delivered wtih a given version.

There is no version numbering change with each patch installed, correct?

For example, other open source software I';ve used will use cumulative patch level vesioning.

You might be running version 1.2.3 but with a given patch level so you might have 1.2.3PL1 and then 1.2.3PL2 will contain the patches from PL1 plus PL2 so you always know if you are up to date based on version and PL# and are given a CORRECT and up to date warning in the admin panel if you are truly behind on patches.

Am I getting a correct understanding of magento patch managment and it basically stinks?

[chiefair]

You got it in one... Nothing changes except the code within the patched files which can be overwritten at any time, causing regression errors, you know, that blessed core everyone keeps banging on about not modifying and that  we should always be writing modules to protect our changes from being obliterated?

As to patch management, think back to all those cartoons that had the dumb, unsophisticated hick character chewing on the straw...

"Mickey Mouse and Goofy go on Vacation" also comes to mind.

[jimbo5]

For the $30,000 price tag or whatever it is for Enterprise, do they throw in some better patch management?

[Arjen Miedema]

Just adding my thoughts to the conversation. No, there is no patch management in Magento. But your option to show the PL in the version number is not going to be an option either. There is no specific order in which you need to install the patches for Magento. For example, I don't need to install SUPEE-1533 before I install SUPEE-5344, so changing version numbers would not be consistent with the patches you apply. I think that's why it's being logged in it's own file.

I work with a lot of Magento clients, both Enterprise and Community and also did some upgrades lately from CE 1.7.2.0 to CE 1.9.1.0, etc. Before I upgrade the webshop, I always check the applied patches file. And I will apply them again. Since there might be changes to those file between to versions of Magento, it's just common sense that you need to apply the patch again to make sure the file is still up-to-date.

So, just check app/etc/applied.patches.list before upgrading to see which patches are applied on the current version, upgrade and run the same patches again, if the bug hasn't been fixed yet for your new version.

[sherrie]

Hi @jimbo5, patches are like hotfixes to quickly fix issues and are rolled up into the next version. In CE, you can see a list of patches in /etc/ applied.patches.list. In EE, you have a support tool that shows installed patches. We're working to improve the process with funtional testing to speed up future releases, and the process as a whole should be much easier in Magento 2.

The admin notices are not actually checking for the vulnerability, they're just there to inform you that it exists. 

[jimbo5]

I appreciate all the feedback. I'm doing an eval now to decide if Magento is the right move for my ecommerce site and if so if Enterprise is warranted. Magento definitely comes with a lot of nice features, but I definitely have to give patch management a thumbs down. Hot fixes are nice and you might do that for an extremely important vulnerability, but why not produce cumulative patch levels... no question there then if you are up to date.

I suppose those working with magento for a long time consider this normal. From a newcomer's perspective that has worked with other open source softeware I find it a significant negative.