La propuesta de actualizar automáticamente las versiones antiguas de WordPress a 4.7 genera un debate acalorado

Los colaboradores, desarrolladores y miembros de la comunidad de WordPress están debatiendo actualmente una propuesta para implementar una nueva política con respecto al soporte de seguridad para versiones anteriores. La discusión comenzó la semana pasada cuando el líder del equipo de seguridad, Jake Spurlock, solicitó comentarios sobre diferentes enfoques para respaldar las correcciones de seguridad en versiones anteriores. Siguiendo esta discusión, Ian Dunn, un colaborador de tiempo completo del núcleo de WordPress, patrocinado por Automattic, ha publicado una propuesta para avanzar con una nueva política:

Admite las últimas 6 versiones y actualiza automáticamente los sitios no compatibles a la versión compatible más antigua.

Eso significaría que las versiones admitidas actualmente serían 4.7 - 5.2, y las ramas 3.7 - 4.6 eventualmente se actualizarían automáticamente a 4.7.

En la práctica, eso proporcionaría aproximadamente 2 años de soporte para cada rama, y ​​aproximadamente el 10% de los sitios actuales eventualmente se actualizarían automáticamente a 4.7. Una vez que se publique la versión 5.3, la versión compatible más antigua se convertirá en la 4.8.

Dunn describió un plan detallado para implementar la nueva política que implica probar un pequeño subconjunto de sitios para identificar problemas antes de actualizar gradualmente los sitios más antiguos de una versión principal a la siguiente (no todos a la vez). Los administradores del sitio serían notificados al menos 30 días antes de las actualizaciones automáticas con correos electrónicos y avisos en el administrador que también ofrecerían la oportunidad de optar por no participar.

La propuesta ha recibido docenas de comentarios, con algunos contribuyentes a favor, algunos a favor de las modificaciones en el lanzamiento y otros que se oponen inequívocamente a la idea de actualizar automáticamente los sitios antiguos a las versiones principales.

Una de las preocupaciones predominantes es que muchos administradores no recibirán ningún aviso debido a que las direcciones de correo electrónico no funcionan o no inician sesión en sus paneles de administración con la frecuencia suficiente. Los opositores también sostienen que, aunque existen alternativas para los sitios que no se actualizan, algunos sitios pueden estar dañados de una manera que WordPress no puede detectar, debido a problemas con complementos o temas.

“Un aviso de back-end ni siquiera comenzará a compensar la falta de comunicación confiable por correo electrónico”, dijo Glenn Messersmith. “Hay toneladas de propietarios de sitios que nunca se aventuran en el back-end una vez que se ha desarrollado su sitio. Estas son las mismas personas que tampoco recibirán notificaciones por correo electrónico porque la dirección de correo electrónico es la de un desarrollador desaparecido hace mucho tiempo.

“No hay forma de que ningún tipo de detección de errores pueda actuar como una red de seguridad para aquellos que nunca vieron ninguna notificación. Hay todo tipo de formas en que el propietario de un sitio puede considerar que su sitio está 'roto' y que un script de actualización posiblemente no podría detectar".

En respuesta a las preocupaciones sobre la ruptura de sitios abandonados o los administradores que dependen en gran medida de un complemento que ha sido abandonado, Dunn estuvo de acuerdo en que este tipo de situaciones pueden ser inevitables con la propuesta actual.

“Definitivamente puedo simpatizar con esa situación, pero tenemos que trazar la línea en alguna parte”, dijo Dunn. “No tenemos recursos ilimitados y la política actual tiene efectos perjudiciales para todo el ecosistema de WordPress.

“En realidad, las elecciones nunca son entre algo puramente bueno y algo puramente malo; siempre están entre compensaciones que compiten.

“Definitivamente estoy de acuerdo en que es malo si un pequeño número de propietarios de sitios tienen que hacer un trabajo adicional para actualizar su sitio, pero en el esquema general, eso es mucho, mucho mejor que tener a nuestro equipo de seguridad obstaculizado por una política de soporte extremadamente onerosa. .”

El autor de la propuesta afirma que "nadie se vería obligado a actualizar"; Los opositores argumentan que exigir a los usuarios que opten por no participar no es consentimiento

Además del problema de la posibilidad de romper sitios, aquellos que se oponen a la propuesta no están de acuerdo con WordPress forzando una actualización sin obtener el consentimiento explícito de los administradores del sitio. Brindar a los usuarios una forma de optar por las actualizaciones automáticas para las principales versiones principales es uno de los nueve proyectos que Matt Mullenweg había identificado para trabajar en 2019. Sin embargo, el plan para esta propuesta es más agresivo porque requeriría propietarios de sitios en la versión 3.7. – 4.6 sucursales para optar por no participar si no desean que se actualicen automáticamente de forma incremental a 4.7.

“Todavía conservan la agencia sin importar qué, nadie se vería obligado a actualizar, todos conservan el control de su sitio y pueden optar por no participar si lo desean”, dijo Dunn. “Algo que está activado de forma predeterminada es muy diferente de obligar a alguien a hacer algo. Haríamos que sea muy fácil optar por no participar, solo instale un complemento, no se requiere configuración, y las instrucciones para optar por no participar se incluirían en cada correo electrónico y aviso de administrador ".

Dunn aclaró aún más en un comentario sobre quién recibiría estas actualizaciones:

Nadie se vería obligado, sino que sería un proceso de exclusión voluntaria. Si alguien ya ha deshabilitado las actualizaciones automáticas a las versiones principales, eso se respetará y su sitio no se actualizará.

Si alguien hizo clic en el enlace de exclusión en el correo electrónico, o si hizo clic en el botón de exclusión en el aviso del administrador, las actualizaciones también se desactivarán.

Las únicas personas que recibirían las actualizaciones son las que:

1) Quiere la actualización
2) no me importa
3) Han abandonado sus sitios o cuentas de correo electrónico

Varios participantes en la discusión preguntaron por qué el proceso de obtener estos sitios en 4.7 no puede optar por consentimiento, en lugar de forzar la actualización en aquellos que no optan por no participar. No importa cuán conveniente sea el mecanismo de exclusión voluntaria, tener uno en su lugar no constituye consentimiento. Muchos propietarios de sitios que se verán obligados a participar en este proceso pensaron que estarían seguros al optar por actualizaciones de mantenimiento y seguridad y dejar que sus sitios realicen "actualizaciones mientras duermes", como se describe en la publicación de la versión 3.7.

“Los sitios inseguros son malos, pero podría decirse que la ampliación retrospectiva del poder otorgado a uno mismo por este mecanismo es peor”, dijo el creador de UpdraftPlus, David Anderson. “Potencialmente podría dañar la confianza y la reputación más que la inseguridad. Yo diría que sería mejor que los avisos feos e inamovibles del panel de control enorme en las versiones anteriores advirtieran sobre el próximo abandono + la necesidad de actualizar. Deje que el propietario del sitio asuma la responsabilidad. No juegues a la niñera, abuses de la confianza, rompas sitios y luego escribas publicaciones de blog sobre cómo fue necesario el daño colateral. Nadie que se despierte con un sitio roto estará contento con eso”.

Andrew Nacin, líder de lanzamiento de WordPress 3.7 y coautor de la función de actualizaciones automáticas en segundo plano de WordPress, alentó a quienes están detrás de la propuesta a aclarar que WordPress solo es compatible con la última versión principal y nunca ha sido compatible oficialmente con versiones anteriores.

“Se necesita mucho trabajo, sin duda, para respaldar”, dijo Nacin. “Pero aún debemos ceñirnos a nuestra estrella polar, que es que WordPress es compatible con versiones anteriores de una versión a otra, que los usuarios de WordPress no deberían preocuparse por la versión que están ejecutando y que deberíamos mantener los sitios actualizados si estamos disponibles."

Nacin ofreció más contexto sobre la estrategia original para introducir actualizaciones automáticas, que incluía pasar gradualmente a tener lanzamientos importantes como actualizaciones automáticas para que todos los sitios finalmente tuvieran la última versión:

En primer lugar, cuando lanzamos por primera vez las actualizaciones automáticas en segundo plano, pensamos que nuestro próximo gran impulso sería llegar a las principales actualizaciones automáticas de lanzamiento en los próximos años. En la práctica, podemos hacer esto en cualquier momento y, de hecho, 3.7 admitía esto como bandera. Pero la idea era que invertiríamos energía en sandboxing, protección de pantalla blanca, mejorar nuestra funcionalidad de reversión, etc., por lo que nuestra tasa de éxito fue tan alta para las versiones principales como para las versiones secundarias. (La tasa de fallas aumenta de manera algo lineal con la cantidad de archivos que deben copiarse, y también se vuelve más compleja cuando es necesario agregar archivos, en lugar de solo cambiarlos). Una vez que hicimos esto, simplemente comenzamos a actualizar todos los sitios. a la última versión y deja de hacer backporting. Obviamente todavía no hemos llegado aquí.

Comentó que, en general, la propuesta es “un gran plan”, pero enfatizó los beneficios de comunicar a los usuarios que es seguro actualizar y que WordPress solo pretende admitir la última versión.

La mayoría de los participantes en la discusión están a favor de que el equipo de seguridad suspenda las correcciones de versiones anteriores de WordPress. La pregunta que permanece sin respuesta para los oponentes es por qué es responsabilidad de WordPress forzar la actualización de los sitios más antiguos.

“No creo que deba ser decisión de WordPress actualizar los sitios que no manejan a versiones principales o de última hora, pero creo que se debe detener el mantenimiento de esas sucursales”, dijo Will Stocks. “Usted (WordPress) no es dueño de la infraestructura o los procesos comerciales, ni comprende el soporte existente para administrar esos sitios. También hay una razón por la cual esos sitios todavía están en esa versión hoy y no se han actualizado más allá”.

Hay otros enfoques que aún pueden trazar una línea para respetar los recursos limitados del equipo de seguridad sin forzar ninguna actualización no consensuada de las versiones principales. Rachel Cherry, directora de WPCampus, comentó sobre la propuesta e instó encarecidamente a WordPress a establecer el consentimiento antes de actualizar estos sitios:

Nos estamos metiendo en la maleza de si las actualizaciones forzadas causarán o no problemas tecnológicos y perderemos el problema real por completo.

Estamos hablando de forzar la actualización del software de las personas cuando no han dado su consentimiento.

¿Y con qué fin? ¿Cuál es el verdadero problema aquí? ¿Porque no queremos preocuparnos por actualizar versiones antiguas?

Hay otras formas de resolver este problema.

Podemos hacer una política clara con respecto al soporte de EOL para lanzamientos.

Podemos agregar una configuración al núcleo que le permita al usuario elegir si desea o no actualizaciones automáticas y, en el futuro, ese es el tomador de decisiones. Entonces tenemos el consentimiento.

Podemos trabajar en educación y comunicación con respecto a las actualizaciones.

Podemos enviar correos electrónicos a las personas para informarles que su sitio está desactualizado e inseguro y que deben actualizarlo lo antes posible, junto con enlaces a educación y mejores prácticas. Si todavía necesitan ayuda, aliéntelos a buscar a un profesional.

Podemos solucionar este problema para seguir adelante, pero no tenemos un consentimiento retroactivo implícito solo porque nunca implementamos un mecanismo de permiso.

Si alguien no actualizó su sitio, lo hizo por una razón. O la indiferencia. De cualquier manera, no tenemos derecho a entrar así y modificar los sitios web de las personas.

Los participantes en la discusión todavía están luchando con las implicaciones potenciales del cambio de política propuesto. Las actualizaciones menores han demostrado ser muy confiables como actualizaciones automáticas. Dunn informó que la actualización automática 3.7.29 solo tuvo una falla que tuvo que revertirse a 3.7.28. El uso del sistema de actualización automática para enviar actualizaciones importantes a sitios tan antiguos como estos aún no se ha probado a fondo.

"Ya sea que actualicemos automáticamente o no las versiones 3.7 -> 5.x, apoyo totalmente dejar en claro que esto es algo que esperamos comenzar a hacer en el futuro (5.x -> x.x+)", Jeremy Felt comentó la propuesta. "El trabajo de probar la infraestructura y el código para respaldar esto debe hacerse absolutamente de cualquier manera". Felt también dijo que apreciaba la programación de implementación escalonada para los lanzamientos propuestos, así como el plan para proporcionar un complemento con soporte oficial para deshabilitar las actualizaciones automáticas.

La discusión aún está abierta sobre la propuesta, pero hasta ahora parece haber un desacuerdo fundamental entre los participantes sobre si WordPress tiene derecho a forzar actualizaciones de versiones principales sin consentimiento explícito, incluso si es con la intención de evitar que los propietarios de sitios sean potencialmente pirateados. .

“Una cosa es segura, parece ser una preocupación mayoritaria hasta el momento, mientras que a muchos de nosotros nos gustan estas nobles intenciones, no estoy tan seguro de que ser el benévolo señor de Internet sea una buena imagen para que WP avance. ”, dijo el desarrollador de complementos Philip Ingram.