Patch de segurança SUPEE-8788 - Possíveis problemas?

O patch de segurança mais recente Magento 1 SUPEE-8788 contém 17 atualizações do APPSEC , por isso é muito importante aplicá-lo o mais rápido possível. Por outro lado, existem muitas quebras de compatibilidade com versões anteriores e, dado o histórico de patches no último ano, eu não a aplicaria descuidada.

O bom é que desta vez não há modelos de front-end envolvidos, portanto parece que não precisamos corrigir todos os nossos temas. Isso só é verdade para o Magento 1.8 ou superior.

No entanto: você encontrou algum problema ou bug de compatibilidade após aplicar o patch?

Anotações importantes

Observe que 1.9.3 é diferente de 1.9.2.4 + SUPEE-8788. Aqui está a diferença entre os dois: https://gist.github.com/digitalpianism/14a15cd52baede0e5d600e8c653f33e9

Atualização em 14 de outubro: a versão 2 do patch foi lançada (veja abaixo) Em 13 de outubro, os patches de 1.5.x a 1.8.x foram retirados do site Magento devido à incompatibilidade com os patches anteriores (veja abaixo):

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

V3 do patch

Esta nova versão é apenas para Magento EE 1.13.0.x

Aplique a V3:

• reverter SUPEE 1533 (se instalado)
• instale o SUPEE 3941 (se não estiver instalado)
• instalar SUPEE 8788 v3

V2 do patch

Aplique a V2:

• reverter SUPEE 8788 v1
• reverter SUPEE 1533 (se instalado)
• instale o SUPEE 3941 (se não estiver instalado)
• instalar SUPEE 8788 v2

A DemacMedia desenvolveu um script bash útil para automatizar o processo acima, você pode encontrá-lo aqui: https://github.com/DemacMedia/magento-SUPEE8788-patcher

Detalhes do patch

Depois de cavar o patch, aqui estão as partes interessantes (patching de 1.9.2.4):

• Mage_Adminhtml_Block_Media_Uploaderfoi substituído Mage_Uploader_Block_Multiplepor um Mage_Uploadermódulo completo que dispensa o suporte ao Flash . O bloco antigo agora está obsoleto e estende o novo bloco.
• Ainda com relação ao remetente, o Mage_Downloadablemódulo foi refatorado para lidar com o novo remetente não flash. Ele usa Mage_Uploader_Block_Singlecomo bloco de upload em vez de usar modelos.
• Na sequência desta alteração, t ele arquivos SWF skin/adminhtml/default/default/media/flex.swf, skin/adminhtml/default/default/media/uploader.swfe skin/adminhtml/default/default/media/uploaderSingle.swfforam excluídos.
• O controlador de exclusão de endereço agora está protegido com a chave do formulário diretamente via getDeleteUrldeMage_Customer_Block_Address_Book
• Controlador de remoção de item de lista agora é protegido com chave forma através da getRemoveUrldeMage_Wishlist_Helper_Data
• O método de pagamento Paypal Express agora garante que o email do cliente usado exista no Magento ao fazer check-out e registrar um novo usuário. (entenda: o novo usuário é criado antes do processamento da nova cotação)
• Os métodos de pagamento que usam o cliente cURL / HTTP agora foram CURLOPT_SSL_VERIFYHOSTdefinidos como 2 (era 0 antes) e o CURLOPT_SSL_VERIFYPEERsinalizador agora é adicionado às chamadas cURL. O sinalizador Verificar pares pode ser ativado / desativado através da configuração do método de pagamento através do menu suspenso Ativar verificação SSL.
• Mage_Http_Client_Curlagora CURLOPT_SSL_VERIFYPEERdefinido como true (era falso antes) , tenha cuidado se você tiver algum módulo personalizado usando-o.
• As dimensões máximas das imagens do produto agora podem ser configuradas na configuração. Nota: pode resultar em uma mensagem de erro engraçada se você enviar imagens muito grandes: Formato de arquivo não permitido no Magento 1.9.2.2 após o upload do patch

Problemas conhecidos do SUPEE-8788 v2

• Magento 1.9.2.0 SUPEE-8788 v2 Hunk # 1 FALHOU aos 91 após reverter SUPEE-1533
• O patch não pode ser aplicado no modelo PayPal Express: Magento 1.9.2.2 SUPEE-8788 v2 Hunk # 1 FAILED
• Incidência não relacionada a remendos Os emails deixaram de ser enviados no 1.8: https://magento.stackexchange.com/q/141799/2380 e problema no patch de segurança 8788 V2
• Alteração incompatível com versões anteriores ao chamar o getConfig()método a partir do bloco de upload: Problema no painel de administração após a instalação do SUPEE Patch 8788

Problemas conhecidos do SUPEE-8788 v1

• Atualização: a v2 do patch corrige esse problema (veja acima)Conflito entre SUPEE-1533 e SUPEE-8788 , possível solução alternativa (hacky) aqui . Uma solução menos hacky aqui
• Atualização: v2 do patch corrige esse problema Unsupported data type Nerro no /lib/Unserialize/Reader/ArrValue.php1.9.1.0 e possivelmente versões anteriores quando o patch é aplicado. corrija aqui: https://gist.github.com/balloz/ceaf5feb5ac66caaa82342441d32aa88
• Atualização: a v2 do patch corrige esse problema Possível conflito com SUPEE-3941: https://magento.stackexchange.com/a/140696/2380
• Emissão com OS X:Illegal Byte Sequence : SUPEE-8788 no OSX - sequência de bytes ilegal
• Patch malformado (provavelmente devido à sequência binária no patch) : Magento 1.9.2.4 patch SUPEE-8788 patch mal formado na linha 5790
• Inclusão de um test_oauth.phparquivo com patch EE , não envie esse arquivo para
• Possível problema de login no EE relacionado aEnterprise_Pci : https://magento.stackexchange.com/a/140577/2380
• Problema se você editar o arquivo de correção, pois ele contém arquivos binários encapsulados , use este método se precisar editar: https://magento.stackexchange.com/a/140575/2380
• Caso você tenha uma app/code/localversão, Mage/Core/functions.phpterá problemas com a nova hash_equalsfunção : https://magento.stackexchange.com/a/140664/2380
• É bom saber que existem algumas alterações de modelos envolvidas em relação à form_key para Magento antes da 1.8
• Possível problema no 1.5.1.0 com downloader/Maged/View.php: Patch de segurança SUPEE-8788 falhando no downloader / Maged / View.php (M1 v1.5.1.0)
• Caso você tenha removido / renomeado a downloaderpasta: https://magento.stackexchange.com/a/140631/2380

Problemas conhecidos do 1.9.3.0

Edit: como a lista está ficando longa e está praticamente fora do tópico nesta resposta (como não relacionada ao SUPEE-8788), você pode consultar este post para obter a lista dos problemas conhecidos do 1.9.3.0: https: //magento.stackexchange. com / a / 140826/2380

Ao aplicar o patch, este erro pode ocorrer:

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

O patch 8788 contém conteúdo binário. Como o Magento não fornece links de download direto (eu odeio essa política desde então), você deve baixar o patch no seu computador e carregá-lo com um aplicativo de transferência de arquivos (como o WinSCP no Windows) para o seu servidor. O WinSCP, por exemplo, será carregado no modo TEXTO (o WinSCP manipula arquivos * .sh como texto por padrão).

Portanto, a solução alternativa é compactar / tar o arquivo de correção e descompactar / descompactar novamente no servidor. et voila.

Desculpe, eu não tinha como responder isso

1. Baixe a versão correta do magento (por exemplo: CE 1.9.1.0)
2. Substitua os seguintes arquivos pelo local baixado

skin / adminhtml / padrão / padrão / mídia / flex.swf skin / adminhtml / padrão / padrão / mídia / uploader.swf skin / adminhtml / padrão / padrão / mídia / uploaderSingle.swf

3. Execute o patch

Trabalhou para mim

Se você aplicou o SUPEE-1533 anteriormente, o patch falhará app/code/core/Mage/Adminhtml/controllers/DashboardController.php.

Eu resolvi isso por ...

1. Reverta manualmente as alterações introduzidas nesse arquivo por SUPEE-1533
2. Aplicar SUPEE-8788
3. Reintroduza manualmente as alterações introduzidas nesse arquivo por SUPEE-1533

Remover a alteração do SUPEE-8788 é perigoso porque o arquivo de correção contém dados binários e salvá-los em um editor pode causar problemas (outra dica).

Aqui está um resumo do que eu (e outros) encontrei até agora, estou tentando mantê-lo organizado, sinta-se à vontade para adicionar ou vincular qualquer coisa que estiver faltando, a postagem é um Wiki da comunidade:

Razões para falha na correção

Se você vir "ERRO: O patch não pode ser aplicado / revertido com êxito", procure "Hunk # 1 FAILED" nas mensagens de log para verificar em qual arquivo o patch falhou.

• Aparentemente, a v2 do patch do Magento 1.7 espera que o SUPEE-3941 seja apresentado, embora exista apenas para o Magento 1.8 e 1.9 . Se você estiver no Magento 1.7 e downloadervir erros relacionados aos arquivos , faça o download do SUPEE-3941 para 1.8 e aplique-o no 1.7, ele deve funcionar. Consulte o tópico de comentários aqui: Problema no patch de segurança SUPEE 8788

• Nas versões Magento que tiveram o SUPEE-1533 aplicado anteriormente, o patch falha app/code/core/Mage/Adminhtml/controllers/DashboardController.phpporque o arquivo é afetado pelos patches e o SUPEE-8788 (incorretamente!) Assume que a versão sem patch está presente. Isso ainda é verdade com a versão 2 do patch! A versão 2 inclui as alterações do SUPEE-1533, portanto, se você o instalou antes, ainda precisará revertê-lo, mas não precisará aplicá-lo manualmente novamente posteriormente.

• Se você excluiu ou renomeou o diretório "downloader", o patch falhará porque corrige um arquivo dentro do downloader. A solução mais fácil é restaurar o diretório original do downloader, aplicar o patch e excluir o diretório novamente. Como alternativa, você também pode remover as instruções downloader/lib/Mage/HTTP/Client/Curl.phpdo patch.

• Outras mensagens "Hunk FAILED" geralmente ocorrem devido a alterações nos arquivos principais ou à falta de patches anteriores. Verifique se todos os patches anteriores da sua versão do Magento estão instalados e se você não fez alterações nos arquivos principais.

• Outro problema comum é que o patch falha ao excluir .swfarquivos devido ao seu conteúdo binário. O erro terá a seguinte aparência:

  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
  

  ou assim

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

  ou assim:

  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.
  

  As possíveis soluções são dadas nesta resposta por @infabo. O download do patch diretamente no sistema em que eu quero aplicá-lo, usando curl, conforme explicado em https://gist.github.com/piotrekkaminski/9bc45ec84028611d621e, sempre funcionou para mim, exceto quando eu tentei no Cygwin

Maneira avançada de lidar com patches com falha: @PeterOCallaghan sugeriu comentar a linha de execução a seco e lidar manualmente com os arquivos * .rej. Dessa forma, o patch pode ser parcialmente aplicado e, se não conseguir excluir os arquivos swf, você poderá fazer isso manualmente. Ou, se ele não atualizar os arquivos downloaderporque você excluiu esse diretório, você pode simplesmente ignorá-lo.

1. vi PATCH_SUPEE-8788_CE_1.8.1.0_v1-2016-10-11-06-54-44.sh(ou nome de arquivo semelhante) altere _apply_revert_patch dry-runpara se parecer #_apply_revert_patch dry-run

2. execute o patch emitindo ./PATCH_SUPEE-8788_CE_1.8.1.0_v1-2016-10-11-06-54-44.sh

Isso irá corrigir seus arquivos

3. Comentar _apply_revert_patchpara#_apply_revert_patch

4. execute o patch novamente, para adicionar a app/etc/app/etc/applied.patches.listentrada

5. grep para todos os arquivos .rej com

   git status | grep *.rej

6. trabalhar manualmente nessas mudanças

Problemas após a aplicação do patch

Chaves de formulário

• Para versões do Magento anteriores à 1.8, há alterações nos frontend/base/defaultmodelos. Certifique-se de aplicar manualmente as mesmas alterações no seu tema, se ele substituir esses arquivos

  Mais especificamente, uma chave de formulário foi adicionada para ações de front-end, como:

  • Removendo um item da lista de desejos
  • Excluindo um endereço de cliente da visualização da loja
  • Atualizando um item de cotação em sua cesta

  Veja esta resposta de @LukeRogers se você encontrar problemas com essas ações.

Uploader personalizado

O Unirgy_Rapidflow e outras extensões com formulários de upload personalizados não estão mais funcionando.

Veja esta resposta por @mpchadwick e comentário por @lloiacono

Eu fixo-lo substituindo $this->getUploader()->getConfig()com $this->getUploader()->getUploaderConfig()noUnirgy_RapidFlow_Block_Adminhtml_Profile_Edit_Tab_Upload

Para descobrir se alguma das suas extensões usa isso, você pode executar o seguinte na linha de comando:

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

Mensagens de erro relatadas

• Erro fatal do PHP: Chamada para a função indefinida hash_equals ()

  acontece se você estiver em uma versão PHP antes de 5.6 e substituir code/core/Mage/core/functions.phpno code/local/Mage/core/functions.php(que poderia ser o caso se você usar extensões Fishpig). Veja esta resposta por @ClaudiuCreanga

Problemas resolvidos na v2 do patch

Se você encontrar algum desses problemas, provavelmente usa a versão 1 do patch ("v1" no nome do arquivo). Faça o download do patch novamente para obter a "v2", que corrige estes problemas:

• Houve um problema de compatibilidade com SUPEE-3941 e downloader/lib/Mage/HTTP/Client/Curl.php

• 'Exceção' com a mensagem 'Tipo de dados não suportado N' em /lib/Unserialize/Reader/ArrValue.php

• O patch para o EE 1.14.2.0 acidentalmente continha um novo arquivo test_oauth.php que você deveria excluir! Veja esta resposta por @MatthiasZeis

Se você pegar

Call to undefined function hash_equals() error

mesmo se o seu patch foi bem-sucedido, isso pode significar que você copiou o functions.php app/code/local/Mage/Core.

Você também precisará inserir essa função porque esse arquivo substitui a principal.

Então insira no app/code/local/Mage/Core/functions.phpfinal:

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

Em PATCH_SUPEE-8788_EE_1.14.2.0_v1-2016-10-10-02-27-03.sh, um arquivo test_oauth.phpé criado no diretório raiz do Magento. Você deseja excluir este (ou pelo menos não implementá-lo na produção) porque pode expor um rastreamento completo da pilha de exceções à pessoa que chama o URL https: //thedomain.tld/test_oauth.php .

ISTO SE APLICA A 1.7 VERSÕES MAGENTO

Se você estiver executando a 1.7.0.2, a versão 2 do SUPEE 8788 falhará na linha 372, tentando aplicar as alterações em 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

As instruções dizem que devemos reverter o SUPEE-1533 e instalar o SUPEE-3941

PROBLEMA: SUPEE-3941 está disponível apenas para Magento CE 1.8-1.9. Você pode tentar aplicá-lo para 1.7, e ele será aplicado. eu acho quedesenvolvedores de patches O Magento deve lançar uma versão 3 do SUPEE-8788 para aqueles que executam o magento abaixo de 1,8 ou criar um patch SUPEE-3941 adicional projetado para a versão abaixo de 1,8.

A versão 1 do SUPEE-8788 não teve o Curl.phperro no 1.7.0.2 (eu testei em muitas instalações)

Dica: se você estiver enfrentando erros .swf no final, certifique-se de compactar seu patch, fazer o upload para o servidor e descompactar o erro.SWF desaparecerá.

ATUALIZAR:

Magento disse que basicamente não há problema em instalar o patch SUPEE-3941 em uma versão Magento 1.7.0.2 para evitar erros na aplicação do SUPEE-8788

Original DashboardController.php (1.7.0.2- Não em cache, fresco do magento)

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

1533 Patched DashboardController.php contém a seguinte alteração

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

O patch 8788 faz a seguinte alteração no DashboardController.php

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

Como você pode ver, o 8788 possui uma alteração modificada em comparação com 1533, NÃO tenho certeza de qual é o ideal para modificar o arquivo, como sugere o mpchadwick, substituindo manualmente a alteração 8788 por 1533 após a instalação do 8788. Removendo basicamente a alteração 8788.

Alguma sugestão?

Meio tentado a sinalizar este post como principalmente baseado em opiniões ou sem uma resposta clara;)

As chaves de formulário foram adicionadas a alguns controladores, o número varia dependendo da sua versão do magento.

Se você tiver problemas

• Removendo um item da lista de desejos
• Excluindo um endereço de cliente da visualização da loja
• Atualizando um item de cotação em sua cesta

Você precisará verificar o .phtmlarquivo de temas e verificar o POSTparâmetro chave do formulário para que ele passe na verificação nas ações do controlador, como:

class Mage_Checkout_CartController extends Mage_Core_Controller_Front_Action

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

Esses problemas provocaram muitas pessoas em patches anteriores; os temas de front-end personalizados com modelos substituídos são facilmente perdidos ao aplicar os patches.

As chaves do formulário são frequentemente adicionadas ao .phtmlmodelo que contém o formulário como um extra, inputcomo

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

Eu encontrei o mesmo problema no swf em 1.9.2.4.

Fox Fixed - Siga os passos abaixo.

Etapa 1. Faça o download do arquivo SSH do patch de segurança 8788 para este link: - https://magento.com/tech-resources/downloads/magento/

Etapa 2. Após o download do arquivo SSH do patch de segurança 8788, coloque em uma pasta e faça o mesmo arquivo zip da pasta.

Etapa 3. Faça o upload da pasta Zip para a pasta magento raiz e descompacte através do SSH Putty.

Etapa 4. Execute o patch: - $ bash PATCH_SUPEE-8788_CE_1.9.2.4_v1-2016-10-11-07-03-46.sh

* Nota: o arquivo de patch contém arquivos binários inteiros em formato de texto. É por isso que quando você envia o arquivo SSH do patch de segurança 8788 sem o arquivo zip, o mesmo arquivo estará corrompido. *

Depois de aplicar a SUPEE-8788, não era mais possível carregar perfis "Importar" usando o Unirgy_RapidFlow 2.0.0.18, obtendo um erro 500 (nada nos logs do Apache ou HTTPD).

Ainda estou no processo de depuração e trabalhando com o Unirgy para resolver, mas parece que o bloco de upload está causando o problema ( Unirgy_RapidFlow_Block_Adminhtml_Profile_Edit_Tab_Upload).

O patch introduziu várias alterações Mage_Adminhtml_Block_Catalog_Product_Helper_Form_Gallery_Contentno pai.

Além do uRapidFlow, outros módulos de terceiros que permitem o upload de arquivos podem ser interrompidos como resultado do SUPEE-8788.

Recebi a seguinte mensagem ao executar o script de patch:

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

Acho que isso ocorreu porque renomeei a pasta "downloader", seguindo as recomendações de https://www.magereport.com .

Renomeei temporariamente a pasta para "downloader", apliquei o patch corretamente e o renomeei com seu nome secreto.

O patch no 1.9.0.0 também falha (provavelmente 1.8.0.0 até 1.9.0.1 afetado) por causa do SUPEE-3941. 3941 corrige o downloader / lib / Mage / HTTP / Client / Curl.php e agora o 8788 falha.

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

Solução alternativa para 1.9.0.1 abaixo. As alterações são muito completas, talvez seja necessário ajustar o próprio patch 8788.

edit: edite o patch, procure por Curl.php e substitua

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 

com

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

Aqui está o que eu estou recebendo

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 o Magento estará lançando a versão atualizada do SUPEE 8788, para corrigir a compatibilidade do SUPEE 1533. Não tenho certeza se é uma boa idéia aplicar correções manuais agora. Alterações manuais podem comprometer futuras atualizações de patches. Gostaria de ouvir seus pensamentos.

Foi confirmado pelo Magento Community Manager. No dia 13 de outubro, às 15h EST. Todos os patches das versões abaixo de 1,9 são excluídos da lista de downloads https://www.magentocommerce.com/download?_ga=1.236497153.1889606568.1445610645 Veja o post: https://community.magento.com/t5 / Patches de segurança / SUPEE-8788-AND-SUPEE-1533-Erro incompatível de hunk / mp / 50514 / destaques / false # M1805

Estamos recebendo relatórios dos seguintes novos problemas que não vejo em outras postagens:

• Exceção nos novos releases em alguns casos - a chamada do método addCrumbs () (no caso de getStoreConfig (web / default / show_cms_breadcrumbs) ser indefinido). Não deve afetar o patch, apenas a versão 1.9.3 / 1.14.3

'Exceção' com a mensagem 'Tipo de dados não suportado N' em /lib/Unserialize/Reader/ArrValue.php na 1.9.1.0 e possivelmente versões anteriores quando o patch é aplicado. resolvido na versão 2 do patch.

Atualmente, não há soluções fáceis conhecidas para esses problemas. Estamos trabalhando para resolvê-los em uma nova versão do patch.

O remetente é interrompido quando você carrega o mesmo arquivo para amostras e links ao mesmo tempo para produtos para download. Observe que isso só acontece se você usar o mesmo arquivo nas duas áreas. (Ele costumava funcionar corretamente antes do patch.)

Para reproduzir, edite um produto para download e clique na guia Informações para Download :

1. Abra a linha Amostras do acordeão e procure um arquivo de amostra.
2. Na linha Links do acordeão, procure um link para download
3. Clique em Upload de arquivos na seção Links.

O remetente carrega o arquivo de amostra em vez do arquivo de link para download, e o arquivo que você procurou na seção de link para download desaparece.

Consegui reproduzir isso em uma baunilha, com a instalação do 1.7.0.2 CE corrigido.

Sim, encontrei outro problema ao fazer o login, ele sempre retornará isso:

Descobri que é porque na classe 165 da linha Enterprise_Pci_Model_Observer,

Ao invés de:

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

Isso irá corrigir:

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

Como não gosto de mudar o núcleo (nem mesmo mudar para o local), é melhor que o Magento conserte ou esclareça isso. No momento, o meu está criando novas extensões para estender isso e criar a função getPassword () (já que quero garantir que todos os desenvolvedores usem o modo Desenvolvedor).

Editando arquivo de correção

Se alguém precisar editar o arquivo do patch, você não deve fazê-lo em um editor, pois isso quebrará os arquivos binários encapsulados no patch.

Se você tem uma linha de comando à mão, ou seja. linux / * unix tente usar o sedutilitário para remover linhas específicas.

Props para @fooman para obter a dica. Veja sua essência original

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

Isso excluirá as linhas 101 a 111 inclusive.

Problemas de envio de formulários.

Se você estiver vendo o problema acima mencionado, também poderá:

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

Para obter mais informações, consulte este post. O que é getBlockHtml ('formkey')?

CE 1.6.2.0 e SUPEE-3941

Para aplicar o patch de segurança SUPEE-8788 (Versão 2), ( http://devdocs.magento.com/guides/m1x/other/ht_install-patches.html#apply-8788-new ), é recomendável aplicar o SUPEE-3941 primeiro .

No entanto, na página de download do patch, não há patch SUPEE-3941 para o CE 1.6.2.0. O patch está disponível apenas para CE 1.8 e 1.9.

Conforme mencionado neste tópico, parece aceitável aplicar o patch SUPEE-3941 disponível (para CE 1.8 e 1.9) no CE 1.7.

Também é bom aplicar o SUPEE-3941 (para CE 1.8 e 1.9) no CE 1.6.2.0? Tentei aplicá-lo no CE 1.6.2.0 e obtive o seguinte erro:

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

Um pouco tarde, mas encontramos um problema no patch SUPEE-8788 V2, que pelo menos se aplica aos arquivos de patch do Magento 1.7.0.2 e 1.7.0.1. Provavelmente, isso também se aplica a todas as versões anteriores para as quais existe uma versão de patch. A versão Magento da 1.8 em diante não é afetada, pois o patch não altera os modelos para eles.

Em detalhe

Falta ao patch uma chave de formulário para o arquivo app/design/frontend/base/default/template/persistent/checkout/onepage/login.phtml

Sem ele, o login não funciona no checkout de uma página (ele simplesmente não funciona sem erros).

Consertar

Uma chave de formulário deve ser inserida como no seguinte 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>

Para o site corrigido 1533, substitua a linha abaixo 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));

Basicamente, apenas reverteu o 1533 e deixou 8788 junto.

A captura do Authorize.net é interrompida após a aplicação do patch. A autorização funciona bem, mas ao capturar o pagamento na fatura, é apresentado "Erro de gateway: é necessário o número do cartão de crédito" . O arquivo de log de pagamento mostra o x_typevalor do parâmetro passa auth_captureagora, mas antes do patch, o prior_auth_captureque funcionava bem. Alguém está com esse problema?

ATUALIZAÇÃO: Correção para este problema - Authorize.net não captura

Consertei uma cópia do Magento 1.9.2.4 usando SSH com SUPEE-8788 Consertei outra cópia do Magento 1.9.2.4 usando ftp com SUPEE-8788 Consertei uma cópia do Magento 1.9.1.0 usando SSH com SUPEE-8788 usou uma nova cópia do magento 1.9.3.1

Em todos esses sites magento com SUPEE-8788, experimento o mesmo problema (talvez um bug do patch)

Usando produtos para download e acessando Informações para download-> Amostras quando tento Adicionar uma nova linha (uma ou mais) clicando no "X", não consigo mais remover a linha

Eu não sou tão especialista em Magento, estou tentando encontrar uma solução. Se eu achar que vou postar, se algum de vocês tiver alguma solução, será muito útil para mim

ATUALIZAÇÃO : usando o inspetor Chrome, vi este erro:

******* ENCONTREI A SOLUÇÃO *******

Passei 2 dias e espero que isso possa ajudar outra pessoa, isso é um bug no SUPEE-8788

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

Encontre a função

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

e substitua-o por

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

Isso resolverá o erro

O PATCH_SUPEE-8788_CE_1.9.2.1_v1-2016-10-11-07-00-43 foi aplicado na cópia de teste do site executando 1.9.2.1 e a verificação foi interrompida. Inverta o patch e o checkout funcionará normalmente novamente.

Ao enviar o pedido, você volta ao carrinho em vez do sucesso da finalização da compra. Acho que vou esperar a versão .1 antes de tentar novamente.

Um novo e-mail do Magento nas primeiras horas da manhã indica que eles estarão produzindo novas versões de patches para lidar com os problemas de compatibilidade SUPEE-1533 e SUPEE-3941. Então, talvez apenas segure seus cavalos um pouco.

ENTERPRISE EDITION 1.14.3, COMMUNITY EDITION 1.9.3 e SUPEE-8788 Enterprise Edition 1.14.3 e Community Edition 1.9.3 oferecem mais de 120 melhorias de qualidade, além de suporte ao PHP 5.6. Eles também resolvem problemas críticos de segurança, incluindo: ...

... O patch SUPEE-8788 soluciona esses problemas de segurança nas versões anteriores do Magento. Infelizmente, descobrimos que os patches SUPEE-8788 para versões do Community Edition 1.8 e versões anteriores e Enterprise Edition 1.13 e versões anteriores falham se uma loja tiver aplicado anteriormente os patches de segurança SUPEE-1533 ou SUPEE-3941. Estamos trabalhando para corrigir esse problema e forneceremos novos patches nos próximos um a três dias. Até então, estamos removendo essas versões do patch SUPEE-8788 da distribuição ...

No entanto, estou preocupado que minhas versões ativas do Magento estejam entre o CE 1.9.3 que eles dizem que funciona e as novas versões em breve para a V1.8 e versões posteriores. Entrei em contato com eles, então vou esperar e ver o que eles dizem.

Eu não sou um grande fã de patches. Pessoalmente, removo todos os arquivos Magento de seus diretórios e carrego a nova versão (usando um script de shell). Todos os arquivos instalados ao longo dos anos, como módulos ou temas, ainda estão lá. Para o banco de dados, faço uma comparação entre novas versões instaladas. Uma maneira é criar ou remover as colunas / tabelas no banco de dados, a outra maneira é instalar novamente o Magento, apenas alterando o nome do arquivo /app/etc/local.xml. Eu prefiro o primeiro.

Se você não alterar a estrutura do banco de dados para a versão 1.9.3.0, ocorrerá alguns erros ou não poderá carregar a área de administração. Se alguém estiver interessado em algumas comparações de diretórios e bancos de dados Magento entre o Magento CE 1.9.2.4 e 1.9.3.0, basta baixar o arquivo aqui:

Comparação Magento: versões 1.9.2.4 - 1.9.3.0

Existem dois arquivos html com resultados visuais muito bons.

Atualizei 4 lojas hoje usando meu método em vez de aplicar patches. Todos estão funcionando sem problemas.

Não tendo sorte na maioria das instalações do Magento CE (6 no total). Versões diferentes: 1.9.1, 1.9.0.1, 1.8.1.

Fiz o download do patch 8788 correspondente correto. Fiz questão de reverter 1533 quando aplicável.

Eu recebo as seguintes saídas importantes que são questionáveis:

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.

... verificando arquivo app / code / core / Mage / Adminhtml / controllers / IndexController.php O pedaço 1 foi bem-sucedido em 373 (deslocamento -19 linhas). ...

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

O mesmo que acima para: lib / Unserialize / Reader / Arr.php lib / Unserialize / Reader / ArrValue.php E diz que esses pedaços foram ignorados.

nota: não há nada no meu diretório Unserialized / Reader. Completamente vazio. nota: o Curl.php está no diretório do downloader. Não renomeado. Ele termina, mas não vejo os arquivos SWF removidos. Não vejo o patch aplicado na lista de applic.patches.list

Não faz sentido.

Eu atualizei cerca de 10 sites hoje e todos os sites em que o patch do SUPEE-8788 falhou tiveram o SUPEE-6788 MISSING .

Isso resultou em (exemplo) o seguinte erro:

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

Após a instalação do SUPEE-6788, o SUPEE-8788 foi corrigido corretamente.

Se você está recebendo Hunk #1 failederro xxx, foi o que eu fiz

Eu tenho Hunk #1 failed at 373. Erro !! depois da linha

verificando o downloader de arquivo / lib / Mage / HTTP / Client / Curl.php

Então, verifiquei o Curl.phparquivo e descobri que havia modificado o arquivo antes (comentei uma linha). Eu restaurei o arquivo original e executei o patch novamente. Então o patch foi bem sucedido. ;).

Então eu verifiquei:

/app/etc/applied.patches.list e tudo parece bom