Propunerea de actualizare automată a versiunilor vechi ale WordPress la 4.7 provoacă dezbateri aprinse

Colaboratorii WordPress, dezvoltatorii și membrii comunității dezbat în prezent o propunere de implementare a unei noi politici privind suportul de securitate pentru versiunile mai vechi. Discuția a început săptămâna trecută, când liderul echipei de securitate, Jake Spurlock, a cerut feedback cu privire la diferite abordări ale reportării corecțiilor de securitate la versiunile mai vechi. În urma acestei discuții, Ian Dunn, un colaborator cu normă întreagă la WordPress core, sponsorizat de Automattic, a publicat o propunere pentru a merge mai departe cu o nouă politică:

Acceptați cele mai recente 6 versiuni și actualizați automat site-urile neacceptate la cea mai veche versiune acceptată.

Asta ar însemna că versiunile suportate în prezent ar fi 4.7 – 5.2, iar ramurile 3.7 – 4.6 vor fi în cele din urmă actualizate automat la 4.7.

În practică, aceasta ar oferi aproximativ 2 ani de asistență pentru fiecare ramură, iar aproximativ 10% din site-urile actuale ar fi în cele din urmă actualizate automat la 4.7. Odată ce 5.3 este lansat, cea mai veche versiune acceptată va deveni 4.8.

Dunn a subliniat un plan detaliat pentru implementarea noii politici care implică testarea unui mic subset de site-uri pentru a identifica problemele înainte de a actualiza treptat site-urile mai vechi de la o versiune majoră la alta (nu toate odată). Administratorii site-ului vor fi anunțați cu cel puțin 30 de zile înainte de actualizările automate cu e-mailuri și notificări în administrator care ar oferi, de asemenea, posibilitatea de a renunța.

Propunerea a primit zeci de comentarii, cu unii contribuitori în sprijin, unii în favoarea modificărilor la lansare și alții care se opun fără echivoc ideii de a actualiza automat site-urile vechi la versiuni majore.

Una dintre preocupările predominante este că mulți administratori nu vor primi nicio notificare din cauza adreselor de e-mail care nu funcționează sau nu se conectează la tablourile de bord de administrare suficient de frecvent. Oponenții susțin, de asemenea, că, deși există alternative pentru site-urile care nu reușesc să se actualizeze, unele site-uri pot fi sparte într-un mod pe care WordPress nu îl poate detecta, din cauza problemelor cu pluginurile sau temele.

„O notificare back-end nici măcar nu va începe să compenseze lipsa unei comunicări de încredere prin e-mail”, a spus Glenn Messersmith. „Există tone de proprietari de site-uri care nu se aventurează niciodată în back-end odată ce site-ul lor a fost dezvoltat. Aceștia sunt chiar oamenii care nu vor primi notificări prin e-mail, deoarece adresa de e-mail este cea a unui dezvoltator de mult dispărut.

„Nu există nicio modalitate de detectare a erorilor să acționeze ca o plasă de siguranță pentru cei care nu au văzut niciodată notificări. Există tot felul de moduri prin care un proprietar de site ar putea să-și considere site-ul ca fiind „defect”, pe care un script de actualizare nu le-ar putea detecta.”

Ca răspuns la preocupările legate de spargerea site-urilor abandonate sau de administratorii care se bazează foarte mult pe un plugin care a fost abandonat, Dunn a fost de acord că aceste tipuri de situații pot fi inevitabile în conformitate cu propunerea actuală.

„Cu siguranță pot simpatiza cu această situație, dar trebuie să tragem limita undeva”, a spus Dunn. „Nu avem resurse nelimitate, iar politica actuală are efecte dăunătoare pentru întregul ecosistem WordPress.

„În realitate, alegerile nu sunt niciodată între un lucru pur bun și un lucru pur rău; sunt întotdeauna între compromisuri concurente.

„Sunt cu siguranță de acord că este rău dacă un număr mic de proprietari de site trebuie să facă o muncă suplimentară pentru a-și actualiza site-ul, dar în marea schemă a lucrurilor, asta este mult, mult mai bine decât ca echipa noastră de securitate să fie împiedicată de o politică de asistență extrem de oneroasă. .”

Autorul propunerii susține „Nimeni nu ar fi forțat să actualizeze;” Oponenții susțin că solicitarea utilizatorilor să renunțe nu este consimțământ

Pe lângă problema posibilei spargeri a site-urilor, cei care se opun propunerii nu sunt de acord cu WordPress forțând o actualizare fără a obține consimțământul explicit de la administratorii site-ului. Oferirea utilizatorilor o modalitate de a opta pentru actualizările automate pentru versiunile de bază majore este unul dintre cele nouă proiecte la care Matt Mullenweg le identificase pentru a lucra în 2019. Cu toate acestea, planul pentru această propunere este mai agresiv, deoarece ar necesita proprietarii site-ului pe versiunea 3.7. – ramurile 4.6 să renunțe dacă nu doresc să fie actualizate automat treptat la 4.7.

„Ei păstrează în continuare agenția, indiferent de ce, nimeni nu ar fi forțat să actualizeze, toată lumea își păstrează controlul asupra site-ului și poate renunța dacă doresc”, a spus Dunn. „Ceva activat în mod implicit este foarte diferit de a forța pe cineva să facă ceva. Vom face foarte ușor să renunțați - doar instalați un plugin, nu este necesară nicio configurare - și instrucțiunile pentru renunțare ar fi incluse în fiecare e-mail și notificare de administrator.”

Dunn a mai clarificat într-un comentariu cu privire la cine va primi aceste actualizări:

Nimeni nu ar fi forțat, ar fi în schimb un proces de renunțare. Dacă cineva a dezactivat deja actualizările automate la versiunile majore, acest lucru ar fi respectat și site-ul său nu ar fi actualizat.

Dacă cineva a făcut clic pe linkul de renunțare din e-mail sau dacă a făcut clic pe butonul de renunțare din notificarea de administrator, atunci actualizările ar fi, de asemenea, dezactivate.

Singurele persoane care ar primi actualizările sunt cele care:

1) Doriți actualizarea
2) Nu-ți pasă
3) Au abandonat site-urile sau conturile de e-mail

Mai mulți participanți la discuție au întrebat de ce procesul de obținere a acestor site-uri pe versiunea 4.7 nu poate fi opt-in pentru consimțământ, în loc să forțeze actualizarea celor care nu renunță. Indiferent cât de convenabil este mecanismul de renunțare, existența unuia nu constituie consimțământ. Mulți proprietari de site-uri care vor fi forțați să intre în acest proces s-au gândit că ar fi în siguranță să opteze pentru actualizări de întreținere și securitate și să-și părăsească site-urile să efectueze „actualizări în timp ce dormiți”, așa cum a descris această funcție în postarea versiunii 3.7.

„Site-urile nesigure sunt proaste, dar, fără îndoială, extinderea retroactivă a puterii acordate prin acest mecanism este mai rău”, a spus creatorul UpdraftPlus, David Anderson. „Potențial ar putea afecta încrederea + reputația mai mult decât insecuritatea. Aș susține că tabloul de bord uriaș, notificări urâte, inamovibile pe versiunile mai vechi care avertizează asupra viitoarei abandonuri + necesitatea actualizării ar fi mai bine. Lăsați proprietarul site-ului să-și asume responsabilitatea. Nu te juca dădacă, nu abuza de încredere, nu sparge site-uri și apoi scrie postări pe blog despre cum a fost necesar daune colaterale. Nimeni care se trezește cu un site stricat nu va fi mulțumit de asta.”

Andrew Nacin, liderul lansării WordPress 3.7 și coautor al funcției de actualizări automate de fundal a WordPress, i-a încurajat pe cei din spatele propunerii să clarifice că WordPress acceptă doar cea mai recentă versiune majoră și nu a acceptat niciodată oficial versiuni mai vechi.

„Este nevoie de multă muncă, cu siguranță, pentru backport”, a spus Nacin. „Dar ar trebui să rămânem în continuare la steaua noastră nordică, și anume că WordPress este compatibil invers de la o versiune la alta, că utilizatorii WordPress nu ar trebui să-și facă griji cu privire la versiunea pe care o rulează și că ar trebui să menținem site-urile actualizate dacă suntem capabili."

Nacin a oferit mai mult context asupra strategiei inițiale de introducere a actualizărilor automate, care a inclus trecerea treptată la lansări majore ca actualizări automate, astfel încât toate site-urile să fie în cele din urmă pe cea mai recentă versiune:

În primul rând, când am lansat pentru prima dată actualizări automate de fundal, ne-am gândit că următorul nostru mare impuls ar fi să ajungem la actualizările automate majore în următorii câțiva ani. În practică, putem face acest lucru în orice moment și, într-adevăr, 3.7 a susținut acest lucru ca un steag. Dar ideea a fost să investim energie în sandboxing, protecție a ecranului alb, îmbunătățirea funcționalității noastre de rollback etc., astfel încât rata noastră de succes a fost la fel de mare pentru versiunile majore ca și pentru versiunile minore. (Rata de eșec crește oarecum liniar cu numărul de fișiere care trebuie copiate și, de asemenea, devine mai complexă atunci când fișierele trebuie adăugate, mai degrabă decât doar schimbate.) Odată ce am făcut acest lucru, am începe pur și simplu să actualizăm toate site-urile la cea mai recentă versiune și opriți backportingul. Evident că încă nu am ajuns aici.

El a comentat că, în general, propunerea este „un plan grozav”, dar a subliniat beneficiile comunicării utilizatorilor că actualizarea este sigură și că WordPress intenționează doar să accepte cea mai recentă versiune.

Majoritatea participanților la discuție sunt în favoarea ca echipa de securitate să întrerupă remedierea backporting-ului la versiunile mai vechi de WordPress. Întrebarea care rămâne fără răspuns pentru oponenți este de ce este responsabilitatea WordPress de a forța site-urile mai vechi să se actualizeze.

„Nu cred că ar trebui să fie decizia WordPress de a actualiza site-urile care nu reușesc la versiuni majore/de ruptură, dar cred că menținerea acelor ramuri ar trebui oprită”, a spus Will Stocks. „Dvs. (WordPress) nu dețineți infrastructura sau procesele de afaceri și nu înțelegeți suportul existent pentru gestionarea site-urilor respective. Există, de asemenea, un motiv pentru care acele site-uri sunt încă pe această versiune astăzi și nu s-au actualizat în trecut.”

Există și alte abordări care pot încă trage o linie pentru a respecta resursele limitate ale echipei de securitate fără a forța actualizări neconsensuale la versiunile majore. Rachel Cherry, directorul WPCampus, a comentat propunerea, îndemnând cu tărie WordPress să stabilească consimțământul înainte de a actualiza aceste site-uri:

Intrăm în nebunia dacă actualizările forțate vor cauza sau nu probleme tehnologice și pierdem cu totul problema reală.

Discutăm despre actualizarea forțată a software-ului oamenilor atunci când aceștia nu și-au dat consimțământul.

Și pentru ce scop? Care este problema reală aici? Pentru că nu vrem să ne îngrijorăm cu privire la actualizarea versiunilor vechi?

Există și alte modalități de a rezolva această problemă.

Putem face o politică clară cu privire la suportul EOL pentru versiuni.

Putem adăuga o setare la core care să permită utilizatorului să aleagă dacă dorește sau nu actualizări automate și, în continuare, acesta este cel care ia decizii. Atunci avem consimțământul.

Putem lucra la educație și comunicare cu privire la actualizări.

Putem trimite prin e-mail oamenilor că site-ul lor este învechit și nesigur și ar trebui să actualizeze cât mai curând posibil, împreună cu link-uri către educație și cele mai bune practici. Dacă totuși au nevoie de ajutor, încurajați-i să se adreseze unui profesionist.

Putem rezolva această problemă pentru a merge mai departe, dar nu avem consimțământ retroactiv implicit doar pentru că nu am instituit niciodată un mecanism de permisiune.

Dacă cineva nu și-a actualizat site-ul, a făcut-o pentru un motiv. Sau indiferenta. Oricum, nu avem dreptul să intrăm astfel și să modificăm site-urile web ale oamenilor.

Participanții la discuție încă se luptă cu potențialele implicații ale schimbării de politică propuse. Actualizările minore s-au dovedit a fi foarte fiabile ca actualizări automate. Dunn a raportat că actualizarea automată 3.7.29 a avut o singură eroare care a trebuit să fie redată la 3.7.28. Utilizarea sistemului de actualizare automată pentru a trimite actualizări majore către site-uri atât de vechi ca acestea nu a fost încă testată complet.

„Fie că actualizăm sau nu automat versiunile 3.7 -> 5.x, susțin pe deplin să fie clar că acesta este ceva ce ne așteptăm să începem să facem în viitor (5.x -> x.x+)”, Jeremy Felt a comentat propunerea. „Lucrările de testare a infrastructurii și a codului pentru a susține acest lucru ar trebui să fie făcute în orice mod.” Felt a mai spus că apreciază programarea eșalonată a lansării pentru lansările propuse, precum și planul de a oferi un plugin acceptat oficial pentru dezactivarea actualizărilor automate.

Discuția este încă deschisă cu privire la propunere, dar până acum pare să existe un dezacord fundamental între participanți cu privire la faptul dacă WordPress are dreptul de a forța actualizări majore de versiuni fără consimțământul explicit, chiar dacă este cu intenția de a salva proprietarii de site-uri de la eventualele piratare. .

„Un lucru este sigur, pare să fie o preocupare majoritară până acum, în timp ce mulți dintre noi sunt pasionați de aceste intenții nobile, pur și simplu nu sunt atât de sigur că a fi stăpânul binevoitor al internetului este o imagine bună pentru WP care merge mai departe. ”, a spus dezvoltatorul de plugin Philip Ingram.