Security Patch SUPEE-8788 - Possible Problems?

Question

The latest Magento 1 security patch SUPEE-8788 contains 17 APPSEC updates, so it is very important to apply it as soon as possible. On the other hand, there are many potential backward compatibility breaks, and given the history of patches over the last year I would not apply it carelessly.

Good thing is that this time there are no frontend templates involved, so it looks like we don't need to patch all our themes. This is only true for Magento 1.8 or higher.

Nonetheless: Did you encounter any compatibility problems or bugs after applying the patch?

Answer 1

Important notes

Please note that 1.9.3 is different than 1.9.2.4 + SUPEE-8788. Here's the diff between the two: https://gist.github.com/digitalpianism/14a15cd52baede0e5d600e8c653f33e9

Update October 14th: v2 of the patch has been released (see below) As of October 13th, the patches for 1.5.x to 1.8.x have been taken down from the Magento website because of the incompatibility with previous patches (see below):

https://community.magento.com/t5/Security-Patches/SUPEE-8788-AND-SUPEE-1533-Incompatible-Hunk-error/td-p/50434/highlight/false/page/2

V3 of the patch

This new version is only for Magento EE 1.13.0.x

Apply the V3:

• revert SUPEE 1533 (if installed)
• install SUPEE 3941 (if not installed)
• install SUPEE 8788 v3

V2 of the patch

Apply the V2:

• revert SUPEE 8788 v1
• revert SUPEE 1533 (if installed)
• install SUPEE 3941 (if not installed)
• install SUPEE 8788 v2

DemacMedia developed a useful bash script to automate the process above you can find it here: https://github.com/DemacMedia/magento-SUPEE8788-patcher

Details of the patch

After digging into the patch here are the interesting parts (patching from 1.9.2.4):

• Mage_Adminhtml_Block_Media_Uploader has been replaced with Mage_Uploader_Block_Multiple so there's a full Mage_Uploader module which drops Flash support. The old block is now deprecated and extends the new block.
• Still regarding the uploader, the Mage_Downloadable module has been refactored to handle the new non-flash uploader. It uses Mage_Uploader_Block_Single as the upload block instead of using templates.
• Following this change, the SWF files skin/adminhtml/default/default/media/flex.swf, skin/adminhtml/default/default/media/uploader.swf and skin/adminhtml/default/default/media/uploaderSingle.swf have been deleted.
• Address deletion controller is now protected with form key directly via the getDeleteUrl from Mage_Customer_Block_Address_Book
• Wishlist item removal controller is now protected with form key via the getRemoveUrl from Mage_Wishlist_Helper_Data
• Paypal Express payment method now ensures that the customer email used exists in Magento when checking out and registering a new user. (understand: the new user is created before the new quote is processed)
• The payment methods using cURL/HTTP Client now have CURLOPT_SSL_VERIFYHOST set to 2 (was 0 before) and the CURLOPT_SSL_VERIFYPEER flag is now added to the cURL calls. The Verify Peer flag can be enable/disable via the payment method configuration via the Enable SSL Verification dropdown.
• Mage_Http_Client_Curl now has CURLOPT_SSL_VERIFYPEER set to true (was false before), beware if you have any custom module using it.
• Max dimensions for product pictures are now configurable in the config. NB: it can result in a funny error message if you upload too big images: Disallowed file format in Magento 1.9.2.2 after patch upload

Known SUPEE-8788 v2 issues

• Magento 1.9.2.0 SUPEE-8788 v2 Hunk #1 FAILED at 91 after reverting SUPEE-1533
• Patch can't be applied on PayPal Express model: Magento 1.9.2.2 SUPEE-8788 v2 Hunk #1 FAILED
• Coïncidence not patch related Emails stopped being sent on 1.8 : https://magento.stackexchange.com/q/141799/2380 and Security patch 8788 V2 problem
• Backward incompatible change when calling the getConfig() method from the uploader block: Issue in Admin Panel after SUPEE Patch 8788 installation

Known SUPEE-8788 v1 issues

• Update: the v2 of the patch fixes that issue (see above)Conflict between SUPEE-1533 and SUPEE-8788, possible (hacky) workaround here . A less hacky solution here
• Update: v2 of the patch fixes that issue Unsupported data type N error in /lib/Unserialize/Reader/ArrValue.php in 1.9.1.0 and possibly earlier versions when patch is applied. fix here: https://gist.github.com/balloz/ceaf5feb5ac66caaa82342441d32aa88
• Update: the v2 of the patch fixes that issue Possible conflict with SUPEE-3941: https://magento.stackexchange.com/a/140696/2380
• Issue with OS X: Illegal Byte Sequence : SUPEE-8788 on OSX - illegal byte sequence
• Malformed patch (probably bue to the binary sequence in the patch): Magento 1.9.2.4 patch SUPEE-8788 malformed patch at line 5790
• Inclusion of a test_oauth.php file with EE patch, don't push that file to prod
• Possible login issue on EE related to Enterprise_Pci : https://magento.stackexchange.com/a/140577/2380
• Problem if you edit the patch file as it contains binary files encapsulated, use this method if you need to edit: https://magento.stackexchange.com/a/140575/2380
• In case you have an app/code/local version of Mage/Core/functions.php you'll have issue with the new hash_equals function: https://magento.stackexchange.com/a/140664/2380
• Good to know that there is some templates change involved regarding form_key for Magento prior to 1.8
• Possible issue on 1.5.1.0 with downloader/Maged/View.php : Security Patch SUPEE-8788 failing at downloader/Maged/View.php (M1 v1.5.1.0)
• Incase you removed/renamed the downloader folder: https://magento.stackexchange.com/a/140631/2380

Known 1.9.3.0 issues

Edit: as the list is getting long and it's pretty much off-topic in this answer (as not SUPEE-8788 related) you can refer to this post for the list of known 1.9.3.0 issues: https://magento.stackexchange.com/a/140826/2380

Answer 2

When applying the patch this error can happen:

checking file skin/adminhtml/default/default/media/flex.swf
checking file skin/adminhtml/default/default/media/uploader.swf
checking file skin/adminhtml/default/default/media/uploaderSingle.swf
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored
checking file skin/adminhtml/default/default/xmlconnect/boxes.css

The 8788 patch contains binary content. As Magento does not provide any direct download links (I hate this policy ever since), you have to download the patch to your computer and upload it with an file-transfer application (like WinSCP on Windows) to your server. WinSCP for example will upload in TEXT-mode (WinSCP handles *.sh files as text by default).

So the workaround for this is, zip/tar the patch-file and unzip/untar again on the server. et voila.

---

Sorry I didn't have any way to answer this

1. Download the correct magento version (Eg: CE 1.9.1.0)
2. Replace the following files with downloaded location

skin/adminhtml/default/default/media/flex.swf skin/adminhtml/default/default/media/uploader.swf skin/adminhtml/default/default/media/uploaderSingle.swf

3. Run the patch

Worked for me

---

Answer 3

Here's a summary of what I (and others) encountered so far, I'm trying to keep it sorted, feel free to add or link anything that's missing, the post is a Community Wiki:

Reasons for failed patch

If you see "ERROR: Patch can't be applied/reverted successfully", look for "Hunk #1 FAILED" in the log messages to check at which file the patch failed.

• Apparently v2 of the patch for Magento 1.7 expects SUPEE-3941 to present although it only exists for Magento 1.8 and 1.9. If you are on Magento 1.7 and see errors related to files in downloader, download SUPEE-3941 for 1.8 and apply it on 1.7, it should work. See comment thread here: Security Patch SUPEE 8788 problem

• On Magento versions that have had SUPEE-1533 applied before, the patch fails at app/code/core/Mage/Adminhtml/controllers/DashboardController.php because the file is affected by both patches and SUPEE-8788 (incorrectly!) assumes that the unpatched version is present. This is still true with version 2 of the patch! Version 2 includes the changes from SUPEE-1533, so if you installed it before, you still have to revert it, but you don't have to manually apply it again afterwards.

• If you deleted or renamed the "downloader" directory, the patch will fail because it patches a file within the downloader. The easiest workaround is to restore the original downloader directory, apply the patch, then delete the directory again. Alternatively, you could also remove the instructions for downloader/lib/Mage/HTTP/Client/Curl.php from the patch.

• Other "Hunk FAILED" messages are usually due to changes in core files or missing previous patches. Make sure all previous patches for your Magento version are installed and you did not make changes in core files.

• Another common problem is that the patch fails to delete .swf files because of their binary content. The error will look like this:

  checking file skin/adminhtml/default/default/media/uploaderSingle.swf
  Reversed (or previously applied) patch detected!  Assume -R? [n]
  Apply anyway? [n]
  Skipping patch.
  1 out of 1 hunk ignored
  

  or like this

  Patching file skin/adminhtml/default/default/media/uploader.swf using Plan A...
  No such line 2 in input file, ignoring
  Empty context always matches.
  Hunk #1 failed at 0.
  1 out of 1 hunks failed while patching skin/adminhtml/default/default/media/uploader.swf
  Hmm...  The next patch looks like a unified diff to me...
  The text leading up to this was:
  --------------------------
  

  or like this:

  Checking if patch can be applied/reverted successfully...
  /bin/patch: **** malformed patch at line 5790: ?rM]M??????&X㔮??v??Q;r?N?qJ??Y???I0?Y??4??'?????9?.??X?Ǒ?{??ax!G???I???q?u|????թ??????|
                                                 h??o?V@??|? ?g?H aꪭ??Ю???,I"?ğ????.??    yI?I\????)?X?
                       ?p???*?e?q?K8<DqD?H;|?
  ERROR: Patch can't be applied/reverted successfully.
  

  Possible solutions are given in this answer by @infabo. Downloading the patch directly to the system where I want to apply it, using curl as explained in https://gist.github.com/piotrekkaminski/9bc45ec84028611d621e always worked for me, except when I tried it on Cygwin

Advanced way to deal with failed patches: @PeterOCallaghan suggested to comment out the dry-run line and manually deal with the *.rej files. This way the patch can partially be applied and if it fails to delete the swf files, you can do that manually. Or if it fails to update files in downloader because you deleted that directory, you can just ignore that.

1. vi PATCH_SUPEE-8788_CE_1.8.1.0_v1-2016-10-11-06-54-44.sh (or similar file name) change _apply_revert_patch dry-run to look like #_apply_revert_patch dry-run

2. run the patch by issuing ./PATCH_SUPEE-8788_CE_1.8.1.0_v1-2016-10-11-06-54-44.sh

That will patch your files

3. Comment _apply_revert_patch to #_apply_revert_patch

4. run the patch again, to add the app/etc/app/etc/applied.patches.list entry

5. grep for all .rej files with

   git status | grep *.rej

6. manually work in those changes

Issues after applying patch

Form keys

• For Magento versions prior to 1.8 there are changes in frontend/base/default templates. Make sure that you manually apply the same changes in your theme if it overrides these files

  More specifically, a form key has been added for frontend actions such as:

  • Removing an item from the wishlist
  • Deleting a customers address from the store view
  • Updating a quote item in your basket

  See this answer by @LukeRogers if you encounter problems with these actions.

Custom uploader

Unirgy_Rapidflow and other extensions with custom upload forms are not working anymore.

See this answer by @mpchadwick and comment by @lloiacono

I fixed it by replacing $this->getUploader()->getConfig() with $this->getUploader()->getUploaderConfig() in Unirgy_RapidFlow_Block_Adminhtml_Profile_Edit_Tab_Upload

To find out if any of your extensions use this, you can run the following on the command line:

grep -R 'getUploader()->getConfig();' app/code/community

Reported error messages

• PHP Fatal error: Call to undefined function hash_equals()

  happens if you are on a PHP version prior to 5.6 and override code/core/Mage/core/functions.php in code/local/Mage/core/functions.php (which might be the case if you use Fishpig extensions). See this answer by @ClaudiuCreanga

---

Problems solved in v2 of the patch

If you encounter any of these issues, you probably use version 1 of the patch ("v1" in the filename). Download the patch again to get "v2" which fixes these issues:

• There was a compatibility issue with SUPEE-3941 and downloader/lib/Mage/HTTP/Client/Curl.php

• 'Exception' with message 'Unsupported data type N' in /lib/Unserialize/Reader/ArrValue.php

• The patch for EE 1.14.2.0 accidently contained a new file test_oauth.php which you should delete! See this answer by @MatthiasZeis

Answer 4

If you've previously applied SUPEE-1533 then the patch will fail on app/code/core/Mage/Adminhtml/controllers/DashboardController.php.

I solved this by...

1. Manually revert the changes introduced to that file by SUPEE-1533
2. Apply SUPEE-8788
3. Manually reintroduce the changes introduced to that file by SUPEE-1533

Removing the change from the SUPEE-8788 is dangerous because the patch file contains binary data and saving it in an editor can cause issues (another gotcha).

Answer 5

If you get

Call to undefined function hash_equals() error

even if your patch was successful then it may mean that you have copied functions.php in app/code/local/Mage/Core.

You will have to insert that function there too because that file overwrites the core one.

So insert in app/code/local/Mage/Core/functions.php at the end:

if (!function_exists('hash_equals')) {
    /**
     * Compares two strings using the same time whether they're equal or not.
     * A difference in length will leak
     *
     * @param string $known_string
     * @param string $user_string
     * @return boolean Returns true when the two strings are equal, false otherwise.
     */
    function hash_equals($known_string, $user_string)
    {
        $result = 0;

        if (!is_string($known_string)) {
            trigger_error("hash_equals(): Expected known_string to be a string", E_USER_WARNING);
            return false;
        }

        if (!is_string($user_string)) {
            trigger_error("hash_equals(): Expected user_string to be a string", E_USER_WARNING);
            return false;
        }

        if (strlen($known_string) != strlen($user_string)) {
            return false;
        }

        for ($i = 0; $i < strlen($known_string); $i++) {
            $result |= (ord($known_string[$i]) ^ ord($user_string[$i]));
        }

        return 0 === $result;
    }
}

Answer 6

In PATCH_SUPEE-8788_EE_1.14.2.0_v1-2016-10-10-02-27-03.sh, a file test_oauth.php is created in the Magento root directory. You will want to delete this one (or at least not deploy it to production) because it could expose a complete exception stack trace to the person calling the URL https://thedomain.tld/test_oauth.php.

Answer 7

THIS APPLIES FOR 1.7 MAGENTO VERSIONS

---

If you are running 1.7.0.2 version 2 of SUPEE 8788 will fail on line 372 trying to apply changes to Curl.php:

patching file downloader/lib/Mage/HTTP/Client/Curl.php
Hunk #1 FAILED at 372.
1 out of 1 hunk FAILED -- saving rejects to file downloader/lib/Mage/HTTP/Client

The instructions say that we should revert SUPEE-1533 and install SUPEE-3941

PROBLEM: SUPEE-3941 is only available for Magento CE 1.8-1.9. You can try applying it for 1.7, and it will apply. I think patch developers Magento should either release a version 3 of SUPEE-8788 for those running magento's below 1.8 or create an additional SUPEE-3941 patch that is designed for version below 1.8.

B.t.w. version 1 of SUPEE-8788 did not have the Curl.php error on 1.7.0.2 (I tested it on many installs)

Tip: if you are facing .swf errors at the end, make sure you Compress your patch, upload to the server and decompress there.SWF error will be gone.

UPDATE:

Magento said that basically it is okay to install the SUPEE-3941 patch on a Magento 1.7.0.2 version to avoid errors on applying SUPEE-8788

Answer 8

Original DashboardController.php (1.7.0.2- Not pached, Fresh from magento)

  if ($params = unserialize(base64_decode(urldecode($gaData)))) {

1533 Patched DashboardController.php contains the following change

 if ($newHash == $gaHash) {
            $params = json_decode(base64_decode(urldecode($gaData)), true);
            if ($params) {

8788 patch makes the following change in DashboardController.php

 if (hash_equals($newHash, $gaHash)) {
            if ($params = unserialize(base64_decode(urldecode($gaData)))) {

As you can see 8788 has a modified change compared to 1533, I am NOT sure whther its ideal to modify the file as mpchadwick suggests, by manually replacing 8788 change with 1533 after installing 8788. Basically removing 8788 change.

Any suggestions?

Answer 9

Half tempted to flag this post as primarily opinion based or without a clear answer ;)

Form keys have been added to a couple of controllers, the number varies depending on your magento version.

If you experience trouble

• Removing an item from the wishlist
• Deleting a customers address from the store view
• Updating a quote item in your basket

You'll need to check your themes .phtml file and make sure you're POSTing over the form key parameter so it will pass the check in the controller actions like:

class Mage_Checkout_CartController extends Mage_Core_Controller_Front_Action

     public function updatePostAction()
     {
+        if (!$this->_validateFormKey()) {
+            $this->_redirect('*/*/');
+            return;
+        }
+

These problems tripped a lot of people up in previous patches, custom frontend themes with overridden templates are easily missed when applying the patches.

Form keys are often added to the .phtml template containing the form as an extra input like

<input name="form_key" type="hidden" value="<?php echo $this->getFormKey() ?>" />

Answer 10

I met the same problem in swf in 1.9.2.4.

Fox Fixed - Please follow below steps.

Step 1. Download security patch 8788 SSH file to this Link :- https://magento.com/tech-resources/downloads/magento/

Step 2. After download security patch 8788 SSH file Please put into one folder and make same folder Zip file.

Step 3. Please upload Zip folder to root magento folder and Unzip through SSH Putty.

Step 4. Run the patch :- $ bash PATCH_SUPEE-8788_CE_1.9.2.4_v1-2016-10-11-07-03-46.sh

*Note : he patch file contains entire binary files in text format.That's why when you upload security patch 8788 SSH file without zip file, the same file will be corrupt. *

Answer 11

After appyling SUPEE-8788 I was no longer able to load "Import" profiles using Unirgy_RapidFlow 2.0.0.18, getting a 500 error (nothing in Apache or HTTPD logs).

I am still in the process of debugging and working with Unirgy to resolve, but it appears that the uploader block is causing the issue (Unirgy_RapidFlow_Block_Adminhtml_Profile_Edit_Tab_Upload).

The patch introduced several changes to Mage_Adminhtml_Block_Catalog_Product_Helper_Form_Gallery_Content, the parent.

In addition to uRapidFlow, other 3rd party modules that allow for file upload could break as a result of SUPEE-8788.

Answer 12

I got the following message when executing the patch script:

can't find file to patch at input line 4753
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git downloader/lib/Mage/HTTP/Client/Curl.php downloader/lib/Mage/HTTP/Client/Curl.php
|index 6d0607e..5757be3 100644
|--- downloader/lib/Mage/HTTP/Client/Curl.php
|+++ downloader/lib/Mage/HTTP/Client/Curl.php

I think this is because I renamed the "downloader" folder, following recommendations from https://www.magereport.com.

I temporarily renamed the folder to "downloader", applied the patch correctly and then renamed it with its secret name.

Answer 13

Patch on 1.9.0.0 fails too (probably 1.8.0.0 until 1.9.0.1 affected) because of SUPEE-3941. 3941 patches downloader/lib/Mage/HTTP/Client/Curl.php and now the 8788 fails.

checking file downloader/lib/Mage/HTTP/Client/Curl.php
Hunk #1 FAILED at 378.
1 out of 1 hunk FAILED
checking file js/lib/uploader/flow.min.js

Workaround for 1.9.0.1 below. Changes are too thorough, maybe need to adjust the 8788 patch itself.

edit: Edit the patch, search for Curl.php and replace

diff --git downloader/lib/Mage/HTTP/Client/Curl.php downloader/lib/Mage/HTTP/Client/Curl.php
index c55f88d..31f9f77 100644
--- downloader/lib/Mage/HTTP/Client/Curl.php
+++ downloader/lib/Mage/HTTP/Client/Curl.php
@@ -378,8 +378,8 @@ implements Mage_HTTP_IClient
         }

         $this->curlOption(CURLOPT_URL, $uri);
-        $this->curlOption(CURLOPT_SSL_VERIFYPEER, FALSE);
-        $this->curlOption(CURLOPT_SSL_VERIFYHOST, 2);
+        $this->curlOption(CURLOPT_SSL_VERIFYPEER, true);
+        $this->curlOption(CURLOPT_SSL_VERIFYHOST, 'TLSv1');

         // force method to POST if secured
         if ($isAuthorizationRequired) {
diff --git js/lib/uploader/flow.min.js js/lib/uploader/flow.min.js 

with

diff --git downloader/lib/Mage/HTTP/Client/Curl.php downloader/lib/Mage/HTTP/Client/Curl.php
index c55f88d..31f9f77 100644
--- downloader/lib/Mage/HTTP/Client/Curl.php
+++ downloader/lib/Mage/HTTP/Client/Curl.php
@@ -378,8 +378,8 @@ implements Mage_HTTP_IClient
         $uriModified = $this->getSecureRequest($uri, $isAuthorizationRequired);
         $this->_ch = curl_init();
         $this->curlOption(CURLOPT_URL, $uriModified);
-        $this->curlOption(CURLOPT_SSL_VERIFYPEER, false);
-        $this->curlOption(CURLOPT_SSL_VERIFYHOST, 2);
+        $this->curlOption(CURLOPT_SSL_VERIFYPEER, true);
+        $this->curlOption(CURLOPT_SSL_VERIFYHOST, 'TLSv1');
         $this->getCurlMethodSettings($method, $params, $isAuthorizationRequired);

         if(count($this->_headers)) {
diff --git js/lib/uploader/flow.min.js js/lib/uploader/flow.min.js

Answer 14

Here's what I'm getting

Hunk #1 FAILED at 373.
1 out of 1 hunk FAILED -- saving rejects to file downloader/lib/Mage/HTTP/Client/Curl.php.rej
patching file js/lib/uploader/flow.min.js
patching file js/lib/uploader/fusty-flow-factory.js
patching file js/lib/uploader/fusty-flow.js
patching file js/mage/adminhtml/product.js
patching file js/mage/adminhtml/uploader/instance.js
patching file skin/adminhtml/default/default/boxes.css
patching file skin/adminhtml/default/default/media/flex.swf
patching file skin/adminhtml/default/default/media/uploader.swf
patching file skin/adminhtml/default/default/media/uploaderSingle.swf
patching file skin/adminhtml/default/default/xmlconnect/boxes.css

Answer 15

Looks like Magento will be releasing updated version of the SUPEE 8788, to fix the SUPEE 1533 compatibility. I am not sure if its good idea to apply manually fixes right now. Manual changes may compromise future patch updates. Would like to hear your thoughts.

It has been confirmed by Magento Community Manager. As oct 13, 3pm EST.. all patches for versions below 1.9 are deleted from download list https://www.magentocommerce.com/download?_ga=1.236497153.1889606568.1445610645 See post: https://community.magento.com/t5/Security-Patches/SUPEE-8788-AND-SUPEE-1533-Incompatible-Hunk-error/m-p/50514/highlight/false#M1805

Answer 16

We are getting reports of the following new issues that I don't see in other posts:

• Exception in the new releases in some cases - addCrumbs() method call (in case getStoreConfig(web/default/show_cms_breadcrumbs) is undefined). Should not affect the patch, only the 1.9.3/1.14.3 release

'Exception' with message 'Unsupported data type N' in /lib/Unserialize/Reader/ArrValue.php in 1.9.1.0 and possibly earlier versions when patch is applied. resolved in patch version 2.

There are currently no known easy workarounds for those issues. We are working to resolve them in a new patch version.

Answer 17

Uploader breaks when you upload the same file for samples and links at the same time for downloadable products. Note that this only happens if you use the same file in both areas. (It used to work correctly before the patch.)

To reproduce, edit a downloadable product and click on the Downloadable Information tab:

1. Open the Samples row of the accordion and browse for a sample file.
2. On the Links row of the accordion, browse for a download link
3. Click Upload Files from within the Links section.

The uploader uploads the sample file instead of the downloadable link file, and the file you browsed for in the downloadable link section disappears.

I was able to reproduce this on a vanilla, patched 1.7.0.2 CE install.

Answer 18

Yes, I did encounter other issue when login, it will always return this:

I found that is because on class Enterprise_Pci_Model_Observer line 165,

Instead of:

if (!Mage::helper('core')->getEncryptor()->validateHashByVersion($password, $model->getPassword())) {

This will fix:

if (!Mage::helper('core')->getEncryptor()->validateHashByVersion($password, $model->getPasswordHash())) {

Since I don't like changing core (even move to local), it's best if Magento fix this or clarify this. At the moment mine is creating new extensions to extend this and create function for getPassword() (since I want to make sure all devs use Developer mode on).

Answer 19

Editing Patch File

If anyone has to edit the patch file, you should not being do it in an editor as this will break the binary files encapsulated in the patch.

If you have a command line handy ie. linux/*unix try using sed utility to remove specific lines.

Props to @fooman for the tip. See his original gist

Example sed -ie '101,111d' PATCH_SUPEE-8788_CE_1.7.0.2_v1-2016-10-11-06-36-18.sh

This will delete line 101 to 111 inclusively.

Form Submission Issues.

If you are seeing the above mentioned for issue you can also you:

<?= $this->getBlockHtml('formkey'); ?>

For more information refer to this post What is getBlockHtml('formkey')?

Answer 20

CE 1.6.2.0 & SUPEE-3941

To apply security patch SUPEE-8788 (Version 2), (http://devdocs.magento.com/guides/m1x/other/ht_install-patches.html#apply-8788-new) it is suggested to apply SUPEE-3941 first.

However, on the patch download page, there is no SUPEE-3941 patch for CE 1.6.2.0. The patch is available only for CE 1.8 and 1.9.

As mentioned in this thread, it seems to be okay to apply the available SUPEE-3941 patch (for CE 1.8 & 1.9) on CE 1.7.

Is it also okay to apply SUPEE-3941 (for CE 1.8 & 1.9) on CE 1.6.2.0? I tried applying it on CE 1.6.2.0 and got the following error:

Checking if patch can be applied/reverted successfully...
-e ERROR: Patch can't be applied/reverted successfully.

checking file downloader/Maged/Model/Connect.php
Hunk #1 succeeded at 489 (offset 3 lines).
checking file downloader/lib/Mage/Connect/Backup.php
checking file downloader/lib/Mage/Connect/Command.php
Hunk #1 FAILED at 64.
Hunk #2 succeeded at 205 with fuzz 2 (offset -44 lines).
Hunk #3 succeeded at 382 (offset -53 lines).
1 out of 3 hunks FAILED
checking file downloader/lib/Mage/Connect/Command/Install.php
Hunk #1 FAILED at 90.
Hunk #2 succeeded at 333 with fuzz 1 (offset 17 lines).
Hunk #3 succeeded at 363 (offset 17 lines).
1 out of 3 hunks FAILED
checking file downloader/lib/Mage/Connect/Packager.php
Hunk #4 FAILED at 268.
Hunk #5 FAILED at 290.
Hunk #6 succeeded at 369 with fuzz 2.
Hunk #7 FAILED at 377.
Hunk #9 FAILED at 428.
4 out of 10 hunks FAILED
checking file downloader/lib/Mage/Connect/Rest.php
Hunk #1 succeeded at 71 with fuzz 2 (offset -11 lines).
checking file downloader/lib/Mage/Connect/Singleconfig.php
Hunk #1 succeeded at 100 (offset -36 lines).
checking file downloader/lib/Mage/Connect/Validator.php
Hunk #1 succeeded at 418 (offset -41 lines).
Hunk #2 succeeded at 431 (offset -41 lines).
checking file downloader/lib/Mage/HTTP/Client/Curl.php
checking file downloader/template/settings.phtml

Answer 21

A little late but we found a problem in patch SUPEE-8788 V2 which at least applies to the patch files for Magento 1.7.0.2 and 1.7.0.1. Probably this also applies to all prior versions for which a patch version exists. Magento version from 1.8 on are not affected as the patch doesn't change templates for those.

In detail

The patch is missing a formkey for file app/design/frontend/base/default/template/persistent/checkout/onepage/login.phtml

Without it login doesn't work on onepage checkout (it just doesn't work without error).

Fix

A formkey has to be inserted like in following patch:

diff --git a/app/design/frontend/base/default/template/persistent/checkout/onepage/login.phtml b/app/design/frontend/base/default/template/persistent/checkout/onepage/login.phtml
index 9d15a577b..18483a3c5 100644
--- a/app/design/frontend/base/default/template/persistent/checkout/onepage/login.phtml
+++ b/app/design/frontend/base/default/template/persistent/checkout/onepage/login.phtml
@@ -71,6 +71,7 @@
         <h3><?php echo $this->__('Login') ?></h3>
         <?php echo $this->getMessagesBlock()->getGroupedHtml() ?>
         <form id="login-form" action="<?php echo $this->getPostAction() ?>" method="post">
+        <?php echo $this->getBlockHtml('formkey'); ?>
         <fieldset>
             <h4><?php echo $this->__('Already registered?') ?></h4>
             <p><?php echo $this->__('Please log in below:') ?></p>

Answer 22

For 1533 Patched site just replace below line from PATCH_SUPEE-8788*****.sh :

diff --git app/code/core/Mage/Adminhtml/controllers/DashboardController.php app/code/core/Mage/Adminhtml/controllers/DashboardController.php
index 09ffc4c..367bf8e 100644
--- app/code/core/Mage/Adminhtml/controllers/DashboardController.php
+++ app/code/core/Mage/Adminhtml/controllers/DashboardController.php
@@ -91,7 +91,7 @@ class Mage_Adminhtml_DashboardController extends Mage_Adminhtml_Controller_Actio
         $gaHash = $this->getRequest()->getParam('h');
         if ($gaData && $gaHash) {
             $newHash = Mage::helper('adminhtml/dashboard_data')->getChartDataHash($gaData);
-            if ($newHash == $gaHash) {
+            if (hash_equals($newHash, $gaHash)) {
                 if ($params = unserialize(base64_decode(urldecode($gaData)))) {
                     $response = $httpClient->setUri(Mage_Adminhtml_Block_Dashboard_Graph::API_URL)
                             ->setParameterGet($params) 

by:

diff --git a/app/code/core/Mage/Adminhtml/controllers/DashboardController.php b/app/code/core/Mage/Adminhtml/controllers/DashboardController.php
index ab2d654..367bf8e 100644
--- a/app/code/core/Mage/Adminhtml/controllers/DashboardController.php
+++ b/app/code/core/Mage/Adminhtml/controllers/DashboardController.php
@@ -91,9 +91,8 @@ class Mage_Adminhtml_DashboardController extends Mage_Adminhtml_Controller_Actio
         $gaHash = $this->getRequest()->getParam('h');
         if ($gaData && $gaHash) {
             $newHash = Mage::helper('adminhtml/dashboard_data')->getChartDataHash($gaData);
-            if ($newHash == $gaHash) {
-                $params = json_decode(base64_decode(urldecode($gaData)), true);
-                if ($params) {
+            if (hash_equals($newHash, $gaHash)) {
+                if ($params = unserialize(base64_decode(urldecode($gaData)))) {
                     $response = $httpClient->setUri(Mage_Adminhtml_Block_Dashboard_Graph::API_URL)
                             ->setParameterGet($params)
                             ->setConfig(array('timeout' => 5))
diff --git a/app/code/core/Mage/Adminhtml/Block/Dashboard/Graph.php b/app/code/core/Mage/Adminhtml/Block/Dashboard/Graph.php
index da1b14a..b6d72c0 100644
--- a/app/code/core/Mage/Adminhtml/Block/Dashboard/Graph.php
+++ b/app/code/core/Mage/Adminhtml/Block/Dashboard/Graph.php
@@ -444,7 +444,7 @@ class Mage_Adminhtml_Block_Dashboard_Graph extends Mage_Adminhtml_Block_Dashboar
             }
             return self::API_URL . '?' . implode('&', $p);
         } else {
-            $gaData = urlencode(base64_encode(json_encode($params)));
+            $gaData = urlencode(base64_encode(serialize($params)));
             $gaHash = Mage::helper('adminhtml/dashboard_data')->getChartDataHash($gaData);
             $params = array('ga' => $gaData, 'h' => $gaHash);
             return $this->getUrl('*/*/tunnel', array('_query' => $params));

Basically it just reverted the 1533 and left 8788 along.

Answer 23

Authorize.net capture is broken after applying the patch. Authorizing works good, but when capturing the payment to invoice it gives "Gateway error: Credit card number is required". Payment log file shows x_type param passes value auth_capture now, but before the patch it used to pass prior_auth_capture which worked well. Anyone experiencing this issue?

UPDATE: Fix for this issue - Authorize.net not capturing

Answer 24

I have patched a copy of Magento 1.9.2.4 using SSH with SUPEE-8788 I have patched another copy of Magento 1.9.2.4 using ftp with SUPEE-8788 I have patched a copy of magento 1.9.1.0 using SSH with SUPEE-8788 I have used a fresh copy of magento 1.9.3.1

In all these magento web sites with SUPEE-8788 i experience the same problem (maybe a bug of the patch)

Using downloadable products and going in Downloadable information->Samples when i try to Add a new row (one or more) by clicking on the "X" i'm not able anymore to remove the row

I'm not so expert in Magento i'm trying to find a solution. If i will find i will post, if anyone of you have some solution it will be very very usefull for me

UPDATE: using Chrome inspector i saw this error:

******* I FOUND THE SOLUTION *******

I spent 2 days and i hope this can help someone else, this is a bug in SUPEE-8788

Open samples.phtml inside app/design/adminhtml/default/default/template/downloadable/product/edit/downloadable

Find the function

remove : function(event){
    var element = $(Event.findElement(event, 'tr'));
    alertAlreadyDisplayed = false;
    if(element){
        element.down('input[type="hidden"].__delete__').value = '1';
        element.down('div.flex').remove();
        element.addClassName('no-display');
        element.addClassName('ignore-validate');
        element.hide();
    }
},

and replace it with

remove : function(event){
    var element = $(Event.findElement(event, 'tr'));
    alertAlreadyDisplayed = false;
    if(element){
        element.down('input[type="hidden"].__delete__').value = '1';
        Element.select(element, 'div.flex').each(function(elm){
            elm.remove();
        });
        element.addClassName('no-display');
        element.addClassName('ignore-validate');
        element.hide();
    }
},

This will solve the BUG

Answer 25

Applied PATCH_SUPEE-8788_CE_1.9.2.1_v1-2016-10-11-07-00-43 on test copy of site running 1.9.2.1 and it has broken the checkout. Revert the patch and the checkout works normally again.

When submitting the order it takes you back to the cart instead of checkout success. Think I'll be waiting for the .1 version before trying again.

Answer 26

New email in the early hours from Magento states that they will be producing new patch versions to deal with the SUPEE-1533 and SUPEE-3941 compatibility issues. So maybe just hold your horses for a bit.

ENTERPRISE EDITION 1.14.3, COMMUNITY EDITION 1.9.3, AND SUPEE-8788 Enterprise Edition 1.14.3 and Community Edition 1.9.3 deliver over 120 quality improvements, as well as support for PHP 5.6. They also resolve critical security issues, including: ...

...The SUPEE-8788 patch addresses these security issues in earlier Magento versions. Unfortunately, we have discovered that the SUPEE-8788 patches for Community Edition 1.8 and earlier releases and Enterprise Edition 1.13 and earlier releases fail if a store has previously applied SUPEE-1533 or SUPEE-3941 security patches. We are working to correct this issue and will provide new patches in the next one to three days. Until then, we are removing these versions of the SUPEE-8788 patch from distribution...

However I am concerned that my active Magento versions fall between the CE 1.9.3 that they say works and the new versions coming soon for V1.8 and below. I have contacted them so will wait and see what they say.

Answer 27

I am not a big fan of patching. Personally I remove all Magento files from their directories then upload the new version (using a shell script). All the files installed over the years like modules or themes are still there. For database I make a comparison between fresh installed versions. One way is creating or removing the columns/tables into the database, the other way is installing again Magento just changing /app/etc/local.xml file name. I prefer the first one.

If you do not change the database structure to version 1.9.3.0 you will get some errors or you cannot load admin area. If anyone is interested in some comparisons for Magento directories and databases between Magento CE 1.9.2.4 and 1.9.3.0 just download the file from here:

Magento Comparison: versions 1.9.2.4 - 1.9.3.0

There are two html files with very nice visual results.

I updated 4 stores today using my method instead of patching. All are running without any issues.

Answer 28

Not having any luck on most installs of Magento CE (6 total). Different versions: 1.9.1, 1.9.0.1, 1.8.1.

I've downloaded the correct corresponding 8788 patch. I've made sure to revert 1533 when applicable.

I get the following key notable outputs that are questionable:

Checking if patch can be applied/reverted successfully...
ERROR: Patch can't be applied/reverted successfully.

...

checking file downloader/lib/Mage/HTTP/Client/Curl.php
Hunk #1 FAILED at 372.

... checking file app/code/core/Mage/Adminhtml/controllers/IndexController.php Hunk #1 succeeded at 373 (offset -19 lines). ...

can't find file to patch at input line 5810
|diff --git lib/Unserialize/Parser.php lib/Unserialize/Parser.php
|index 423902a..2c01684 100644
|--- lib/Unserialize/Parser.php
|+++ lib/Unserialize/Parser.ph

Same as above for: lib/Unserialize/Reader/Arr.php lib/Unserialize/Reader/ArrValue.php And says those hunks ignored.

note: There is nothing in my Unserialized/Reader dir. Completely empty. note: the Curl.php is in downloader dir. Not renamed. It finishes, but I don't see the SWF files removed. I don't see the patch applied in the list of applied.patches.list

Makes no sense.

Answer 29

I've patched about 10 websites today, and every site where the SUPEE-8788 patch failed had the SUPEE-6788 MISSING.

This resulted in (example) the following error:

can't find file to patch at input line 5810
|diff --git lib/Unserialize/Parser.php lib/Unserialize/Parser.php
|index 423902a..2c01684 100644
|--- lib/Unserialize/Parser.php
|+++ lib/Unserialize/Parser.php

After installing SUPEE-6788 the SUPEE-8788 patched correctly.

Answer 30

If you are getting Hunk #1 failed at xxx Error , This is what i did

I got Hunk #1 failed at 373. Error !! after the line

checking file downloader/lib/Mage/HTTP/Client/Curl.php

So i checked the Curl.php file and found that i had modified the file before (commented one line ). I restored the original file and ran the patch again. Then the patch was successful. ;) .

Then i checked :

/app/etc/applied.patches.list & everything seems good