Propozycja automatycznej aktualizacji starych wersji WordPressa do wersji 4.7 wywołuje zaciekłą debatę

Współtwórcy WordPressa, programiści i członkowie społeczności debatują obecnie nad propozycją wdrożenia nowej polityki dotyczącej obsługi bezpieczeństwa dla starszych wersji. Dyskusja rozpoczęła się w zeszłym tygodniu, kiedy szef zespołu ds. bezpieczeństwa, Jake Spurlock, poprosił o opinie na temat różnych podejść do backportingu poprawek bezpieczeństwa do starszych wersji. Kontynuując tę ​​dyskusję, Ian Dunn, pełnoetatowy współpracownik rdzenia WordPress, sponsorowany przez Automattic, opublikował propozycję wprowadzenia nowej polityki:

Obsługuj najnowsze 6 wersji i automatycznie aktualizuj nieobsługiwane witryny do najstarszej obsługiwanej wersji.

Oznaczałoby to, że obecnie obsługiwane wersje to 4.7 – 5.2, a gałęzie 3.7 – 4.6 zostaną ostatecznie zaktualizowane do wersji 4.7.

W praktyce zapewniłoby to około 2 lata wsparcia dla każdego oddziału, a około 10% obecnych witryn zostałoby ostatecznie zaktualizowanych automatycznie do wersji 4.7. Po wydaniu wersji 5.3 najstarszą obsługiwaną wersją będzie wersja 4.8.

Dunn przedstawił szczegółowy plan wdrożenia nowej polityki, który obejmuje testowanie niewielkiego podzbioru witryn w celu zidentyfikowania problemów przed stopniową aktualizacją starszych witryn z jednej głównej wersji do kolejnej (nie wszystkie naraz). Administratorzy witryny byliby powiadamiani co najmniej 30 dni przed automatycznymi aktualizacjami za pomocą wiadomości e-mail i powiadomień w administratorze, które również oferowałyby możliwość rezygnacji.

Propozycja otrzymała dziesiątki komentarzy, przy czym niektórzy autorzy poparli, niektórzy opowiadali się za modyfikacjami wdrażania, a inni jednoznacznie sprzeciwiają się pomysłowi automatycznej aktualizacji starych witryn do głównych wersji.

Jedną z głównych obaw jest to, że wielu administratorów nie otrzyma żadnego powiadomienia z powodu niedziałających adresów e-mail lub niewystarczającego logowania się do pulpitów administracyjnych. Przeciwnicy twierdzą również, że chociaż istnieją awaryjne rozwiązania dla witryn, które nie są aktualizowane, niektóre witryny mogą być zepsute w sposób, którego WordPress nie może wykryć z powodu problemów z wtyczkami lub motywami.

„Powiadomienie z zaplecza nawet nie zrekompensuje braku niezawodnej komunikacji e-mail” – powiedział Glenn Messersmith. „Istnieje mnóstwo właścicieli witryn, którzy nigdy nie zapuszczają się w back-end po opracowaniu swojej witryny. Są to ci sami ludzie, którzy również nie otrzymają powiadomień e-mail, ponieważ adres e-mail należy do jakiegoś dawno nieistniejącego programisty.

„Nie ma możliwości, aby jakiekolwiek wykrywanie błędów mogło działać jako siatka bezpieczeństwa dla tych, którzy nigdy nie widzieli żadnych powiadomień. Istnieje wiele sposobów, w jakie właściciel witryny może uznać swoją witrynę za „uszkodzoną”, czego skrypt aktualizacji nie byłby w stanie wykryć”.

W odpowiedzi na obawy związane z łamaniem opuszczonych witryn lub administratorami polegającymi w dużym stopniu na porzuconej wtyczce, Dunn zgodził się, że tego typu sytuacje mogą być nieuniknione w ramach obecnej propozycji.

„Zdecydowanie mogę sympatyzować z tą sytuacją, ale musimy gdzieś postawić granicę” – powiedział Dunn. „Nie mamy nieograniczonych zasobów, a obecna polityka ma szkodliwy wpływ na cały ekosystem WordPressa.

„W rzeczywistości wybory nigdy nie są między czysto dobrą rzeczą a czysto złą rzeczą; zawsze są pomiędzy konkurencyjnymi kompromisami.

„Zdecydowanie zgadzam się, że to źle, jeśli niewielka liczba właścicieli witryn musi wykonać dodatkową pracę, aby uaktualnić swoją witrynę, ale ogólnie rzecz biorąc, jest to znacznie, znacznie lepsze niż to, aby nasz zespół ds. bezpieczeństwa był utrudniony przez niezwykle uciążliwą politykę pomocy technicznej ”.

Autor propozycji twierdzi „Nikt nie będzie zmuszony do aktualizacji”; Przeciwnicy twierdzą, że wymaganie od użytkowników rezygnacji jest brakiem zgody

Oprócz problemu możliwego łamania witryn, osoby sprzeciwiające się tej propozycji nie są na pokładzie, ponieważ WordPress wymusza aktualizację bez uzyskania wyraźnej zgody administratorów witryny. Zapewnienie użytkownikom możliwości włączenia automatycznych aktualizacji głównych wersji podstawowych jest jednym z dziewięciu projektów, nad którymi Matt Mullenweg zidentyfikował pracę w 2019 roku. Jednak plan dotyczący tej propozycji jest bardziej agresywny, ponieważ wymagałby właścicieli witryn w wersji 3.7. – 4.6 oddziałów, aby zrezygnować, jeśli nie chcą być stopniowo aktualizowane automatycznie do wersji 4.7.

„Nadal zachowują agencję bez względu na wszystko, nikt nie byłby zmuszony do aktualizacji, wszyscy zachowują kontrolę nad swoją witryną i mogą zrezygnować, jeśli chcą” – powiedział Dunn. „Coś, co jest włączone domyślnie, bardzo różni się od zmuszania kogoś do zrobienia czegoś. Ułatwilibyśmy rezygnację — wystarczy zainstalować wtyczkę, nie jest wymagana konfiguracja — a instrukcje dotyczące rezygnacji byłyby zawarte w każdym e-mailu i powiadomieniu administratora”.

Dunn wyjaśnił dalej w komentarzu dotyczącym tego, kto otrzyma te aktualizacje:

Nikt nie byłby zmuszany, byłby to proces rezygnacji. Jeśli ktoś wyłączył już automatyczne aktualizacje do głównych wersji, będzie to uszanowane, a jego witryna nie zostanie zaktualizowana.

Jeśli ktoś kliknie link rezygnacji w wiadomości e-mail lub kliknie przycisk rezygnacji w powiadomieniu administratora, aktualizacje również zostaną wyłączone.

Jedynymi osobami, które otrzymają aktualizacje, są te, które:

1) Chcesz aktualizację
2) Nie przejmuj się!
3) porzuciły swoje witryny lub konta e-mail

Kilku uczestników dyskusji zapytało, dlaczego w procesie uzyskiwania tych witryn w wersji 4.7 nie można wyrazić zgody, zamiast wymusić aktualizację na tych, którzy tego nie zrobili. Bez względu na to, jak wygodny jest mechanizm rezygnacji, posiadanie go nie stanowi zgody. Wielu właścicieli witryn, którzy zostaną zmuszeni do tego procesu, uważało, że byliby bezpieczni, decydując się na konserwację i aktualizacje zabezpieczeń oraz pozostawiając swoje witryny w celu przeprowadzania „aktualizacji podczas snu”, jak opisano w poście w wersji 3.7.

„Niezabezpieczone witryny są złe, ale prawdopodobnie wsteczne zwiększanie mocy przyznanej sobie przez ten mechanizm jest gorsze” – powiedział twórca UpdraftPlus, David Anderson. „Potencjalnie może to bardziej zaszkodzić zaufaniu i reputacji niż brakowi bezpieczeństwa. Twierdzę, że ogromny pulpit brzydki, nieusuwalne powiadomienia na starszych wersjach ostrzegające o nadchodzącym porzuceniu + konieczność aktualizacji byłyby lepsze. Niech właściciel witryny weźmie odpowiedzialność. Nie baw się w nianię, nie nadużywaj zaufania, nie psuj witryn, a potem nie pisz postów na blogu o tym, jak konieczne były szkody uboczne. Nikt, kto obudzi się na zepsutej stronie, nie będzie z tego zadowolony”.

Andrew Nacin, lider wydania WordPress 3.7 i współautor funkcji automatycznych aktualizacji WordPress w tle, zachęcił twórców propozycji do wyjaśnienia, że ​​WordPress obsługuje tylko najnowszą wersję główną i nigdy oficjalnie nie wspierał starszych wersji.

„Z pewnością potrzeba dużo pracy, aby backportować” – powiedział Nacin. „Ale nadal powinniśmy trzymać się naszej gwiazdy północnej, czyli tego, że WordPress jest wstecznie kompatybilny z wersji na wersję, aby użytkownicy WordPressa nie musieli martwić się o to, z jakiej wersji korzystają, i że powinniśmy po prostu aktualizować witryny, jeśli jesteśmy zdolni."

Nacin zaoferował więcej kontekstu na temat oryginalnej strategii wprowadzania automatycznych aktualizacji, która obejmowała stopniowe przechodzenie do głównych wydań jako automatycznych aktualizacji, aby ostatecznie wszystkie witryny miały najnowszą wersję:

Po pierwsze, kiedy po raz pierwszy wydaliśmy automatyczne aktualizacje w tle, pomyśleliśmy, że naszym kolejnym dużym impulsem będzie dotarcie do głównych aktualizacji automatycznych w ciągu najbliższych kilku lat. W praktyce możemy to zrobić w dowolnym momencie i rzeczywiście 3.7 poparł to jako flagę. Ale pomysł był taki, że zainwestowalibyśmy energię w piaskownicę, ochronę białego ekranu, poprawę funkcji wycofywania itd., więc nasz wskaźnik sukcesu był tak samo wysoki w przypadku wersji głównych, jak i mniejszych. (Wskaźnik niepowodzeń skaluje się nieco liniowo wraz z liczbą plików, które należy skopiować, a także staje się bardziej złożony, gdy trzeba dodać, a nie tylko zmienić pliki). Gdy to zrobimy, po prostu zaczniemy aktualizować wszystkie witryny do najnowszej wersji i zaprzestań backportingu. Oczywiście jeszcze tu nie dotarliśmy.

Skomentował, że ogólnie propozycja jest „świetnym planem”, ale podkreślił korzyści płynące z informowania użytkowników, że aktualizacja jest bezpieczna i że WordPress zamierza obsługiwać tylko najnowszą wersję.

Większość uczestników dyskusji opowiada się za zaprzestaniem przez zespół ds. bezpieczeństwa backportingu poprawek do starszych wersji WordPressa. Pytanie, które pozostaje bez odpowiedzi dla przeciwników, brzmi: dlaczego WordPress jest odpowiedzialny za zmuszanie starszych witryn do aktualizacji.

„Nie sądzę, aby decyzja WordPressa o aktualizowaniu witryn, których nie udało się uzyskać do wersji głównych/łamliwych, powinna być zatrzymana”, powiedział Will Stocks. „Ty (WordPress) nie jesteś właścicielem infrastruktury ani procesów biznesowych, ani nie rozumiesz wsparcia w zakresie zarządzania tymi witrynami. Jest też powód, dla którego te witryny nadal są w tej wersji i nie zostały zaktualizowane w przeszłości”.

Istnieją inne podejścia, które nadal mogą wytyczyć granicę, aby szanować ograniczone zasoby zespołu ds. bezpieczeństwa bez wymuszania jakichkolwiek nieuzasadnionych aktualizacji głównych wersji. Rachel Cherry, dyrektor WPCampus, skomentowała tę propozycję, zdecydowanie nakłaniając WordPressa do wyrażenia zgody przed aktualizacją tych witryn:

Wchodzimy w chwasty tego, czy wymuszone aktualizacje spowodują problemy techniczne i całkowicie przeoczą prawdziwy problem.

Omawiamy wymuszanie aktualizacji oprogramowania osób, które nie wyraziły na to zgody.

I po co? Jaki jest tu prawdziwy problem? Ponieważ nie chcemy się martwić aktualizacją starych wersji?

Istnieją inne sposoby rozwiązania tego problemu.

Możemy stworzyć jasną politykę dotyczącą wsparcia EOL dla wydań.

Możemy dodać ustawienie do rdzenia, które pozwala użytkownikowi wybrać, czy chce automatycznych aktualizacji, i iść dalej, co jest decydentem. Wtedy mamy zgodę.

Możemy pracować nad edukacją i komunikacją dotyczącą aktualizacji.

Możemy wysłać wiadomość e-mail do osób, że ich witryna jest nieaktualna i niepewna oraz że powinni aktualizować jak najszybciej, wraz z linkami do edukacji i najlepszych praktyk. Jeśli nadal potrzebują pomocy, zachęć ich do skontaktowania się z profesjonalistą.

Możemy rozwiązać ten problem w przyszłości, ale nie mamy dorozumianej zgody z mocą wsteczną tylko dlatego, że nigdy nie wdrożyliśmy mechanizmu udzielania zezwoleń.

Jeśli ktoś nie aktualizował swojej witryny, robił to z jakiegoś powodu. Albo obojętność. Tak czy inaczej, nie mamy prawa wchodzić w ten sposób i modyfikować witryn internetowych ludzi.

Uczestnicy dyskusji wciąż zmagają się z potencjalnymi konsekwencjami proponowanej zmiany polityki. Drobne aktualizacje okazały się bardzo niezawodne jako aktualizacje automatyczne. Dunn poinformował, że automatyczna aktualizacja wersji 3.7.29 miała tylko jedną awarię, która musiała zostać przywrócona do wersji 3.7.28. Korzystanie z systemu automatycznej aktualizacji do przesyłania głównych aktualizacji do witryn tak starych, jak te, nie zostało jeszcze dokładnie przetestowane.

„Niezależnie od tego, czy automatycznie aktualizujemy wersje 3.7 -> 5.x, w pełni popieram, aby jasno powiedzieć, że spodziewamy się, że zaczniemy to robić w przyszłości (5.x -> x.x+)” Jeremy Felt skomentował wniosek. „Praca nad infrastrukturą testową i kodem, aby to wspierać, należy bezwzględnie wykonać w dowolny sposób”. Felt powiedział również, że docenia rozłożone harmonogramy wdrażania proponowanych wydań, a także plan udostępnienia oficjalnie obsługiwanej wtyczki do wyłączania automatycznych aktualizacji.

Dyskusja nad propozycją jest nadal otwarta, ale jak dotąd wydaje się, że istnieje fundamentalna różnica zdań wśród uczestników co do tego, czy WordPress ma prawo wymusić aktualizacje głównych wersji bez wyraźnej zgody, nawet jeśli ma to na celu uchronienie właścicieli witryn przed potencjalnym zhakowaniem .

„Jedno jest pewne, jak dotąd wydaje się, że dotyczy to większości, podczas gdy wielu z nas lubi te szlachetne intencje, po prostu nie jestem pewien, czy bycie życzliwym władcą Internetu jest dobrym wizerunkiem dla WP posuwającego się do przodu ”, powiedział twórca wtyczek Philip Ingram.