¿Por qué PATCH_SUPEE-6788 parece no tener efecto en una instalación 1.7.0.2?

21

Nota: Este problema parece aplicarse a todas las versiones de Magento que recibieron el parche SUPEE-6788. Verás en mi respuesta que ambos .htaccess y .htaccess.samplenecesitan ser restaurados para que el parche tenga éxito.

Estoy trabajando en aplicar el parche SUPEE-6788 a un sitio CE 1.7.0.2 usando el script de shell proporcionado por magentocommerce.com/downloads . El sitio ha tenido todos los parches de seguridad anteriores aplicados.

El nombre del script es PATCH_SUPEE-6788_CE_1.7.0.2_v1-2015-10-27-12-00-16.shy tiene un md5sum de cfc0cf533fe36a5f573414f0feeb1590(este parche era inusual porque se lanzó sin comprimir, aunque el archivo no parece estar dañado o truncado).

Cuando se ejecuta este script, la salida de la consola parece indicar que al menos uno de los parches incluidos falló o se omitió, pero que muchas partes del parche tuvieron éxito, sin embargo, no gitmuestran cambios. El script se ha probado en dos entornos diferentes con la misma base de código: uno es una estación de trabajo Ubuntu GNOME 14.04 LTS y el otro un servidor compartido nexcess.com (que ejecuta CentOS).

De interés es que la salida en los dos entornos es ligeramente diferente. Tenga en cuenta las líneas que comienzan con "comprobación" vs "parches".

Una muestra de salida del entorno Ubuntu:

bash PATCH_SUPEE-6788_CE_1.7.0.2_v1-2015-10-27-12-00-16.sh                                              [19:27:10]
Checking if patch can be applied/reverted successfully...
ERROR: Patch can't be applied/reverted successfully.

checking file .htaccess
Hunk #1 FAILED at 207.
1 out of 1 hunk FAILED
can't find file to patch at input line 38
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git .htaccess.sample .htaccess.sample
|index 546f18e..3e79c77 100644
|--- .htaccess.sample
|+++ .htaccess.sample
--------------------------
File to patch: 
Skip this patch? [y] 
Skipping patch.
1 out of 1 hunk ignored
checking file app/code/core/Mage/Admin/Model/Block.php
checking file app/code/core/Mage/Admin/Model/Resource/Block.php
checking file app/code/core/Mage/Admin/Model/Resource/Block/Collection.php
checking file app/code/core/Mage/Admin/Model/Resource/Variable.php
checking file app/code/core/Mage/Admin/Model/Resource/Variable/Collection.php
checking file app/code/core/Mage/Admin/Model/Variable.php
...

Una muestra del entorno CentOS:

bash PATCH_SUPEE-6788_CE_1.7.0.2_v1-2015-10-27-12-00-16.sh 
Checking if patch can be applied/reverted successfully...
ERROR: Patch can't be applied/reverted successfully.

patching file .htaccess
Hunk #1 FAILED at 207.
1 out of 1 hunk FAILED -- saving rejects to file .htaccess.rej
can't find file to patch at input line 38
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git .htaccess.sample .htaccess.sample
|index 546f18e..3e79c77 100644
|--- .htaccess.sample
|+++ .htaccess.sample
--------------------------
File to patch: 
Skip this patch? [y] 
Skipping patch.
1 out of 1 hunk ignored
patching file app/code/core/Mage/Admin/Model/Block.php
patching file app/code/core/Mage/Admin/Model/Resource/Block.php
patching file app/code/core/Mage/Admin/Model/Resource/Block/Collection.php
patching file app/code/core/Mage/Admin/Model/Resource/Variable.php
...

Investigaré el error en la parte superior de la salida y posiblemente aplicaré manualmente los parches, pero esperaba que alguien pudiera tener una idea de la causa o una solución relativamente simple.

magento-1.7 ce-1.7.0.2 security patches supee-6788 STW
fuente

He probado todas las soluciones mencionadas anteriormente. Pero aún así no puedo aplicar el parche 6788 con éxito. ¿Alguien puede ayudarme en esto? Gracias.

Mesk

¿Son los síntomas los mismos? Si no, probablemente debería hacer una nueva pregunta con los detalles de su problema

STW

Utilice los archivos de la instalación de stock de Magento. Luego, asegúrese de que su .htaccessarchivo tenga exactamente 1 nueva línea vacía al final del archivo #FileETag none. Y el .htaccess.samplearchivo debe tener 2 nuevas líneas vacías al final del archivo.

pbaldauf

15

Parece que los cambios en mi persona .htaccessy en los desaparecidos .htaccess.sampleson los culpables. Después de restaurar una copia de stock de ambos archivos (ambos fueron necesarios), el parche parece aplicarse con éxito.

Para resolver esto, sin perder las modificaciones (necesarias), seguí estos pasos:

Cree una copia de seguridad de .htaccessy, .htaccess.sampleya sea con su sistema de control de versiones o copiando los archivos
Copié una versión de stock 1.7.0.2 de .htaccessy .htaccess.sampleen mi base de código, reemplazando mi personalizado.htaccess
Aplica el parche. El resultado fue mucho más corto que antes (2 líneas).
Cometió todos los cambios, incluidos .htaccess(para la posteridad)
Revisó la versión anterior de .htaccess, sin el parche, y aplicó manualmente el parche a ese archivo.

Aquí está el git diffparche, que muestra las líneas agregadas:

diff --git a/.htaccess b/.htaccess
index 60e1795..aca7f55 100644
--- a/.htaccess
+++ b/.htaccess
@@ -207,3 +207,28 @@
 ## http://developer.yahoo.com/performance/rules.html#etags

     #FileETag none
+
+###########################################
+## Deny access to cron.php
+    <Files cron.php>
+
+############################################
+## uncomment next lines to enable cron access with base HTTP authorization
+## http://httpd.apache.org/docs/2.2/howto/auth.html
+##
+## Warning: .htpasswd file should be placed somewhere not accessible from the web.
+## This is so that folks cannot download the password file.
+## For example, if your documents are served out of /usr/local/apache/htdocs
+## you might want to put the password file(s) in /usr/local/apache/.
+
+        #AuthName "Cron auth"
+        #AuthUserFile ../.htpasswd
+        #AuthType basic
+        #Require valid-user
+
+############################################
+
+        Order allow,deny
+        Deny from all
+
+    </Files>

STW
fuente

Nota: Si tiene problemas similares, pero esto no lo soluciona, es posible que se haya perdido un parche de seguridad anterior. Verifique app/etc/applied.patches.listy / o use magereport.com/scan para verificar que todos los parches de seguridad anteriores se hayan aplicado y ndash; ** son obligatorios **

STW

Trabajé para mí

jruzafa

¿Qué significa esto? Warning: .htpasswd file should be placed somewhere not accessible from the web¿Alguna idea?

Adarsh Khatri

4

He intentado descargar versiones del stock de .htaccessy .htaccess.sampley el parche todavía no se aplicaría incluso después de usar las versiones de valores.

Para cualquiera que esté experimentando este problema, eche un vistazo a este artículo que explica cómo eliminar las partes .htaccessy htaccess.sampledel parche y luego agregarlas manualmente después: http://www.atwix.com/magento/security-patch-supee-6788 -problemas de instalacion/

REVISIÓN : edite el archivo de parche eliminando las líneas 163-195 que comienzan con la línea

diff --git .htaccess .htaccess

y termina con

+    </Files>

También es posible que deba eliminar la parte relacionada con htaccess.sampleesto que comienza con

diff --git .htaccess.sample .htaccess.sample

y termina en

+    </Files>

Una vez hecho esto, intente aplicar el parche nuevamente y esta vez debería aplicarse con éxito.

A continuación, debemos agregar lo siguiente al final de nuestros archivos .htaccessy .htaccess.samplepara que estén actualizados según el parche

###########################################
## Deny access to cron.php
    <Files cron.php>

############################################
## uncomment next lines to enable cron access with base HTTP authorization
## http://httpd.apache.org/docs/2.2/howto/auth.html
##
## Warning: .htpasswd file should be placed somewhere not accessible from the web.
## This is so that folks cannot download the password file.
## For example, if your documents are served out of /usr/local/apache/htdocs
## you might want to put the password file(s) in /usr/local/apache/.

        #AuthName "Cron auth"
        #AuthUserFile ../.htpasswd
        #AuthType basic
        #Require valid-user

############################################

        Order allow,deny
        Deny from all

    </Files>

Siguiendo estos pasos pude aplicar el parche con éxito, ¡espero que esto ayude!

James Collins
fuente

1

He actualizado mi publicación original para incluir la solución, por favor, ¿pueden explicar por qué me han votado negativamente ya que estuve atrapado en este problema durante horas hasta que encontré la solución que publiqué y esperaba que pudiera ayudar a otros a seguir con esto?

James Collins el

3

Esto podría ayudarlo, aunque sea una versión diferente: https://community.magento.com/t5/Security-Patches/1-9-1-0-applying-patch-6788-hunk-failed/td-p/ 20070

Vicky Toshach
fuente

0

Tuve el mismo problema, fue porque descargué el parche incorrecto. Estoy usando Magento EE 1.13 y había descargado un parche CE ... Descargué el parche para CE 1.8 mientras seguía un tutorial, pensando que funcionaría para EE 1.13. Asegúrese de descargar el parche para su versión de Magento.

Laila
fuente

-1

Haga una copia de seguridad de su .htaccess y .htaccess.sample
Cargue archivos originales .htaccess y .htaccess.sample según su versión de Magento.
Ejecutar parche.

Gaurang Patel
fuente

¿Por qué PATCH_SUPEE-6788 parece no tener efecto en una instalación 1.7.0.2?

Respuestas: