La proposition de mise à jour automatique des anciennes versions de WordPress vers la 4.7 suscite un débat houleux

Les contributeurs, développeurs et membres de la communauté WordPress débattent actuellement d'une proposition visant à mettre en œuvre une nouvelle politique concernant la prise en charge de la sécurité pour les anciennes versions. La discussion a commencé la semaine dernière lorsque le chef de l'équipe de sécurité, Jake Spurlock, a demandé des commentaires sur les différentes approches de rétroportage des correctifs de sécurité vers les anciennes versions. Suite à cette discussion, Ian Dunn, contributeur à temps plein au cœur de WordPress, sponsorisé par Automattic, a publié une proposition pour aller de l'avant avec une nouvelle politique :

Prend en charge les 6 dernières versions et met automatiquement à jour les sites non pris en charge vers la version prise en charge la plus ancienne.

Cela signifierait que les versions actuellement prises en charge seraient 4.7 - 5.2, et les branches 3.7 - 4.6 seraient éventuellement mises à jour automatiquement vers 4.7.

En pratique, cela fournirait environ 2 ans de support pour chaque branche, et environ 10% des sites actuels seraient éventuellement mis à jour automatiquement vers 4.7. Une fois la version 5.3 publiée, la version la plus ancienne prise en charge deviendrait la 4.8.

Dunn a présenté un plan détaillé pour la mise en œuvre de la nouvelle politique qui consiste à tester un petit sous-ensemble de sites pour identifier les problèmes avant de mettre à jour progressivement les anciens sites d'une version majeure à la suivante (pas tous en même temps). Les administrateurs du site seraient informés au moins 30 jours avant les mises à jour automatiques avec des e-mails et des avis dans l'administrateur qui offriraient également la possibilité de se retirer.

La proposition a reçu des dizaines de commentaires, avec certains contributeurs en faveur, certains en faveur de modifications du déploiement et d'autres qui s'opposent sans équivoque à l'idée de mettre à jour automatiquement les anciens sites vers des versions majeures.

L'une des préoccupations dominantes est que de nombreux administrateurs ne recevront aucune notification en raison d'adresses e-mail non fonctionnelles ou de ne pas se connecter assez fréquemment à leurs tableaux de bord d'administration. Les opposants soutiennent également que même s'il existe des solutions de repli pour les sites qui ne parviennent pas à se mettre à niveau, certains sites peuvent être endommagés d'une manière que WordPress ne peut pas détecter, en raison de problèmes avec des plugins ou des thèmes.

"Un avis de back-end ne commencera même pas à compenser le manque de communication par e-mail fiable", a déclaré Glenn Messersmith. "Il y a des tonnes de propriétaires de sites qui ne s'aventurent jamais dans le back-end une fois que leur site a été développé. Ce sont ces mêmes personnes qui ne recevront pas non plus de notifications par e-mail, car l'adresse e-mail est celle d'un développeur disparu depuis longtemps.

"Il est impossible qu'une sorte de détection d'erreur puisse servir de filet de sécurité pour ceux qui n'ont jamais vu de notifications. Un propriétaire de site peut considérer son site comme «cassé» de toutes sortes de façons qu'un script de mise à jour ne pourrait pas détecter.

En réponse aux préoccupations concernant la rupture de sites abandonnés ou les administrateurs s'appuyant fortement sur un plugin qui a été abandonné, Dunn a convenu que ces types de situations peuvent être inévitables dans le cadre de la proposition actuelle.

"Je peux certainement sympathiser avec cette situation, mais nous devons tracer la ligne quelque part", a déclaré Dunn. « Nous n'avons pas de ressources illimitées et la politique actuelle a des effets néfastes sur l'ensemble de l'écosystème WordPress.

« En réalité, les choix ne sont jamais entre une chose purement bonne et une chose purement mauvaise ; ils sont toujours entre des compromis concurrents.

"Je suis tout à fait d'accord que c'est mauvais si un petit nombre de propriétaires de sites doivent faire un travail supplémentaire pour mettre à niveau leur site, mais dans l'ensemble, c'est beaucoup, beaucoup mieux que d'avoir notre équipe de sécurité gênée par une politique de support extrêmement onéreuse .”

L'auteur de la proposition affirme que "personne ne serait obligé de mettre à jour ;" Les opposants soutiennent que demander aux utilisateurs de se retirer n'est pas un consentement

En plus du problème de casser éventuellement des sites, ceux qui s'opposent à la proposition ne sont pas d'accord avec WordPress forçant une mise à jour sans obtenir le consentement explicite des administrateurs du site. Fournir aux utilisateurs un moyen d'opter pour des mises à jour automatiques pour les principales versions de base est l'un des neuf projets sur lesquels Matt Mullenweg avait identifié pour travailler en 2019. Cependant, le plan de cette proposition est plus agressif en ce sens qu'il nécessiterait des propriétaires de sites sur le 3.7 – Les branches 4.6 peuvent se désabonner si elles ne souhaitent pas être mises à jour automatiquement vers la version 4.7.

"Ils conservent leur agence quoi qu'il arrive, personne ne serait obligé de mettre à jour, tout le monde garde le contrôle de son site et peut se retirer s'il le souhaite", a déclaré Dunn. "Quelque chose étant activé par défaut est très différent de forcer quelqu'un à faire quelque chose. Nous rendrions la désactivation très facile – il suffit d'installer un plugin, aucune configuration requise – et les instructions de désactivation seraient incluses dans chaque e-mail et avis d'administration.

Dunn a précisé dans un commentaire qui recevrait ces mises à jour :

Personne ne serait forcé, il s'agirait plutôt d'un processus d'opt-out. Si quelqu'un a déjà désactivé les mises à jour automatiques des versions majeures, cela sera respecté et son site ne sera pas mis à jour.

Si quelqu'un cliquait sur le lien de désinscription dans l'e-mail ou s'il cliquait sur le bouton de désinscription dans l'avis d'administration, les mises à jour seraient également désactivées.

Les seules personnes qui recevraient les mises à jour sont celles qui :

1) Vous voulez la mise à jour
2) Je m'en fiche
3) Ont abandonné leurs sites ou comptes de messagerie

Plusieurs participants à la discussion ont demandé pourquoi le processus d'obtention de ces sites sur 4.7 ne peut pas être opt-in pour le consentement, au lieu de forcer la mise à jour sur ceux qui ne se désinscrivent pas. Peu importe la commodité du mécanisme de retrait, le fait d'en avoir un ne constitue pas un consentement. De nombreux propriétaires de sites qui seront contraints à ce processus pensaient qu'ils seraient en sécurité en optant pour des mises à jour de maintenance et de sécurité et en laissant leurs sites effectuer des "mises à jour pendant que vous dormez", comme le décrit la publication de la version 3.7.

"Les sites non sécurisés sont mauvais, mais sans doute, élargir rétrospectivement le pouvoir accordé à soi-même par ce mécanisme est pire", a déclaré le créateur d'UpdraftPlus, David Anderson. "Potentiellement, cela pourrait nuire davantage à la confiance et à la réputation qu'à l'insécurité. Je dirais que d'énormes avis laids et inamovibles sur le tableau de bord sur les anciennes versions avertissant de l'abandon prochain + la nécessité de mettre à jour seraient mieux. Laissez le propriétaire du site prendre ses responsabilités. Ne jouez pas à la nounou, n'abusez pas de la confiance, ne cassez pas les sites, puis n'écrivez pas d'articles de blog sur la façon dont il s'agissait de dommages collatéraux nécessaires. Personne qui se réveille avec un site en panne ne sera satisfait de cela.

Andrew Nacin, responsable de la version 3.7 de WordPress et co-auteur de la fonctionnalité de mises à jour automatiques en arrière-plan de WordPress, a encouragé les auteurs de la proposition à préciser que WordPress ne prend en charge que la dernière version majeure et n'a jamais officiellement pris en charge les anciennes versions.

"Il faut certainement beaucoup de travail pour rétroporter", a déclaré Nacin. «Mais nous devons toujours nous en tenir à notre étoile du nord, à savoir que WordPress est rétrocompatible d'une version à l'autre, que les utilisateurs de WordPress ne devraient pas avoir à se soucier de la version qu'ils utilisent et que nous devrions simplement maintenir les sites à jour si nous sommes capables."

Nacin a offert plus de contexte sur la stratégie originale d'introduction des mises à jour automatiques, qui comprenait le passage progressif à des versions majeures en tant que mises à jour automatiques afin que tous les sites soient finalement sur la dernière version :

Tout d'abord, lorsque nous avons publié pour la première fois des mises à jour automatiques en arrière-plan, nous pensions que notre prochaine grande avancée serait d'obtenir des mises à jour automatiques majeures dans les prochaines années. En pratique, nous pouvons le faire à tout moment, et, en effet, 3.7 supportait cela comme un drapeau. Mais l'idée était que nous allions investir de l'énergie dans le sandboxing, la protection de l'écran blanc, l'amélioration de notre fonctionnalité de restauration, etc., donc notre taux de réussite était aussi élevé pour les versions majeures que pour les versions mineures. (Le taux d'échec évolue de manière quelque peu linéaire avec le nombre de fichiers qui doivent être copiés, et devient également plus complexe lorsque des fichiers doivent être ajoutés, plutôt que simplement modifiés.) Une fois que nous avons fait cela, nous commençons simplement à mettre à jour tous les sites à la dernière version et arrêtez le rétroportage. De toute évidence, nous n'en sommes toujours pas là.

Il a commenté que dans l'ensemble, la proposition est "un excellent plan", mais a souligné les avantages de communiquer aux utilisateurs qu'il est sûr de mettre à jour et que WordPress n'a l'intention de prendre en charge que la dernière version.

La plupart des participants à la discussion sont favorables à ce que l'équipe de sécurité cesse de rétroporter les correctifs vers les anciennes versions de WordPress. La question qui reste sans réponse pour les opposants est pourquoi est-ce la responsabilité de WordPress de forcer les sites plus anciens à se mettre à jour.

"Je ne pense pas que ce devrait être la décision de WordPress de mettre à jour les sites qu'ils ne gèrent pas vers des versions majeures/de rupture, mais je pense que le maintien de ces branches devrait être arrêté", a déclaré Will Stocks. "Vous (WordPress) ne possédez pas l'infrastructure ou les processus métier, ou ne comprenez pas le support en place pour gérer ces sites. Il y a aussi une raison pour laquelle ces sites sont toujours sur cette version aujourd'hui et n'ont pas été mis à jour par le passé.

Il existe d'autres approches qui peuvent encore tracer une ligne pour respecter les ressources limitées de l'équipe de sécurité sans forcer les mises à jour non consensuelles des versions majeures. Rachel Cherry, directrice de WPCampus, a commenté la proposition, exhortant fortement WordPress à établir le consentement avant de mettre à jour ces sites :

Nous entrons dans les mauvaises herbes pour savoir si les mises à jour forcées causeront ou non des problèmes techniques et passeront complètement à côté du vrai problème.

Nous discutons de la mise à jour forcée des logiciels des personnes lorsqu'elles n'ont pas donné leur consentement.

Et pour quelle fin ? Quel est le vrai problème ici ? Parce que nous ne voulons pas nous soucier de la mise à jour des anciennes versions ?

Il existe d'autres moyens de résoudre ce problème.

Nous pouvons établir une politique claire concernant le support EOL pour les versions.

Nous pouvons ajouter un paramètre au noyau qui permet à l'utilisateur de choisir s'il souhaite ou non des mises à jour automatiques et, à l'avenir, c'est le décideur. Ensuite, nous avons le consentement.

Nous pouvons travailler sur l'éducation et la communication concernant les mises à jour.

Nous pouvons envoyer un e-mail aux personnes indiquant que leur site est obsolète et non sécurisé et qu'elles doivent mettre à jour dès que possible, ainsi que des liens vers des formations et des meilleures pratiques. S'ils ont encore besoin d'aide, encouragez-les à contacter un professionnel.

Nous pouvons résoudre ce problème pour aller de l'avant, mais nous n'avons pas de consentement rétroactif implicite simplement parce que nous n'avons jamais mis en place de mécanisme d'autorisation.

Si quelqu'un n'a pas mis à jour son site, il l'a fait pour une raison. Ou l'indifférence. Quoi qu'il en soit, nous n'avons pas le droit d'entrer comme ça et de modifier les sites Web des gens.

Les participants à la discussion sont toujours aux prises avec les implications potentielles du changement de politique proposé. Les mises à jour mineures se sont avérées très fiables en tant que mises à jour automatiques. Dunn a signalé que la mise à jour automatique 3.7.29 n'a eu qu'un seul échec qui a dû être annulé vers 3.7.28. L'utilisation du système de mise à jour automatique pour envoyer des mises à jour majeures à des sites aussi anciens n'a pas encore été testée de manière approfondie.

"Que nous mettions ou non à jour automatiquement les versions 3.7 -> 5.x, je soutiens pleinement qu'il soit clair que c'est quelque chose que nous prévoyons de commencer à faire à l'avenir (5.x -> x.x+)", Jeremy Felt a commenté la proposition. "Le travail de test de l'infrastructure et du code pour prendre en charge cela doit absolument être fait dans les deux sens." Felt a également déclaré qu'il appréciait le calendrier de déploiement échelonné des versions proposées ainsi que le projet de fournir un plug-in officiellement pris en charge pour désactiver les mises à jour automatiques.

La discussion est toujours ouverte sur la proposition, mais jusqu'à présent, il semble y avoir un désaccord fondamental entre les participants quant à savoir si WordPress a le droit de forcer les mises à jour majeures de la version sans consentement explicite, même si c'est dans le but d'éviter aux propriétaires de sites d'être potentiellement piratés. .

"Une chose est sûre, cela semble être une préoccupation majoritaire jusqu'à présent, alors que beaucoup d'entre nous sont friands de ces nobles intentions, je ne suis tout simplement pas si sûr qu'être le seigneur bienveillant d'Internet soit une bonne image pour WP aller de l'avant ", a déclaré le développeur du plugin Philip Ingram.