Parche de seguridad SUPEE-8788: ¿posibles problemas?

El último parche de seguridad Magento 1 SUPEE-8788 contiene 17 actualizaciones de APPSEC , por lo que es muy importante aplicarlo lo antes posible. Por otro lado, hay muchas posibles interrupciones de compatibilidad con versiones anteriores, y dado el historial de parches durante el último año, no lo aplicaría descuidadamente.

Lo bueno es que esta vez no hay plantillas frontend involucradas, por lo que parece que no necesitamos parchear todos nuestros temas. Esto solo es cierto para Magento 1.8 o superior.

No obstante: ¿Encontró problemas o errores de compatibilidad después de aplicar el parche?

Notas importantes

Tenga en cuenta que 1.9.3 es diferente de 1.9.2.4 + SUPEE-8788. Aquí está la diferencia entre los dos: https://gist.github.com/digitalpianism/14a15cd52baede0e5d600e8c653f33e9

Actualización 14 de octubre: v2 del parche ha sido lanzado (ver abajo) A partir del 13 de octubre, los parches para 1.5.xa 1.8.x se han eliminado del sitio web de Magento debido a la incompatibilidad con parches anteriores (ver más abajo):

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

V3 del parche

Esta nueva versión es solo para Magento EE 1.13.0.x

Aplica el V3:

• revertir SUPEE 1533 (si está instalado)
• instalar SUPEE 3941 (si no está instalado)
• instalar SUPEE 8788 v3

V2 del parche

Aplica el V2:

• revertir SUPEE 8788 v1
• revertir SUPEE 1533 (si está instalado)
• instalar SUPEE 3941 (si no está instalado)
• instalar SUPEE 8788 v2

DemacMedia desarrolló un útil script bash para automatizar el proceso anterior. Puede encontrarlo aquí: https://github.com/DemacMedia/magento-SUPEE8788-patcher

Detalles del parche

Después de profundizar en el parche, aquí están las partes interesantes (parches de 1.9.2.4):

• Mage_Adminhtml_Block_Media_Uploaderha sido reemplazado por Mage_Uploader_Block_Multiplelo que hay un Mage_Uploadermódulo completo que deja de admitir Flash . El bloque antiguo ahora está en desuso y extiende el nuevo bloque.
• Aún con respecto al cargador, el Mage_Downloadablemódulo ha sido refactorizado para manejar el nuevo cargador sin flash. Se usa Mage_Uploader_Block_Singlecomo bloque de carga en lugar de usar plantillas.
• Después de este cambio, t que los archivos SWF skin/adminhtml/default/default/media/flex.swf, skin/adminhtml/default/default/media/uploader.swfy skin/adminhtml/default/default/media/uploaderSingle.swfse han eliminado.
• El controlador de eliminación de direcciones ahora está protegido con clave de formulario directamente a través getDeleteUrldeMage_Customer_Block_Address_Book
• El controlador de eliminación de elementos de la lista de deseos ahora está protegido con la clave de formulario a través getRemoveUrldeMage_Wishlist_Helper_Data
• El método de pago de Paypal Express ahora garantiza que el correo electrónico del cliente utilizado exista en Magento al momento de pagar y registrar un nuevo usuario. (Comprenda: el nuevo usuario se crea antes de que se procese la nueva cotización)
• Los métodos de pago que utilizan el cliente cURL / HTTP ahora se han CURLOPT_SSL_VERIFYHOSTestablecido en 2 (antes era 0) y el CURLOPT_SSL_VERIFYPEERindicador ahora se agrega a las llamadas cURL. El indicador Verify Peer se puede habilitar / deshabilitar a través de la configuración del método de pago a través del menú desplegable Habilitar verificación SSL.
• Mage_Http_Client_Curlahora se ha CURLOPT_SSL_VERIFYPEERestablecido en verdadero (antes era falso) , tenga cuidado si tiene algún módulo personalizado que lo use.
• Las dimensiones máximas para las imágenes del producto ahora se pueden configurar en la configuración. NB: puede generar un mensaje de error divertido si sube imágenes demasiado grandes: formato de archivo no permitido en Magento 1.9.2.2 después de la carga del parche

Problemas conocidos de SUPEE-8788 v2

• Magento 1.9.2.0 SUPEE-8788 v2 Hunk # 1 FALLÓ en 91 después de revertir SUPEE-1533
• El parche no se puede aplicar en el modelo PayPal Express: Magento 1.9.2.2 SUPEE-8788 v2 Hunk # 1 FAILED
• Coincidencia no relacionada con parches Los correos electrónicos dejaron de enviarse el 1.8: https://magento.stackexchange.com/q/141799/2380 y el problema del parche de seguridad 8788 V2
• Cambio incompatible con versiones anteriores al llamar al getConfig()método desde el bloque del cargador: Problema en el Panel de administración después de la instalación del SUPEE Patch 8788

Problemas conocidos de SUPEE-8788 v1

• Actualización: la v2 del parche corrige ese problema (ver arriba)Conflicto entre SUPEE-1533 y SUPEE-8788 , posible solución (hacky) aquí . Una solución menos hacky aquí
• Actualización: v2 del parche corrige ese problema Unsupported data type Nerror en /lib/Unserialize/Reader/ArrValue.php1.9.1.0 y posiblemente versiones anteriores cuando se aplica el parche. arreglar aquí: https://gist.github.com/balloz/ceaf5feb5ac66caaa82342441d32aa88
• Actualización: la v2 del parche corrige ese problema Posible conflicto con SUPEE-3941: https://magento.stackexchange.com/a/140696/2380
• Problema con OS X:Illegal Byte Sequence : SUPEE-8788 en OSX - secuencia de bytes ilegal
• Parche malformado (probablemente bue a la secuencia binaria en el parche) : parche Magento 1.9.2.4 parche SUPEE-8788 malformado en la línea 5790
• Inclusión de un test_oauth.phparchivo con parche EE , no presione ese archivo para pinchar
• Posible problema de inicio de sesión en EE relacionado conEnterprise_Pci : https://magento.stackexchange.com/a/140577/2380
• Problema si edita el archivo de parche ya que contiene archivos binarios encapsulados , use este método si necesita editar: https://magento.stackexchange.com/a/140575/2380
• En caso de que tenga una app/code/localversión Mage/Core/functions.php, tendrá problemas con la nueva hash_equalsfunción : https://magento.stackexchange.com/a/140664/2380
• Es bueno saber que hay algunos cambios de plantillas involucrados con respecto a form_key para Magento antes de 1.8
• Posible problema en 1.5.1.0 con downloader/Maged/View.php: Error del parche de seguridad SUPEE-8788 en el descargador / Maged / View.php (M1 v1.5.1.0)
• En caso de que haya eliminado / renombrado la downloadercarpeta: https://magento.stackexchange.com/a/140631/2380

Problemas conocidos de 1.9.3.0

Editar: como la lista se está alargando y está bastante fuera de tema en esta respuesta (ya que no está relacionada con SUPEE-8788), puede consultar esta publicación para ver la lista de problemas conocidos de 1.9.3.0: https: //magento.stackexchange. com / a / 140826/2380

Al aplicar el parche este error puede ocurrir:

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

El parche 8788 contiene contenido binario. Como Magento no proporciona ningún enlace de descarga directa (odio esta política desde entonces), debe descargar el parche en su computadora y cargarlo con una aplicación de transferencia de archivos (como WinSCP en Windows) a su servidor. WinSCP, por ejemplo, se cargará en modo TEXTO (WinSCP maneja los archivos * .sh como texto de forma predeterminada).

Entonces, la solución para esto es comprimir / tar el archivo de parche y descomprimir / descomprimir nuevamente en el servidor. et voila.

Lo siento, no tenía forma de responder esto

1. Descargue la versión correcta de magento (por ejemplo: CE 1.9.1.0)
2. Reemplace los siguientes archivos con la ubicación descargada

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

3. Ejecute el parche

Trabajó para mi

Si ya aplicó SUPEE-1533, el parche fallará app/code/core/Mage/Adminhtml/controllers/DashboardController.php.

Resolví esto por ...

1. Revertir manualmente los cambios introducidos en ese archivo por SUPEE-1533
2. Aplicar SUPEE-8788
3. Reintroduzca manualmente los cambios introducidos en ese archivo por SUPEE-1533

Eliminar el cambio del SUPEE-8788 es peligroso porque el archivo de parche contiene datos binarios y guardarlo en un editor puede causar problemas (otro problema).

Aquí hay un resumen de lo que yo (y otros) encontré hasta ahora, estoy tratando de mantenerlo ordenado, siéntase libre de agregar o vincular todo lo que falta, la publicación es un Wiki de la comunidad:

Motivos del parche fallido

Si ve "ERROR: el parche no se puede aplicar / revertir con éxito", busque "Hunk # 1 FAILED" en los mensajes de registro para verificar en qué archivo falló el parche.

• Aparentemente, v2 del parche para Magento 1.7 espera que se presente SUPEE-3941, aunque solo existe para Magento 1.8 y 1.9 . Si está en Magento 1.7 y ve errores relacionados con los archivos downloader, descargue SUPEE-3941 para 1.8 y aplíquelo en 1.7, debería funcionar. Vea el hilo de comentarios aquí: problema del parche de seguridad SUPEE 8788

• En las versiones de Magento a las que se les ha aplicado SUPEE-1533 anteriormente, el parche falla app/code/core/Mage/Adminhtml/controllers/DashboardController.phpporque el archivo está afectado por ambos parches y SUPEE-8788 (¡incorrectamente!) Supone que la versión sin parche está presente. ¡Esto sigue siendo cierto con la versión 2 del parche! La versión 2 incluye los cambios de SUPEE-1533, por lo que si lo instaló antes, aún debe revertirlo, pero no tiene que volver a aplicarlo manualmente después.

• Si eliminó o renombró el directorio "descargador", el parche fallará porque parcheará un archivo dentro del descargador. La solución más fácil es restaurar el directorio de descarga original, aplicar el parche y luego eliminar el directorio nuevamente. Alternativamente, también puede eliminar las instrucciones downloader/lib/Mage/HTTP/Client/Curl.phpdel parche.

• Otros mensajes de "Hunk FAILED" generalmente se deben a cambios en los archivos principales o faltan parches anteriores. Asegúrese de que todos los parches anteriores para su versión de Magento estén instalados y no haya realizado cambios en los archivos principales.

• Otro problema común es que el parche no puede eliminar .swfarchivos debido a su contenido binario. El error se verá así:

  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
  

  o así

  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:
  --------------------------
  

  o así:

  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.

  Las posibles soluciones se dan en esta respuesta por @infabo. Descargar el parche directamente al sistema donde quiero aplicarlo, usando curl como se explica en https://gist.github.com/piotrekkaminski/9bc45ec84028611d621e siempre funcionó para mí, excepto cuando lo probé en Cygwin

Manera avanzada de lidiar con parches fallidos: @PeterOCallaghan sugirió comentar la línea de ejecución en seco y manejar manualmente los archivos * .rej. De esta manera, el parche se puede aplicar parcialmente y si no puede eliminar los archivos swf, puede hacerlo manualmente. O si no puede actualizar los archivos downloaderporque eliminó ese directorio, puede ignorarlo.

1. vi PATCH_SUPEE-8788_CE_1.8.1.0_v1-2016-10-11-06-54-44.sh(o nombre de archivo similar) cambia _apply_revert_patch dry-runpara parecerse #_apply_revert_patch dry-run

2. ejecutar el parche emitiendo ./PATCH_SUPEE-8788_CE_1.8.1.0_v1-2016-10-11-06-54-44.sh

Eso parcheará tus archivos

3. Comenta _apply_revert_patcha#_apply_revert_patch

4. ejecuta el parche nuevamente para agregar la app/etc/app/etc/applied.patches.listentrada

5. grep para todos los archivos .rej con

   git status | grep *.rej

6. trabajar manualmente en esos cambios

Problemas después de aplicar el parche

Teclas de formulario

• Para las versiones de Magento anteriores a la 1.8 hay cambios en las frontend/base/defaultplantillas. Asegúrese de aplicar manualmente los mismos cambios en su tema si anula estos archivos

  Más específicamente, se ha agregado una clave de formulario para acciones frontend como:

  • Eliminar un elemento de la lista de deseos
  • Eliminar la dirección de un cliente de la vista de la tienda
  • Actualizar un artículo de presupuesto en su cesta

  Vea esta respuesta de @LukeRogers si encuentra problemas con estas acciones.

Cargador personalizado

Unirgy_Rapidflow y otras extensiones con formularios de carga personalizados ya no funcionan.

Ver esta respuesta por @mpchadwick y comentario por @lloiacono

Lo arreglé reemplazando $this->getUploader()->getConfig()con $this->getUploader()->getUploaderConfig()enUnirgy_RapidFlow_Block_Adminhtml_Profile_Edit_Tab_Upload

Para averiguar si alguna de sus extensiones usa esto, puede ejecutar lo siguiente en la línea de comando:

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

Mensajes de error reportados

• Error fatal de PHP: Llamada a la función indefinida hash_equals ()

  que sucede si se encuentra en una versión de PHP anteriores a 5.6 y anular code/core/Mage/core/functions.phpen code/local/Mage/core/functions.php(que podría ser el caso si se utiliza extensiones Fishpig). Ver esta respuesta por @ClaudiuCreanga

Problemas resueltos en v2 del parche

Si encuentra alguno de estos problemas, probablemente use la versión 1 del parche ("v1" en el nombre del archivo). Descargue el parche nuevamente para obtener "v2" que corrige estos problemas:

• Hubo un problema de compatibilidad con SUPEE-3941 y downloader/lib/Mage/HTTP/Client/Curl.php

• 'Excepción' con el mensaje 'Tipo de datos no admitidos N' en /lib/Unserialize/Reader/ArrValue.php

• ¡El parche para EE 1.14.2.0 accidentalmente contenía un nuevo archivo test_oauth.php que debería eliminar! Ver esta respuesta por @MatthiasZeis

Si lo consigues

Call to undefined function hash_equals() error

incluso si su parche fue exitoso, puede significar que ha copiado functions.php app/code/local/Mage/Core.

Tendrá que insertar esa función allí también porque ese archivo sobrescribe el núcleo.

Así que inserte app/code/local/Mage/Core/functions.phpal final:

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;
    }
}

En PATCH_SUPEE-8788_EE_1.14.2.0_v1-2016-10-10-02-27-03.sh, test_oauth.phpse crea un archivo en el directorio raíz de Magento. Querrá eliminar este (o al menos no implementarlo en producción) porque podría exponer un seguimiento completo de la pila de excepciones a la persona que llama la URL https: //thedomain.tld/test_oauth.php .

ESTO SE APLICA PARA 1.7 VERSIONES DE MAGENTO

Si está ejecutando 1.7.0.2, la versión 2 de SUPEE 8788 fallará en la línea 372 al intentar aplicar cambios a 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

Las instrucciones dicen que debemos revertir SUPEE-1533 e instalar SUPEE-3941

PROBLEMA: SUPEE-3941 solo está disponible para Magento CE 1.8-1.9. Puede intentar aplicarlo para 1.7, y se aplicará. Yo creo quedesarrolladores de parches Magento debería lanzar una versión 3 de SUPEE-8788 para aquellos que ejecutan magento's por debajo de 1.8 o crear un parche SUPEE-3941 adicional que esté diseñado para la versión por debajo de 1.8.

Por cierto, la versión 1 de SUPEE-8788 no tenía el Curl.phperror en 1.7.0.2 (lo probé en muchas instalaciones)

Consejo: si se enfrenta a errores .swf al final, asegúrese de comprimir el parche, cargarlo en el servidor y descomprimirlo allí. El error SWF desaparecerá.

ACTUALIZAR:

Magento dijo que básicamente está bien instalar el parche SUPEE-3941 en una versión Magento 1.7.0.2 para evitar errores al aplicar SUPEE-8788

DashboardController.php original (1.7.0.2- Sin palear, Recién llegado de magento)

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

1533 Patched DashboardController.php contiene el siguiente cambio

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

El parche 8788 realiza el siguiente cambio en DashboardController.php

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

Como puede ver, 8788 tiene un cambio modificado en comparación con 1533, NO estoy seguro de si es ideal modificar el archivo como sugiere mpchadwick, reemplazando manualmente el cambio 8788 con 1533 después de instalar 8788. Básicamente eliminando el cambio 8788.

¿Alguna sugerencia?

Medio tentado a marcar esta publicación como basada principalmente en opiniones o sin una respuesta clara;)

Se han agregado claves de forma a un par de controladores, el número varía según la versión de magento.

Si tienes problemas

• Eliminar un elemento de la lista de deseos
• Eliminar la dirección de un cliente de la vista de la tienda
• Actualizar un artículo de presupuesto en su cesta

Deberá verificar su .phtmlarchivo de temas y asegurarse de que está POSTpasando el parámetro clave de formulario para que pase la verificación en las acciones del controlador como:

class Mage_Checkout_CartController extends Mage_Core_Controller_Front_Action

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

Estos problemas hicieron tropezar a mucha gente en parches anteriores, los temas frontend personalizados con plantillas anuladas se pierden fácilmente al aplicar los parches.

Claves del formulario con frecuencia se añaden a la .phtmlplantilla que contiene la forma como extra inputcomo

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

Encontré el mismo problema en swf en 1.9.2.4.

Fox fijo: siga los pasos a continuación.

Paso 1. Descargue el parche de seguridad 8788 SSH en este enlace: - https://magento.com/tech-resources/downloads/magento/

Paso 2. Después de descargar el archivo de seguridad parche 8788 SSH Por favor, colóquelo en una carpeta y cree el mismo archivo Zip.

Paso 3. Sube la carpeta Zip a la carpeta raíz de magento y descomprime a través de SSH Putty.

Paso 4. Ejecute el parche: - $ bash PATCH_SUPEE-8788_CE_1.9.2.4_v1-2016-10-11-07-03-46.sh

* Nota: el archivo de parche contiene archivos binarios completos en formato de texto. Es por eso que cuando carga el archivo de parche de seguridad 8788 SSH sin archivo zip, el mismo archivo estará dañado. * *

Después de aplicar SUPEE-8788 ya no pude cargar los perfiles "Importar" usando Unirgy_RapidFlow 2.0.0.18, obteniendo un error 500 (nada en los registros de Apache o HTTPD).

Todavía estoy en el proceso de depuración y trabajando con Unirgy para resolverlo, pero parece que el bloqueo del cargador está causando el problema ( Unirgy_RapidFlow_Block_Adminhtml_Profile_Edit_Tab_Upload).

El parche introdujo varios cambios en Mage_Adminhtml_Block_Catalog_Product_Helper_Form_Gallery_Contentel padre.

Además de uRapidFlow, otros módulos de terceros que permiten la carga de archivos podrían romperse como resultado de SUPEE-8788.

Recibí el siguiente mensaje al ejecutar el script de parche:

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

Creo que esto se debe a que cambié el nombre de la carpeta "descargador", siguiendo las recomendaciones de https://www.magereport.com .

Cambié temporalmente el nombre de la carpeta a "descargador", apliqué el parche correctamente y luego le cambié el nombre por su nombre secreto.

El parche en 1.9.0.0 también falla (probablemente 1.8.0.0 hasta 1.9.0.1 afectado) debido a SUPEE-3941. 3941 parches descargador / lib / Mage / HTTP / Client / Curl.php y ahora el 8788 falla.

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

Solución para 1.9.0.1 a continuación. Los cambios son demasiado completos, tal vez sea necesario ajustar el parche 8788 en sí.

editar: edite el parche, busque Curl.php y reemplace

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 

con

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

Esto es lo que estoy obteniendo

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

Parece que Magento lanzará una versión actualizada del SUPEE 8788, para corregir la compatibilidad del SUPEE 1533. No estoy seguro de si es una buena idea aplicar arreglos manuales en este momento. Los cambios manuales pueden comprometer futuras actualizaciones de parches. Me gustaría escuchar tus pensamientos.

Ha sido confirmado por Magento Community Manager. A partir del 13 de octubre, 3 p.m. EST .. todos los parches para las versiones inferiores a 1.9 se eliminan de la lista de descargas https://www.magentocommerce.com/download?_ga=1.236497153.1889606568.1445610645 Ver publicación: https://community.magento.com/t5 / Parches de seguridad / SUPEE-8788-AND-SUPEE-1533-Incompatible-Hunk-error / mp / 50514 / highlight / false # M1805

Recibimos informes de los siguientes problemas nuevos que no veo en otras publicaciones:

• Excepción en las nuevas versiones en algunos casos: la llamada al método addCrumbs () (en caso de que getStoreConfig (web / default / show_cms_breadcrumbs) no esté definida). No debería afectar el parche, solo la versión 1.9.3 / 1.14.3

'Excepción' con el mensaje 'Tipo de datos no admitidos N' en /lib/Unserialize/Reader/ArrValue.php en 1.9.1.0 y posiblemente versiones anteriores cuando se aplica el parche. resuelto en el parche versión 2.

Actualmente no se conocen soluciones fáciles para esos problemas. Estamos trabajando para resolverlos en una nueva versión de parche.

El cargador se interrumpe cuando carga el mismo archivo para muestras y enlaces al mismo tiempo para productos descargables. Tenga en cuenta que esto solo sucede si usa el mismo archivo en ambas áreas. (Solía ​​funcionar correctamente antes del parche).

Para reproducir, edite un producto descargable y haga clic en la pestaña Información descargable :

1. Abra la fila de muestras del acordeón y busque un archivo de muestra.
2. En la fila de enlaces del acordeón, busque un enlace de descarga
3. Haga clic en Cargar archivos desde la sección Enlaces.

El cargador carga el archivo de muestra en lugar del archivo de enlace descargable, y el archivo que buscó en la sección de enlaces descargables desaparece.

Pude reproducir esto en una instalación vainilla, parcheada 1.7.0.2 CE.

Sí, encontré otro problema al iniciar sesión, siempre devolverá esto:

Descubrí que es porque en la clase Enterprise_Pci_Model_Observer línea 165,

En lugar de:

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

Esto arreglará:

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

Como no me gusta cambiar el núcleo (incluso moverme a local), es mejor si Magento arregla esto o aclara esto. Por el momento, el mío está creando nuevas extensiones para extender esto y crear una función para getPassword () (ya que quiero asegurarme de que todos los desarrolladores usen el modo Desarrollador activado).

Edición de archivo de parche

Si alguien tiene que editar el archivo de parche, no debería hacerlo en un editor ya que esto romperá los archivos binarios encapsulados en el parche.

Si tiene una línea de comando a mano, es decir. linux / * unix intente usar la sedutilidad para eliminar líneas específicas.

Apoyos a @fooman para la propina. Mira su esencia original

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

Esto eliminará la línea 101 a 111 inclusive.

Problemas de envío de formularios.

Si está viendo el problema mencionado anteriormente, también puede:

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

Para obtener más información, consulte esta publicación ¿Qué es getBlockHtml ('formkey')?

CE 1.6.2.0 y SUPEE-3941

Para aplicar el parche de seguridad SUPEE-8788 (Versión 2), ( http://devdocs.magento.com/guides/m1x/other/ht_install-patches.html#apply-8788-new ) se sugiere aplicar SUPEE-3941 primero .

Sin embargo, en la página de descarga del parche, no hay parche SUPEE-3941 para CE 1.6.2.0. El parche solo está disponible para CE 1.8 y 1.9.

Como se menciona en este hilo, parece estar bien aplicar el parche SUPEE-3941 disponible (para CE 1.8 y 1.9) en CE 1.7.

¿También está bien aplicar SUPEE-3941 (para CE 1.8 y 1.9) en CE 1.6.2.0? Intenté aplicarlo en CE 1.6.2.0 y obtuve el siguiente 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

Un poco tarde, pero encontramos un problema en el parche SUPEE-8788 V2 que al menos se aplica a los archivos de parche para Magento 1.7.0.2 y 1.7.0.1. Probablemente esto también se aplica a todas las versiones anteriores para las que existe una versión de parche. La versión de Magento de 1.8 en adelante no se ve afectada ya que el parche no cambia las plantillas para ellos.

En detalle

Al parche le falta una clave de formulario para el archivo app/design/frontend/base/default/template/persistent/checkout/onepage/login.phtml

Sin él, el inicio de sesión no funciona en el pago de una página (simplemente no funciona sin error).

Reparar

Se debe insertar una clave de formulario como en el siguiente parche:

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>

Para el sitio parcheado 1533, simplemente reemplace la línea de abajo de 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) 

por:

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));

Básicamente, solo revirtió el 1533 y dejó el 8788.

La captura de Authorize.net se rompe después de aplicar el parche. La autorización funciona bien, pero al capturar el pago para facturar aparece "Error de puerta de enlace: se requiere el número de tarjeta de crédito" . El archivo de registro de pagos muestra el x_typevalor de param auth_captureahora, pero antes del parche solía pasar, lo prior_auth_captureque funcionó bien. ¿Alguien experimenta este problema?

ACTUALIZACIÓN: Solución para este problema: Authorize.net no captura

He parcheado una copia de Magento 1.9.2.4 usando SSH con SUPEE-8788 He parcheado otra copia de Magento 1.9.2.4 usando ftp con SUPEE-8788 He parcheado una copia de magento 1.9.1.0 usando SSH con SUPEE-8788 Tengo usó una copia nueva de magento 1.9.3.1

En todos estos sitios web de magento con SUPEE-8788 tengo el mismo problema (quizás un error del parche)

Utilizando productos descargables y entrando en Información descargable-> Muestras cuando intento agregar una nueva fila (una o más) haciendo clic en la "X" ya no puedo eliminar la fila

No soy tan experto en Magento, estoy tratando de encontrar una solución. Si encuentro, publicaré, si alguno de ustedes tiene alguna solución, será muy muy útil para mí.

ACTUALIZACIÓN : usando el inspector de Chrome vi este error:

******* ENCONTRÉ LA SOLUCIÓN *******

Pasé 2 días y espero que esto pueda ayudar a alguien más, esto es un error en SUPEE-8788

Abra samples.phtml dentro app/design/adminhtml/default/default/template/downloadable/product/edit/downloadable

Encuentra la función

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();
    }
},

y reemplazarlo con

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();
    }
},

Esto resolverá el ERROR

Aplica PATCH_SUPEE-8788_CE_1.9.2.1_v1-2016-10-11-07-00-43 en la copia de prueba del sitio que ejecuta 1.9.2.1 y ha roto el pago. Revierta el parche y la comprobación volverá a funcionar normalmente.

Al enviar el pedido, lo lleva de regreso al carrito en lugar de realizar el pago correctamente. Creo que estaré esperando la versión .1 antes de volver a intentarlo.

Un nuevo correo electrónico en las primeras horas de Magento afirma que estarán produciendo nuevas versiones de parches para tratar los problemas de compatibilidad SUPEE-1533 y SUPEE-3941. Así que tal vez solo sostenga sus caballos por un momento.

ENTERPRISE EDITION 1.14.3, COMMUNITY EDITION 1.9.3 y SUPEE-8788 Enterprise Edition 1.14.3 y Community Edition 1.9.3 ofrecen más de 120 mejoras de calidad, así como soporte para PHP 5.6. También resuelven problemas críticos de seguridad, que incluyen: ...

... El parche SUPEE-8788 aborda estos problemas de seguridad en versiones anteriores de Magento. Desafortunadamente, hemos descubierto que los parches SUPEE-8788 para Community Edition 1.8 y versiones anteriores y Enterprise Edition 1.13 y versiones anteriores fallan si una tienda ha aplicado previamente parches de seguridad SUPEE-1533 o SUPEE-3941. Estamos trabajando para corregir este problema y proporcionaremos nuevos parches en los próximos uno o tres días. Hasta entonces, eliminaremos estas versiones del parche SUPEE-8788 de la distribución ...

Sin embargo, me preocupa que mis versiones activas de Magento se encuentren entre el CE 1.9.3 que dicen que funciona y que las nuevas versiones estarán disponibles próximamente para V1.8 y versiones inferiores. Me he puesto en contacto con ellos, así que esperaré y veré qué dicen.

No soy un gran fanático de los parches. Personalmente elimino todos los archivos de Magento de sus directorios y luego subo la nueva versión (usando un script de shell). Todos los archivos instalados a lo largo de los años, como módulos o temas, todavía están allí. Para la base de datos, hago una comparación entre las nuevas versiones instaladas. Una forma es crear o eliminar las columnas / tablas en la base de datos, la otra forma es instalar nuevamente Magento simplemente cambiando el nombre del archivo /app/etc/local.xml. Prefiero la primera.

Si no cambia la estructura de la base de datos a la versión 1.9.3.0, obtendrá algunos errores o no podrá cargar el área de administración. Si alguien está interesado en algunas comparaciones para directorios y bases de datos de Magento entre Magento CE 1.9.2.4 y 1.9.3.0, simplemente descargue el archivo desde aquí:

Comparación de Magento: versiones 1.9.2.4 - 1.9.3.0

Hay dos archivos html con muy buenos resultados visuales.

Actualicé 4 tiendas hoy usando mi método en lugar de parchear. Todos se ejecutan sin problemas.

No tener suerte en la mayoría de las instalaciones de Magento CE (6 en total). Diferentes versiones: 1.9.1, 1.9.0.1, 1.8.1.

He descargado el parche 8788 correspondiente correcto. Me he asegurado de revertir 1533 cuando corresponda.

Obtengo los siguientes resultados notables clave que son cuestionables:

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.

... comprobando la aplicación de archivo / código / core / Mage / Adminhtml / controllers / IndexController.php Hunk # 1 tuvo éxito en 373 (desplazamiento -19 líneas). ...

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

Igual que el anterior para: lib / Unserialize / Reader / Arr.php lib / Unserialize / Reader / ArrValue.php Y dice que esos tíos ignorados.

nota: No hay nada en mi directorio sin serializar / lector. Completamente vacio. nota: el Curl.php está en el directorio de descarga. No renombrado. Termina, pero no veo los archivos SWF eliminados. No veo el parche aplicado en la lista de apply.patches.list

No tiene sentido.

Hoy parcheé unos 10 sitios web, y cada sitio donde falló el parche SUPEE-8788 tuvo el SUPEE-6788 FALTA .

Esto dio como resultado (ejemplo) el siguiente 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

Después de instalar SUPEE-6788, el SUPEE-8788 se parchó correctamente.

Si tienes un Hunk #1 failederror xxx, esto es lo que hice

Llegué Hunk #1 failed at 373. Error !! despues de la linea

comprobando el descargador de archivos / lib / Mage / HTTP / Client / Curl.php

Así que verifiqué el Curl.phparchivo y descubrí que lo había modificado antes (comentó una línea). Restablecí el archivo original y ejecuté el parche nuevamente. Entonces el parche fue exitoso. ;).

Luego verifiqué:

/app/etc/applied.patches.list y todo parece bien