Proposta di aggiornamento automatico delle vecchie versioni di WordPress a 4.7 Sparks acceso dibattito

Collaboratori, sviluppatori e membri della comunità di WordPress stanno attualmente discutendo una proposta per implementare una nuova politica relativa al supporto della sicurezza per le versioni precedenti. La discussione è iniziata la scorsa settimana quando il capo del team di sicurezza Jake Spurlock ha chiesto un feedback sui diversi approcci al backport delle correzioni di sicurezza su versioni precedenti. A seguito di questa discussione, Ian Dunn, un collaboratore a tempo pieno del core di WordPress, sponsorizzato da Automattic, ha pubblicato una proposta per andare avanti con una nuova politica:

Supporta le ultime 6 versioni e aggiorna automaticamente i siti non supportati alla versione supportata meno recente.

Ciò significherebbe che le versioni attualmente supportate sarebbero 4.7 – 5.2 e i rami 3.7 – 4.6 sarebbero eventualmente aggiornati automaticamente alla 4.7.

In pratica, ciò fornirebbe circa 2 anni di supporto per ciascuna filiale e circa il 10% dei siti attuali verrebbe eventualmente aggiornato automaticamente alla versione 4.7. Una volta rilasciata la 5.3, la versione supportata più vecchia sarebbe diventata la 4.8.

Dunn ha delineato un piano dettagliato per l'implementazione della nuova politica che prevede il test di un piccolo sottoinsieme di siti per identificare i problemi prima di aggiornare gradualmente i siti più vecchi da una versione principale a quella successiva (non tutti in una volta). Gli amministratori del sito riceverebbero una notifica almeno 30 giorni prima degli aggiornamenti automatici con e-mail e avvisi nell'amministratore che offrirebbero anche l'opportunità di rinunciare.

La proposta ha ricevuto decine di commenti, con alcuni contributori a sostegno, alcuni a favore delle modifiche al rollout e altri inequivocabilmente contrari all'idea di aggiornare automaticamente i vecchi siti alle versioni principali.

Una delle preoccupazioni prevalenti è che molti amministratori non riceveranno alcun avviso a causa di indirizzi e-mail non funzionanti o che non accedono abbastanza frequentemente alle loro dashboard di amministrazione. Gli oppositori sostengono inoltre che, anche se ci sono fallback per i siti che non riescono ad aggiornare, alcuni siti potrebbero essere danneggiati in un modo che WordPress non può rilevare, a causa di problemi con plugin o temi.

"Un avviso di back-end non comincerà nemmeno a compensare la mancanza di comunicazioni e-mail affidabili", ha affermato Glenn Messersmith. “Ci sono tonnellate di proprietari di siti che non si avventurano mai nel back-end una volta che il loro sito è stato sviluppato. Queste sono le stesse persone che non riceveranno notifiche e-mail perché l'indirizzo e-mail è quello di uno sviluppatore scomparso da tempo.

“Non è possibile che alcun tipo di rilevamento degli errori possa fungere da rete di sicurezza per coloro che non hanno mai visto alcuna notifica. Esistono molti modi in cui il proprietario di un sito potrebbe considerare il proprio sito "rotto" che uno script di aggiornamento non potrebbe rilevare".

In risposta alle preoccupazioni per la rottura di siti abbandonati o per gli amministratori che fanno molto affidamento su un plug-in che è stato abbandonato, Dunn ha convenuto che questo tipo di situazioni potrebbe essere inevitabile ai sensi dell'attuale proposta.

"Posso sicuramente simpatizzare con quella situazione, ma dobbiamo tracciare un limite da qualche parte", ha detto Dunn. “Non abbiamo risorse illimitate e l'attuale politica ha effetti dannosi per l'intero ecosistema di WordPress.

“In realtà, le scelte non sono mai tra una cosa puramente buona e una cosa puramente cattiva; sono sempre tra compromessi in competizione.

"Sono decisamente d'accordo sul fatto che sia negativo se un piccolo numero di proprietari del sito deve fare del lavoro extra per aggiornare il proprio sito, ma nel grande schema delle cose, è molto, molto meglio che il nostro team di sicurezza sia ostacolato da una politica di supporto estremamente onerosa .”

L'autore della proposta afferma "Nessuno sarebbe costretto ad aggiornare"; Gli oppositori sostengono che richiedere agli utenti di rinunciare non è consenso

Oltre al problema della possibile rottura dei siti, chi si oppone alla proposta non è d'accordo con WordPress forzando un aggiornamento senza ottenere il consenso esplicito dagli amministratori del sito. Fornire agli utenti un modo per attivare gli aggiornamenti automatici per le principali versioni principali è uno dei nove progetti su cui Matt Mullenweg aveva identificato per lavorare nel 2019. Tuttavia, il piano per questa proposta è più aggressivo in quanto richiederebbe ai proprietari di siti il ​​3.7 – 4.6 rami da disattivare se non vogliono essere aggiornati automaticamente in modo incrementale a 4.7.

"Mantengono ancora l'agenzia, non importa cosa, nessuno sarebbe costretto ad aggiornare, tutti mantengono il controllo sul proprio sito e possono rinunciare se lo desiderano", ha detto Dunn. “Qualcosa che è attivo per impostazione predefinita è molto diverso dal costringere qualcuno a fare qualcosa. Semplificheremmo la disattivazione: basta installare un plug-in, non è richiesta alcuna configurazione e le istruzioni per la disattivazione saranno incluse in ogni e-mail e avviso dell'amministratore".

Dunn ha ulteriormente chiarito in un commento chi avrebbe ricevuto questi aggiornamenti:

Nessuno sarebbe costretto, si tratterebbe invece di un processo di opt-out. Se qualcuno ha già disabilitato gli aggiornamenti automatici alle versioni principali, ciò verrebbe rispettato e il loro sito non verrebbe aggiornato.

Se qualcuno ha fatto clic sul collegamento di disattivazione nell'e-mail o se ha fatto clic sul pulsante di disattivazione nell'avviso dell'amministratore, anche gli aggiornamenti sarebbero stati disabilitati.

Le uniche persone che riceverebbero gli aggiornamenti sono quelle che:

1) Vuoi l'aggiornamento
2) Non importa
3) Hanno abbandonato i loro siti o account di posta elettronica

Diversi partecipanti alla discussione hanno chiesto perché il processo per ottenere questi siti su 4.7 non può essere opt-in per il consenso, invece di forzare l'aggiornamento a coloro che non rinunciano. Non importa quanto sia conveniente il meccanismo di opt-out, averne uno in atto non costituisce consenso. Molti proprietari di siti che saranno costretti a questo processo hanno pensato che sarebbero stati al sicuro optando per la manutenzione e gli aggiornamenti di sicurezza e lasciando i loro siti per eseguire "aggiornamenti mentre dormi", come il post sulla versione 3.7 descriveva la funzione.

"I siti non sicuri sono cattivi, ma probabilmente, ampliare retrospettivamente il potere concesso a se stessi da questo meccanismo è peggio", ha affermato il creatore di UpdraftPlus David Anderson. “Potenzialmente potrebbe danneggiare la fiducia + la reputazione più che l'insicurezza. Direi che l'enorme dashboard brutti e irremovibili avvisi sulle versioni precedenti che avvertono dell'imminente abbandono + la necessità di aggiornare sarebbero migliori. Lascia che il proprietario del sito si assuma la responsabilità. Non fare la tata, abusare della fiducia, rompere i siti e poi scrivere post sul blog su come sia stato necessario un danno collaterale. Nessuno che si risvegli su un sito non funzionante ne sarà felice".

Andrew Nacin, responsabile della versione 3.7 di WordPress e coautore della funzione di aggiornamento automatico in background di WordPress, ha incoraggiato coloro che stanno dietro la proposta a chiarire che WordPress supporta solo l'ultima versione principale e non ha mai ufficialmente supportato le versioni precedenti.

"Ci vuole molto lavoro, di sicuro, per fare il backport", ha detto Nacin. “Ma dovremmo comunque attenerci alla nostra stella polare, ovvero che WordPress è retrocompatibile da versione a versione, che gli utenti di WordPress non dovrebbero doversi preoccupare di quale versione stanno eseguendo e che dovremmo semplicemente mantenere aggiornati i siti se noi siamo capaci."

Nacin ha offerto più contesto sulla strategia originale per l'introduzione degli aggiornamenti automatici, che includeva il passaggio graduale ad avere le versioni principali come aggiornamenti automatici in modo che tutti i siti alla fine sarebbero stati sull'ultima versione:

Innanzitutto, quando abbiamo rilasciato per la prima volta gli aggiornamenti automatici in background, abbiamo pensato che la nostra prossima grande spinta sarebbe stata quella di arrivare agli aggiornamenti automatici delle versioni principali nei prossimi anni. In pratica, possiamo farlo in qualsiasi momento e, in effetti, 3.7 lo ha supportato come flag. Ma l'idea era che avremmo investito energia in sandboxing, protezione dello schermo bianco, miglioramento della nostra funzionalità di rollback, ecc., quindi il nostro tasso di successo era alto per le versioni principali come lo era per le versioni secondarie. (Il tasso di errore aumenta in modo alquanto lineare con il numero di file che devono essere copiati e diventa anche più complesso quando i file devono essere aggiunti, anziché semplicemente modificati.) Una volta fatto, inizieremmo semplicemente ad aggiornare tutti i siti all'ultima versione e interrompere il backport. Ovviamente non siamo ancora arrivati ​​qui.

Ha commentato che nel complesso la proposta è "un ottimo piano", ma ha sottolineato i vantaggi di comunicare agli utenti che è sicuro aggiornare e che WordPress intende supportare solo l'ultima versione.

La maggior parte dei partecipanti alla discussione è favorevole al fatto che il team di sicurezza interrompa il backport delle correzioni alle versioni precedenti di WordPress. La domanda che rimane senza risposta per gli avversari è perché è responsabilità di WordPress forzare l'aggiornamento dei siti più vecchi.

"Non credo che dovrebbe essere la decisione di WordPress di aggiornare i siti che non riescono a ottenere con versioni principali/interruttive, ma penso che il mantenimento di quei rami dovrebbe essere interrotto", ha affermato Will Stocks. “Tu (WordPress) non possiedi l'infrastruttura oi processi aziendali, né comprendi il supporto in atto per gestire quei siti. C'è anche un motivo per cui quei siti sono ancora su quella versione oggi e non sono stati aggiornati in passato".

Esistono altri approcci che possono ancora tracciare una linea per rispettare le risorse limitate del team di sicurezza senza forzare aggiornamenti non consensuali alle versioni principali. Rachel Cherry, direttrice di WPCampus, ha commentato la proposta, esortando fortemente WordPress a stabilire il consenso prima di aggiornare questi siti:

Stiamo entrando nel dubbio se gli aggiornamenti forzati causeranno o meno problemi tecnici e mancheranno del tutto il vero problema.

Stiamo discutendo dell'aggiornamento forzato del software delle persone quando non hanno dato il consenso.

E per quale fine? Qual è il vero problema qui? Perché non vogliamo preoccuparci di aggiornare le vecchie versioni?

Ci sono altri modi per risolvere questo problema.

Possiamo stabilire una politica chiara per quanto riguarda il supporto EOL per i rilasci.

Possiamo aggiungere un'impostazione al core che consente all'utente di scegliere se desidera o meno aggiornamenti automatici e andando avanti che è il decisore. Allora abbiamo il consenso.

Possiamo lavorare sull'educazione e la comunicazione per quanto riguarda gli aggiornamenti.

Possiamo inviare un'e-mail alle persone che il loro sito è obsoleto e insicuro e che dovrebbero aggiornarlo il prima possibile, insieme ai collegamenti all'istruzione e alle migliori pratiche. Se hanno ancora bisogno di aiuto, incoraggiali a contattare un professionista.

Possiamo risolvere questo problema per andare avanti, ma non abbiamo un consenso retroattivo implicito solo perché non abbiamo mai messo in atto un meccanismo di autorizzazione.

Se qualcuno non ha aggiornato il proprio sito, lo ha fatto per un motivo. O l'indifferenza. In ogni caso, non abbiamo il diritto di entrare in questo modo e modificare i siti web delle persone.

I partecipanti alla discussione stanno ancora lottando con le potenziali implicazioni del cambiamento politico proposto. Gli aggiornamenti minori si sono rivelati molto affidabili come aggiornamenti automatici. Dunn ha riferito che l'aggiornamento automatico 3.7.29 ha avuto un solo errore che ha dovuto essere ripristinato a 3.7.28. L'utilizzo del sistema di aggiornamento automatico per inviare aggiornamenti importanti a siti vecchi come questi non è stato ancora testato a fondo.

"Indipendentemente dal fatto che aggiorniamo automaticamente le versioni 3.7 -> 5.x, sono pienamente favorevole a chiarire che questo è qualcosa che ci aspettiamo di iniziare a fare per il futuro (5.x -> x.x+)", Jeremy Felt ha commentato la proposta. "Il lavoro per testare l'infrastruttura e il codice per supportare questo dovrebbe assolutamente essere fatto in entrambi i casi." Felt ha anche affermato di aver apprezzato la pianificazione scaglionata del rollout per le versioni proposte, nonché il piano di fornire un plug-in ufficialmente supportato per la disabilitazione degli aggiornamenti automatici.

La discussione è ancora aperta sulla proposta, ma finora sembra esserci un disaccordo fondamentale tra i partecipanti sul fatto che WordPress abbia il diritto di forzare aggiornamenti importanti della versione senza esplicito consenso, anche se è con l'intenzione di salvare i proprietari del sito da potenziali hacker .

"Una cosa è certa, finora sembra essere una preoccupazione della maggioranza, mentre molti di noi sono affezionati a queste nobili intenzioni, solo non sono così sicuro che essere il benevolo signore di Internet sia una buona immagine per WP andare avanti ”, ha affermato lo sviluppatore di plugin Philip Ingram.