Vorschlag zur automatischen Aktualisierung alter WordPress-Versionen auf 4.7 sorgt für hitzige Debatten

WordPress-Mitwirkende, Entwickler und Community-Mitglieder diskutieren derzeit über einen Vorschlag zur Implementierung einer neuen Richtlinie zur Sicherheitsunterstützung für ältere Versionen. Die Diskussion begann letzte Woche, als Jake Spurlock, Leiter des Sicherheitsteams, um Feedback zu verschiedenen Ansätzen für die Rückportierung von Sicherheitsfixes auf ältere Versionen bat. Im Anschluss an diese Diskussion hat Ian Dunn, ein von Automattic gesponserter Vollzeitmitarbeiter des WordPress-Kerns, einen Vorschlag für die Weiterentwicklung einer neuen Richtlinie veröffentlicht:

Unterstützen Sie die neuesten 6 Versionen und aktualisieren Sie nicht unterstützte Websites automatisch auf die älteste unterstützte Version.

Das würde bedeuten, dass die derzeit unterstützten Versionen 4.7 – 5.2 wären und die Zweige 3.7 – 4.6 schließlich automatisch auf 4.7 aktualisiert würden.

In der Praxis würde dies ungefähr 2 Jahre Support für jeden Zweig bieten, und ungefähr 10 % der aktuellen Websites würden schließlich automatisch auf 4.7 aktualisiert. Sobald 5.3 veröffentlicht wird, wird die älteste unterstützte Version 4.8.

Dunn skizzierte einen detaillierten Plan für die Umsetzung der neuen Richtlinie, der das Testen einer kleinen Teilmenge von Websites beinhaltet, um Probleme zu identifizieren, bevor ältere Websites schrittweise von einer Hauptversion auf die nächste aktualisiert werden (nicht alle auf einmal). Site-Administratoren würden mindestens 30 Tage vor den automatischen Updates mit E-Mails und Hinweisen im Admin benachrichtigt, die auch die Möglichkeit bieten würden, sich abzumelden.

Der Vorschlag hat Dutzende von Kommentaren erhalten, von denen einige Befürworter waren, einige für Änderungen am Rollout und andere, die sich eindeutig gegen die Idee der automatischen Aktualisierung alter Websites auf Hauptversionen aussprachen.

Eine der vorherrschenden Bedenken ist, dass viele Administratoren keine Benachrichtigung erhalten, weil ihre E-Mail-Adressen nicht funktionieren oder sie sich nicht häufig genug in ihre Admin-Dashboards einloggen. Gegner behaupten auch, dass, obwohl es Fallbacks für Websites gibt, die nicht aktualisiert werden können, einige Websites aufgrund von Problemen mit Plugins oder Themen auf eine Weise beschädigt sein können, die WordPress nicht erkennen kann.

„Eine Back-End-Benachrichtigung wird den Mangel an zuverlässiger E-Mail-Kommunikation nicht einmal ansatzweise ausgleichen“, sagte Glenn Messersmith. „Es gibt Unmengen von Websitebesitzern, die sich nie ins Backend wagen, sobald ihre Website entwickelt wurde. Dies sind genau die Personen, die auch keine E-Mail-Benachrichtigungen erhalten, da die E-Mail-Adresse die eines längst verstorbenen Entwicklers ist.

„Auf keinen Fall kann irgendeine Art von Fehlererkennung als Sicherheitsnetz für diejenigen dienen, die nie Benachrichtigungen gesehen haben. Es gibt alle möglichen Möglichkeiten, wie ein Websitebesitzer seine Website als „kaputt“ betrachten könnte, was ein Update-Skript möglicherweise nicht erkennen könnte.“

Als Reaktion auf Bedenken, dass aufgegebene Websites kaputt gehen oder Administratoren sich stark auf ein aufgegebenes Plugin verlassen, stimmte Dunn zu, dass diese Art von Situationen im Rahmen des aktuellen Vorschlags möglicherweise unvermeidlich sind.

„Ich kann definitiv mit dieser Situation sympathisieren, aber wir müssen irgendwo die Grenze ziehen“, sagte Dunn. „Wir haben keine unbegrenzten Ressourcen und die aktuelle Politik hat schädliche Auswirkungen auf das gesamte WordPress-Ökosystem.

„In Wirklichkeit gibt es niemals Entscheidungen zwischen einer rein guten und einer rein schlechten Sache; Sie befinden sich immer zwischen konkurrierenden Kompromissen.

„Ich stimme definitiv zu, dass es schlecht ist, wenn eine kleine Anzahl von Websitebesitzern zusätzliche Arbeit leisten muss, um ihre Website zu aktualisieren, aber im Großen und Ganzen ist das viel, viel besser, als unser Sicherheitsteam durch eine extrem belastende Supportrichtlinie behindert zu haben .“

Vorschlagsautor behauptet „Niemand wäre gezwungen zu aktualisieren;“ Gegner argumentieren, dass es keine Zustimmung ist, wenn Benutzer aufgefordert werden, sich abzumelden

Zusätzlich zu dem Problem, dass Websites möglicherweise beschädigt werden, sind die Gegner des Vorschlags nicht an Bord, wenn WordPress ein Update erzwingt, ohne die ausdrückliche Zustimmung der Website-Administratoren einzuholen. Benutzern die Möglichkeit zu geben, sich für automatische Updates für wichtige Core-Releases zu entscheiden, ist eines der neun Projekte, an denen Matt Mullenweg 2019 arbeiten sollte – 4.6-Zweige zum Deaktivieren, wenn sie nicht inkrementell automatisch auf 4.7 aktualisiert werden möchten.

„Sie behalten immer noch die Entscheidungsfreiheit, egal was passiert, niemand wäre gezwungen, Aktualisierungen vorzunehmen, jeder behält die Kontrolle über seine Website und kann sich abmelden, wenn er möchte“, sagte Dunn. „Etwas standardmäßig eingeschaltet ist etwas ganz anderes, als jemanden zu etwas zu zwingen. Wir würden es sehr einfach machen, sich abzumelden – einfach ein Plugin installieren, keine Konfiguration erforderlich – und die Anweisungen zum Abmelden würden in jeder E-Mail und Admin-Benachrichtigung enthalten sein.“

Dunn stellte in einem Kommentar weiter klar, wer diese Updates erhalten würde:

Niemand würde gezwungen, es wäre stattdessen ein Opt-out-Prozess. Wenn jemand automatische Updates auf Hauptversionen bereits deaktiviert hat, würde dies respektiert und seine Website würde nicht aktualisiert.

Wenn jemand auf den Opt-out-Link in der E-Mail oder auf die Opt-out-Schaltfläche im Administratorhinweis geklickt hat, wurden die Updates ebenfalls deaktiviert.

Die einzigen Personen, die die Updates erhalten würden, sind diejenigen, die:

1) Wollen Sie das Update
2) Egal
3) Ihre Websites oder E-Mail-Konten aufgegeben haben

Mehrere Diskussionsteilnehmer fragten, warum der Prozess, diese Sites auf 4.7 zu bringen, nicht für die Zustimmung optiert werden kann, anstatt das Update denen aufzuzwingen, die nicht optieren. Egal wie bequem der Opt-out-Mechanismus ist, ein vorhandener Mechanismus stellt keine Zustimmung dar. Viele Websitebesitzer, die zu diesem Prozess gezwungen werden, dachten, sie wären sicher, wenn sie sich für Wartungs- und Sicherheitsupdates entscheiden und ihre Websites verlassen würden, um „Updates im Schlaf“ durchzuführen, wie der 3.7-Release-Beitrag die Funktion beschrieb.

„Unsichere Websites sind schlecht, aber es ist wohl noch schlimmer, die Macht, die einem selbst durch diesen Mechanismus gewährt wird, nachträglich zu erweitern“, sagte UpdraftPlus-Schöpfer David Anderson. „Potenziell könnte es Vertrauen und Reputation mehr schaden als Unsicherheit. Ich würde argumentieren, dass riesige hässliche, nicht entfernbare Hinweise auf älteren Versionen des Dashboards, die vor dem bevorstehenden Abbruch + der Notwendigkeit eines Updates warnen, besser wären. Lassen Sie den Eigentümer der Website die Verantwortung übernehmen. Nicht Kindermädchen spielen, Vertrauen missbrauchen, Websites brechen und dann Blogbeiträge darüber schreiben, wie es notwendiger Kollateralschaden war. Niemand, der mit einer kaputten Seite aufwacht, wird darüber glücklich sein.“

Andrew Nacin, Release Lead von WordPress 3.7 und Co-Autor der Funktion für automatische Hintergrundaktualisierungen von WordPress, ermutigte die Hintermänner des Vorschlags klarzustellen, dass WordPress nur die neueste Hauptversion unterstützt und ältere Versionen nie offiziell unterstützt hat.

„Es braucht sicher viel Arbeit, um zurückzuportieren“, sagte Nacin. „Aber wir sollten trotzdem an unserem Nordstern festhalten, dass WordPress von Version zu Version abwärtskompatibel ist, dass WordPress-Benutzer sich keine Gedanken darüber machen müssen, welche Version sie verwenden, und dass wir Websites nur dann auf dem neuesten Stand halten sollten wir sind fähig."

Nacin bot mehr Kontext zur ursprünglichen Strategie zur Einführung automatischer Updates, die den schrittweisen Übergang zu Hauptversionen als automatische Updates beinhaltete, damit alle Websites schließlich auf der neuesten Version sein würden:

Erstens, als wir zum ersten Mal automatische Hintergrundupdates veröffentlichten, dachten wir, dass unser nächster großer Schub darin bestehen würde, in den nächsten Jahren automatische Updates für größere Versionen herauszubringen. In der Praxis können wir dies jederzeit tun, und 3.7 hat dies tatsächlich als Flag unterstützt. Aber die Idee war, dass wir Energie in Sandboxing, Whitescreen-Schutz, Verbesserung unserer Rollback-Funktionalität usw. investieren würden, sodass unsere Erfolgsquote für Hauptversionen genauso hoch war wie für Nebenversionen. (Die Fehlerrate skaliert etwas linear mit der Anzahl der Dateien, die kopiert werden müssen, und wird auch komplexer, wenn Dateien hinzugefügt und nicht nur geändert werden müssen.) Sobald wir dies getan haben, würden wir einfach damit beginnen, alle Sites zu aktualisieren auf die neueste Version und stoppen Sie die Rückportierung. Hier sind wir offensichtlich noch nicht angekommen.

Er kommentierte, dass der Vorschlag insgesamt „ein großartiger Plan“ sei, betonte jedoch die Vorteile, den Benutzern mitzuteilen, dass die Aktualisierung sicher ist und dass WordPress nur beabsichtigt, die neueste Version zu unterstützen.

Die meisten Diskussionsteilnehmer befürworten, dass das Sicherheitsteam die Rückportierung von Fixes auf ältere WordPress-Versionen einstellt. Für Gegner bleibt die Frage offen, warum es in der Verantwortung von WordPress liegt, ältere Seiten zur Aktualisierung zu zwingen.

„Ich denke nicht, dass es die Entscheidung von WordPress sein sollte, Websites, die sie nicht verwalten, auf Hauptversionen/Breaking-Versionen zu aktualisieren, aber ich denke, dass die Pflege dieser Zweige eingestellt werden sollte“, sagte Will Stocks. „Sie (WordPress) besitzen weder die Infrastruktur noch die Geschäftsprozesse oder verstehen den Support, der zur Verwaltung dieser Websites vorhanden ist. Es gibt auch einen Grund, warum diese Sites heute noch auf dieser Version sind und in der Vergangenheit nicht aktualisiert wurden.“

Es gibt andere Ansätze, die immer noch eine Grenze ziehen können, um die begrenzten Ressourcen des Sicherheitsteams zu respektieren, ohne nicht einvernehmliche Updates auf Hauptversionen zu erzwingen. Rachel Cherry, Direktorin von WPCampus, kommentierte den Vorschlag und forderte WordPress nachdrücklich auf, vor der Aktualisierung dieser Seiten eine Zustimmung einzuholen:

Wir beschäftigen uns mit der Frage, ob erzwungene Updates technische Probleme verursachen oder nicht, und übersehen das eigentliche Problem insgesamt.

Wir diskutieren darüber, die Software von Personen zu aktualisieren, wenn sie keine Zustimmung gegeben haben.

Und zu welchem ​​Zweck? Was ist hier das eigentliche Problem? Weil wir uns keine Gedanken über die Aktualisierung alter Versionen machen wollen?

Es gibt andere Möglichkeiten, dieses Problem zu lösen.

Wir können eine klare Richtlinie bezüglich der EOL-Unterstützung für Releases festlegen.

Wir können dem Kern eine Einstellung hinzufügen, mit der der Benutzer wählen kann, ob er automatische Updates wünscht oder nicht, und in Zukunft ist dies der Entscheidungsträger. Dann haben wir Zustimmung.

Wir können an der Aufklärung und Kommunikation bezüglich Updates arbeiten.

Wir können Personen per E-Mail mitteilen, dass ihre Website veraltet und unsicher ist und sie so schnell wie möglich aktualisieren sollten, zusammen mit Links zu Schulungen und Best Practices. Wenn sie noch Hilfe benötigen, ermutigen Sie sie, sich an einen Fachmann zu wenden.

Wir können dieses Problem für die Zukunft beheben, aber wir haben keine stillschweigende rückwirkende Zustimmung, nur weil wir nie einen Genehmigungsmechanismus eingerichtet haben.

Wenn jemand seine Website nicht aktualisiert hat, tat er dies aus einem bestimmten Grund. Oder Gleichgültigkeit. Wie auch immer, wir haben kein Recht, so hineinzugehen und die Websites von Leuten zu modifizieren.

Die Diskussionsteilnehmer ringen immer noch mit den möglichen Auswirkungen des vorgeschlagenen Politikwechsels. Kleinere Updates haben sich als Auto-Updates als sehr zuverlässig erwiesen. Dunn berichtete, dass die automatische Aktualisierung von 3.7.29 nur einen Fehler hatte, der auf 3.7.28 zurückgesetzt werden musste. Die Verwendung des Auto-Update-Systems, um wichtige Updates auf so alte Websites zu übertragen, wurde noch nicht gründlich getestet.

„Unabhängig davon, ob wir die Veröffentlichungen 3.7 -> 5.x automatisch aktualisieren oder nicht, unterstütze ich voll und ganz, klarzustellen, dass dies etwas ist, von dem wir erwarten, dass wir damit für die Zukunft (5.x -> x.x+) beginnen“, Jeremy Felt kommentierte den Vorschlag. „Die Arbeit am Testen der Infrastruktur und des Codes, um dies zu unterstützen, sollte unbedingt so oder so erfolgen.“ Felt sagte auch, er schätze die gestaffelte Rollout-Planung für die vorgeschlagenen Versionen sowie den Plan, ein offiziell unterstütztes Plugin zur Deaktivierung von automatischen Updates bereitzustellen.

Die Diskussion über den Vorschlag ist noch offen, aber bisher scheint es unter den Teilnehmern eine grundlegende Meinungsverschiedenheit darüber zu geben, ob WordPress das Recht hat, größere Versionsaktualisierungen ohne ausdrückliche Zustimmung zu erzwingen, selbst wenn dies in der Absicht geschieht, Website-Besitzer vor einem möglichen Hackerangriff zu bewahren .

„Eines ist sicher, es scheint bisher ein Mehrheitsinteresse zu sein, während viele von uns diese edlen Absichten mögen, bin ich mir nicht sicher, ob es ein gutes Image für WP ist, der wohlwollende Oberherr des Internets zu sein, um voranzukommen “, sagte der Plugin-Entwickler Philip Ingram.