Biletul WordPress #30465 a fost deschis în urmă cu 10 ani – 2025 va fi anul în care se rezolvă în sfârșit?

În noiembrie 2014, un dezvoltator WordPress pe nume Sergej Mueller a ridicat ceea ce părea a fi o îngrijorare rezonabilă: utilizatorii nu aveau de unde să știe dacă un plugin pe care îl foloseau a fost eliminat din depozitul oficial – chiar dacă a fost eliminat din motive de securitate. Biletul său – oficial #30465 – a fost închis relativ curând după, dar fără nicio rezoluție. Sergej nu știa că va fi redeschis aproape zece ani mai târziu .

Și iată-ne, la începutul anului 2025, cu mine scriind o actualizare despre asta.

De ce?

Din câteva motive.

În primul rând, este foarte relevant pentru unele evenimente de securitate a pluginurilor care au avut loc recent – ​​octombrie anul trecut, mai exact. Voi vorbi despre acestea în scurt timp. Și, în al doilea rând, voința și impulsul de a rezolva problema au luat avânt serios - ultima activitate pe bilet a fost cu mai puțin de o lună în urmă:

Așa că se pare că răbdarea lui Sergej ar putea în sfârșit să-și aducă roade în curând...

Să începem prin a revedea evoluția biletului. Apoi, putem trece la ceea ce s-a întâmplat cu el în ultimele săptămâni:

De la „nu se rezolvă” la urcarea pe scenă la WCEU 2023 🙅‍♂️

Când biletul a fost deschis pentru prima dată, a primit câteva răspunsuri, dar a fost închis destul de repede de către dezvoltatorul principal WordPress, Andrew Nacin. El l-a închis și l-a marcat ca „nu se va repara”, explicând că eliminările pluginurilor au avut loc din diverse motive, nu numai din probleme de securitate:

După aceea, a existat o rafală de comentarii, dar apoi s-a diminuat într-un comentariu o dată pe an (uneori chiar mai puțin decât atât) al cuiva care încerca să reînvie problema.

Apoi, în martie 2023 , s-a întâmplat ceva interesant. Joost de Valk, o figură cunoscută în comunitatea WordPress, a redeschis oficial biletul . Argumentul său a fost că WordPress are responsabilitatea de a spune utilizatorilor dacă un plugin este întreținut sau nu.

El a mai subliniat că WordPress.org afișa deja aceste informații pe platforma în sine, dar numai după o perioadă de așteptare de 60 de zile. Sugestia lui a fost să aducă aceeași transparență în backend-ul WordPress, unde utilizatorii își gestionează de fapt pluginurile.

Asta a declanșat un nou val de entuziasm peste fir. Biletul a devenit atât de popular încât Oliver Sild, CEO-ul și co-fondatorul Patchstack, l-a menționat chiar în discursul său WCEU 2023 :

Nu numai că a menționat asta, dar i-a încurajat pe participanții la WCEU să lase comentarii pe fir folosind codul QR personalizat pe care l-a adăugat la prezentarea sa. El a folosit, de asemenea, acest plug ca un alley-oop întârziat pentru un concurs pe care Patchstack l-ar găzdui anul următor.

Evenimentul Patchstack din octombrie 2024 🪲

În octombrie 2024, Patchstack a lansat un eveniment Bug Bounty ca parte a lunii securității cibernetice. Dacă mențiunea lui Oliver despre biletul #30465 în discursul său WCEU a fost alley-oop, atunci rezultatele acestui eveniment ar fi slam dunk.

Cercetătorii de securitate care au participat la eveniment au ajuns să descopere 1.571 de rapoarte valide de vulnerabilitate de securitate într-o singură lună. Nici acestea nu au fost doar probleme minore – vorbim despre:

• 73 de cazuri în care atacatorii ar putea încărca fișiere rău intenționate.
• 67 vulnerabilități de injectare SQL care ar putea compromite baze de date întregi.
• 58 de moduri prin care atacatorii își pot escalada privilegiile.
• 17 vulnerabilități de execuție a codului de la distanță (dah!)

Următoarele au dus la închiderea temporară a aproape 1.000 de pluginuri. Și când Patchstack a încercat să contacteze dezvoltatorii de pluginuri în legătură cu aceste probleme, aproape 74% au fost complet inaccesibili. Fie formularele lor de contact au fost rupte, e-mailurile le-au respins, fie domeniile lor au expirat.

Problema este că multe dintre aceste plugin-uri vulnerabile au stat în depozit de 6-11 ani. Unele datează de 17 ani! Și da, există încă site-uri web live care depind de aceste plugin-uri.

Inutil să spun că toate aceste date i-au oferit lui Oliver putere de pârghie în fir pentru a împinge biletul #30465 spre finalizare. A profitat cu bucurie de asta și a postat câteva dintre detalii cu două săptămâni înainte de publicarea postării oficiale de blog Patchstack care discuta despre eveniment:

De la discuție la acțiune 🛠️

Activitatea de pe fir era deja în plină bulgăre de zăpadă când Oliver și-a adăugat comentariul, așa că măsurarea impactului său individual este dificilă. Cu toate acestea, nu este nerezonabil să presupunem că a adăugat combustibil la o flacără în creștere. Mai ales cu alți utilizatori (dintre care cel puțin unul este angajat Patchstack) care își susțin în mod deschis comentariul.

Ca răspuns, dezvoltatorul principal WordPress Dion Hulse (@dd32) a dat o oarecare respingere în mai multe puncte, dar a și intensificat într-un mod uriaș prin crearea unui plugin experimental care implementează caracteristica mult așteptată:

Implementarea este foarte simplă – atunci când un plugin a fost închis în depozitul WordPress.org, utilizatorii văd o notificare clară, dar măsurată. Fără alerte roșii care provoacă panică, doar informații simple despre starea pluginului.

Cineva îl găsește pe Sergej și îi spune: „Mamă am reușit!”

Ei bine... aproape.

Încă nu face parte din nucleul WordPress, dar simt că suntem aproape de linia de sosire aici!

Acum că s-a demonstrat că este posibil, următorul pas este să decideți asupra unei implementări finale. Apoi poate fi integrat în nucleul WordPress.

Ce urmează? 🎯

În momentul scrierii acestui articol, funcția este luată în considerare pentru includerea în WordPress 6.8 (după Dion Hulse), deși mai sunt câteva obstacole de eliminat. Acestea includ:

• Finalizarea timpului de notificare (se discută despre eventuala extindere a ferestrei de 60 de zile).
• Standardizarea documentației privind motivele de închidere.
• Echilibrarea gradului de conștientizare a utilizatorilor cu sarcina de asistență pentru dezvoltatori.
• Decizia privind locația exactă (ecranul de sănătate a site-ului vs direct pe plugin, așa cum se arată în exemplul de captură de ecran de plugin).

Imaginea de ansamblu 🌐

Evoluția biletului WordPress #30465 ne spune ceva fascinant despre modul în care securitatea WordPress s-a schimbat în ultimul deceniu. Ceea ce odată a fost respins ca un caz marginal a devenit din ce în ce mai critic pe măsură ce ecosistemul a crescut și provocările de securitate s-au multiplicat.

Deși a fost nevoie de zece ani pentru a ajunge aici, pluginul experimental sugerează că în sfârșit ne apropiem de o soluție care echilibrează gradul de conștientizare a securității cu experiența utilizatorului. Cu milioane de instalări WordPress potențial afectate de pluginuri vulnerabile, această caracteristică nu poate veni suficient de curând.

Dacă doriți să urmăriți dezvoltarea, consultați pluginul experimental de pe GitHub sau fiți cu ochii pe biletul #30465. Acesta ar putea fi unul dintre acele momente rare în care ajungem să asistăm la o conversație de un deceniu care se transformă într-un rezultat tangibil. 💡

Ce părere aveți despre această caracteristică? Crezi că ți-ar fi util ca utilizator WordPress să fii informat că un plugin a fost închis? Anunță-mă în comentarii. Ne vedem acolo.