Proposta de atualização automática de versões antigas do WordPress para 4.7 gera um debate acalorado

Colaboradores, desenvolvedores e membros da comunidade do WordPress estão atualmente debatendo uma proposta para implementar uma nova política em relação ao suporte de segurança para versões mais antigas. A discussão começou na semana passada quando o líder da equipe de segurança, Jake Spurlock, pediu feedback sobre diferentes abordagens para fazer backport de correções de segurança para versões mais antigas. Dando continuidade a essa discussão, Ian Dunn, colaborador em tempo integral do núcleo do WordPress, patrocinado pela Automattic, publicou uma proposta para avançar com uma nova política:

Suporta as 6 versões mais recentes e atualiza automaticamente sites não suportados para a versão suportada mais antiga.

Isso significaria que as versões atualmente suportadas seriam 4.7 – 5.2, e as ramificações 3.7 – 4.6 eventualmente seriam atualizadas automaticamente para 4.7.

Na prática, isso forneceria aproximadamente 2 anos de suporte para cada filial e aproximadamente 10% dos sites atuais seriam atualizados automaticamente para 4.7. Assim que a versão 5.3 for lançada, a versão suportada mais antiga se tornará a 4.8.

Dunn esboçou um plano detalhado para implementar a nova política que envolve testar um pequeno subconjunto de sites para identificar problemas antes de atualizar gradualmente os sites mais antigos de uma versão principal para a próxima (não todos de uma vez). Os administradores do site seriam notificados pelo menos 30 dias antes das atualizações automáticas com e-mails e avisos no admin que também ofereceriam a oportunidade de optar por não participar.

A proposta recebeu dezenas de comentários, com alguns colaboradores apoiando, alguns a favor de modificações no lançamento e outros que se opõem inequivocamente à ideia de atualizar automaticamente sites antigos para versões principais.

Uma das preocupações predominantes é que muitos administradores não receberão nenhum aviso devido a endereços de e-mail que não funcionam ou não fazem login em seus painéis de administração com frequência suficiente. Os opositores também afirmam que, embora existam alternativas para sites que falham na atualização, alguns sites podem ser quebrados de uma maneira que o WordPress não consegue detectar, devido a problemas com plugins ou temas.

“Um aviso de back-end nem começará a compensar a falta de comunicação confiável por e-mail”, disse Glenn Messersmith. “Existem muitos proprietários de sites que nunca se aventuram no back-end depois que seu site é desenvolvido. Essas são as mesmas pessoas que não receberão notificações por e-mail porque o endereço de e-mail é o de algum desenvolvedor há muito tempo.

“Não há como qualquer tipo de detecção de erro funcionar como uma rede de segurança para quem nunca viu nenhuma notificação. Há todos os tipos de maneiras que um proprietário de site pode considerar seu site 'quebrado' que um script de atualização não poderia detectar. ”

Em resposta a preocupações sobre quebra de sites abandonados ou administradores que dependem muito de um plugin que foi abandonado, Dunn concordou que esses tipos de situações podem ser inevitáveis ​​sob a proposta atual.

“Eu definitivamente posso simpatizar com essa situação, mas temos que traçar a linha em algum lugar”, disse Dunn. “Não temos recursos ilimitados, e a política atual tem efeitos prejudiciais para todo o ecossistema WordPress.

“Na realidade, as escolhas nunca são entre uma coisa puramente boa e uma coisa puramente ruim; eles estão sempre entre compensações concorrentes.

“Eu definitivamente concordo que é ruim se um pequeno número de proprietários de sites tiver que fazer um trabalho extra para atualizar seu site, mas no grande esquema das coisas, isso é muito, muito melhor do que ter nossa equipe de segurança prejudicada por uma política de suporte extremamente onerosa .”

O autor da proposta afirma que “ninguém seria forçado a atualizar”; Oponentes argumentam que exigir que os usuários desistam não é consentimento

Além do problema de possivelmente quebrar sites, aqueles que se opõem à proposta não estão de acordo com o WordPress forçando uma atualização sem obter o consentimento explícito dos administradores do site. Fornecer aos usuários uma maneira de optar por atualizações automáticas para as principais versões principais é um dos nove projetos que Matt Mullenweg identificou para trabalhar em 2019. No entanto, o plano para esta proposta é mais agressivo, pois exigiria proprietários de sites na versão 3.7 – 4.6 ramificações a serem desativadas se não quiserem ser atualizadas automaticamente de forma incremental para 4.7.

“Eles ainda mantêm a agência, não importa o que aconteça, ninguém seria forçado a atualizar, todos mantêm o controle sobre seu site e podem optar por não participar se quiserem”, disse Dunn. “Algo estar ativado por padrão é muito diferente de forçar alguém a fazer algo. Facilitaríamos muito a desativação - basta instalar um plug-in, sem necessidade de configuração - e as instruções para a desativação seriam incluídas em todos os e-mails e avisos do administrador. ”

Dunn esclareceu ainda mais em um comentário sobre quem receberia essas atualizações:

Ninguém seria forçado, seria um processo de opt-out. Se alguém já desativou as atualizações automáticas para versões principais, isso será respeitado e seu site não será atualizado.

Se alguém clicar no link de desativação no e-mail ou se clicar no botão de desativação no aviso do administrador, as atualizações também serão desativadas.

As únicas pessoas que receberiam as atualizações são aquelas que:

1) Quer a atualização
2) Não se importe
3) Abandonou seus sites ou contas de e-mail

Vários participantes da discussão perguntaram por que o processo de colocar esses sites na versão 4.7 não pode ser opt-in por consentimento, em vez de forçar a atualização para aqueles que não optam por não participar. Não importa quão conveniente seja o mecanismo de exclusão, ter um em vigor não constitui consentimento. Muitos proprietários de sites que serão forçados a esse processo pensaram que estariam seguros ao optar por atualizações de manutenção e segurança e deixar seus sites para realizar “atualizações enquanto você dorme”, como o post da versão 3.7 descreveu o recurso.

“Sites inseguros são ruins, mas sem dúvida, ampliar retrospectivamente o poder concedido a si mesmo por esse mecanismo é pior”, disse o criador do UpdraftPlus, David Anderson. “Potencialmente, isso pode prejudicar a confiança + a reputação mais do que a insegurança. Eu diria que um painel enorme, feio, avisos irremovíveis em versões mais antigas, alertando sobre o próximo abandono + a necessidade de atualização, seria melhor. Deixe o proprietário do site assumir a responsabilidade. Não bancar a babá, abusar da confiança, quebrar sites e depois escrever posts sobre como isso foi um dano colateral necessário. Ninguém que acorda com um site quebrado ficará feliz com isso.”

Andrew Nacin, líder de lançamento do WordPress 3.7 e coautor do recurso de atualizações automáticas em segundo plano do WordPress, encorajou aqueles por trás da proposta a esclarecer que o WordPress suporta apenas a versão principal mais recente e nunca apoiou oficialmente as versões mais antigas.

“É preciso muito trabalho, com certeza, para fazer backport”, disse Nacin. “Mas ainda devemos nos ater à nossa estrela do norte, que é que o WordPress é compatível com versões anteriores de versão para versão, que os usuários do WordPress não precisam se preocupar com a versão que estão executando e que devemos apenas manter os sites atualizados se somos capazes."

Nacin ofereceu mais contexto sobre a estratégia original de introdução de atualizações automáticas, que incluiu a mudança gradual para os principais lançamentos como atualizações automáticas, para que todos os sites eventualmente estivessem na versão mais recente:

Primeiro, quando lançamos as atualizações automáticas em segundo plano, pensamos que nosso próximo grande impulso seria obter atualizações automáticas de versão principal nos próximos anos. Na prática, podemos fazer isso a qualquer momento e, de fato, o 3.7 apoiou isso como um sinalizador. Mas a ideia era investir energia em sandboxing, proteção de tela branca, melhorar nossa funcionalidade de reversão etc., então nossa taxa de sucesso foi tão alta para versões principais quanto para versões secundárias. (A taxa de falha escala um pouco linearmente com o número de arquivos que precisam ser copiados e também fica mais complexa quando os arquivos precisam ser adicionados, em vez de apenas alterados.) Depois de fazer isso, simplesmente começamos a atualizar todos os sites para a versão mais recente e pare o backport. Obviamente ainda não chegamos aqui.

Ele comentou que no geral a proposta é “um ótimo plano”, mas enfatizou os benefícios de comunicar aos usuários que é seguro atualizar e que o WordPress pretende suportar apenas a versão mais recente.

A maioria dos participantes da discussão é a favor da equipe de segurança descontinuar as correções de backport para versões mais antigas do WordPress. A pergunta que permanece sem resposta para os oponentes é por que é responsabilidade do WordPress forçar a atualização de sites mais antigos.

“Não acho que deva ser a decisão do WordPress atualizar sites que eles não conseguem para versões principais/quebradas, mas acho que a manutenção dessas ramificações deve ser interrompida”, disse Will Stocks. “Você (WordPress) não possui a infraestrutura ou os processos de negócios, nem entende o suporte existente para gerenciar esses sites. Há também uma razão pela qual esses sites ainda estão nessa versão hoje e não foram atualizados no passado.”

Existem outras abordagens que ainda podem traçar uma linha para respeitar os recursos limitados da equipe de segurança sem forçar nenhuma atualização não consensual para as versões principais. Rachel Cherry, diretora do WPCampus, comentou a proposta, exortando fortemente o WordPress a estabelecer consentimento antes de atualizar esses sites:

Estamos entrando na questão de saber se as atualizações forçadas causarão ou não problemas técnicos e perdendo completamente o problema real.

Estamos discutindo forçar a atualização do software das pessoas quando elas não deram consentimento.

E para que fim? Qual é o verdadeiro problema aqui? Porque não queremos nos preocupar em atualizar versões antigas?

Existem outras formas de resolver este problema.

Podemos fazer uma política clara em relação ao suporte EOL para lançamentos.

Podemos adicionar uma configuração ao núcleo que permite ao usuário escolher se deseja ou não atualizações automáticas e, daqui para frente, é o tomador de decisões. Então temos consentimento.

Podemos trabalhar na educação e comunicação sobre atualizações.

Podemos enviar um e-mail para as pessoas informando que seu site está desatualizado e inseguro e que elas devem atualizar o mais rápido possível, juntamente com links para educação e práticas recomendadas. Se eles ainda precisarem de ajuda, incentive-os a procurar um profissional.

Podemos corrigir esse problema para avançar, mas não temos consentimento retroativo implícito apenas porque nunca implementamos um mecanismo de permissão.

Se alguém não atualizou seu site, fez isso por um motivo. Ou indiferença. De qualquer forma, não temos o direito de entrar assim e modificar os sites das pessoas.

Os participantes da discussão ainda estão lutando com as implicações potenciais da mudança de política proposta. Atualizações menores provaram ser muito confiáveis ​​como atualizações automáticas. Dunn relatou que a atualização automática 3.7.29 teve apenas uma falha que teve que ser revertida para 3.7.28. O uso do sistema de atualização automática para enviar atualizações importantes para sites tão antigos quanto esses ainda não foi completamente testado.

“Independentemente de atualizarmos ou não automaticamente as versões 3.7 -> 5.x, eu apoio totalmente deixar claro que isso é algo que esperamos começar a fazer no futuro (5.x -> x.x+)”, Jeremy Felt comentou a proposta. “O trabalho de testar a infraestrutura e o código para dar suporte a isso deve ser feito de qualquer maneira.” Felt também disse que apreciou o cronograma de lançamento escalonado para os lançamentos propostos, bem como o plano de fornecer um plug-in oficialmente suportado para desabilitar as atualizações automáticas.

A discussão ainda está aberta sobre a proposta, mas até agora parece haver um desacordo fundamental entre os participantes sobre se o WordPress tem o direito de forçar grandes atualizações de versão sem consentimento explícito, mesmo que seja com a intenção de salvar os proprietários de sites de serem potencialmente hackeados. .

“Uma coisa é certa, parece ser uma preocupação da maioria até agora, enquanto muitos de nós gostamos dessas nobres intenções, não tenho tanta certeza de que ser o senhor benevolente da Internet seja uma boa imagem para o WP seguir em frente. ”, disse o desenvolvedor de plugins Philip Ingram.