Rust 1.100 aduce perioade de așteptare în Cargo împotriva pachetelor malițioase

Rust 1.100, programat pentru 12 noiembrie 2026, adaugă în Cargo o perioadă de așteptare („cooldown”) opțională. Aceasta e o vechime minimă pe care o versiune nou publicată a unui crate trebuie să o atingă înainte ca build-urile tale să o folosească. Ideea e simplă și țintește unul dintre cele mai eficiente tipare de atac asupra lanțului de aprovizionare: atacatorul publică o versiune compromisă și lasă actualizările automate să o răspândească înainte să observe cineva.

Ce s-a întâmplat

Funcția vine după un incident din august pe crates.io. Cercetătorii de la Socket au documentat un crate malițios, proc-macro1, al cărui script de build descărca un payload în timpul compilării. Atacatorii au publicat versiuni ale unor crate-uri altfel legitime (arrayref, internment și append-only-vec) care aduceau această dependență periculoasă.

Versiunile compromise au fost disponibile doar 86, 90 și 107 minute înainte de a fi eliminate. A fost totuși suficient: pipeline-urile CI și stațiile dezvoltatorilor cu actualizări automate le-ar fi putut descărca și compila înainte ca echipele de apărare să reacționeze. Cargo rulează scripturile de build la compilare, așa că simpla compilare a bibliotecii afectate executa codul atacatorului, fără nicio modificare în codul sursă al aplicației.

Proiectul Rust lucra la aceste perioade de așteptare dinainte de atac. Discuția de urmărire a fost deschisă pe 18 mai, versiunea nightly a Cargo a primit suport pe 21 iunie, iar stabilizarea a fost integrată pe 28 august. Funcția este acum în beta și ajunge în versiunea stabilă 1.100.

Cum funcționează

Se activează în .cargo/config.toml, în secțiunea [registry], de exemplu global-min-publish-age = "7 days". Perioada poate fi exprimată în secunde, minute, ore, zile, săptămâni sau luni.
La rezolvarea dependențelor, Cargo ignoră versiunile mai noi decât pragul și alege o versiune mai veche care încă respectă cerințele proiectului. Dacă nu există niciuna, rezolvarea eșuează, în loc să accepte în tăcere o versiune proaspătă.
incompatible-publish-age are implicit valoarea "deny", deci nu e nevoie de o setare separată pentru resolver.
Cargo raportează versiunile sărite și vechimea lor, așa că actualizările blocate sunt ușor de înțeles.
Dacă ai nevoie urgent de o corecție mai nouă, poți ocoli perioada de așteptare pentru un singur pachet: CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow cargo update -p <crate> --precise <versiune>.

De ce contează și unde se oprește protecția

Perioada implicită este zero. Simpla actualizare la Rust 1.100 nu schimbă nimic până când echipa nu setează o vechime minimă. Câteva limite importante:

Versiunile deja înregistrate în Cargo.lock rămân neschimbate, chiar dacă sunt mai noi decât pragul. O perioadă de așteptare nu elimină o versiune malițioasă deja blocată în lockfile.
Nu acoperă cargo install, dependențele din git, căile locale sau registrele care nu publică marcaje de timp.
O limită de vechime nu analizează codul și nu dovedește că un crate e sigur. Un malware care scapă de detecție mai mult decât fereastra ta trece în continuare. Abordarea seamănă cu opțiunea de cooldown din Dependabot (GitHub), dar aplică regula direct în resolver, nu prin botul de actualizare.
Socket a semnalat și o campanie din septembrie care viza maintainerii Rust prin oferte false de job sau de proiect și apeluri video, pentru a-i convinge să instaleze software sau să ruleze comenzi. Perioadele de așteptare nu ajută dacă atacatorul preia contul unui publisher de încredere.

Ce poți face

Activează funcția după ce treci la 1.100. Un global-min-publish-age de 3–7 zile e un punct de plecare rezonabil pentru majoritatea echipelor. Folosește o fereastră mai scurtă dacă ai nevoie să aplici rapid corecții.
Verifică lockfile-ul pentru versiunile compromise de proc-macro1, arrayref, internment și append-only-vec din incidentul din august.
Tratează ocolirea ca pe o excepție aprobată. Înregistrează fiecare utilizare a CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow și cere o a doua verificare.
Acoperă manual golurile. Fixează dependențele git la un commit anume și tratează cargo install în CI ca pe o sursă nesigură.
Protejează conturile de maintainer. Folosește MFA pe crates.io și GitHub, limitează strict tokenurile de publicare și instruiește maintainerii să recunoască momelile de tip recrutare.

O perioadă de așteptare îți câștigă timp, iar timpul ăsta ajută doar dacă cineva îți verifică dependențele între timp. De asta se ocupă serviciul nostru de code review asistat de AI: analizează manifestele, lockfile-urile și scripturile de build pentru dependențe riscante sau compromise recent, astfel încât un crate otrăvit să fie prins înainte să ajungă în producție.

Subiect relatat inițial de Cyber Security News (Tushar Subhra Dutta, 21 octombrie 2026). Acest articol este rezumatul și analiza 4Tify.