sudo-rs introduce gli asterischi per le password

Una modifica apparentemente piccola sta generando un dibattito sorprendentemente acceso nel mondo Linux. La reimplementazione in Rust del comando sudo, conosciuta come sudo-rs, abilita di default la visualizzazione degli asterischi durante la digitazione della password. È un cambiamento che spezza una convenzione radicata da quasi mezzo secolo, secondo cui l’inserimento della password avviene senza alcun feedback visivo.

Per comprendere la portata della novità bisogna ricordare che sudo, nato nei primi anni ’80, è diventato uno degli strumenti più diffusi per l’esecuzione di comandi con privilegi elevati. La sua presenza è ubiqua nelle distribuzioni Linux e in molti sistemi Unix-like. Oggi, con l’avanzare delle riscritture in linguaggi memory-safe come Rust, anche le scelte di interfaccia vengono riconsiderate alla luce dell’usabilità moderna.

La modifica del comportamento: pwfeedback attivo di default

Dal febbraio 2026, nel repository ufficiale di sudo-rs è stata introdotta una modifica che abilita automaticamente l’opzione pwfeedback, responsabile della comparsa degli asterischi sul terminale. Nella versione storica di sudo questa opzione era disattivata per ragioni di sicurezza: evitare che un osservatore potesse dedurre la lunghezza della password.

Il cambiamento non tocca il meccanismo di autenticazione, che continua a passare attraverso PAM. A mutare è solo il comportamento dell’interfaccia TTY, cioè la modalità con cui l’utente interagisce con il prompt. Gli asterischi vengono generati localmente e non influiscono sulla stringa inviata a PAM.

Usabilità contro tradizione: perché cambiare ora

Gli sviluppatori di sudo-rs spiegano che la scelta nasce da esigenze di accessibilità e da un desiderio di ridurre gli errori di digitazione. L’assenza totale di feedback può creare incertezza, soprattutto con tastiere non standard o layout differenti. Molti strumenti moderni, dai gestori di password ai terminali avanzati, mostrano già caratteri segnaposto durante l’inserimento delle credenziali.

Il team riconosce che la sicurezza può risultare leggermente indebolita, poiché la lunghezza della password diventa osservabile. Tuttavia, ritiene che il rischio sia marginale rispetto ai benefici per l’esperienza utente. Il cosiddetto shoulder surfing viene considerato meno rilevante rispetto alla necessità di evitare errori di digitazione e rendere sudo più accessibile anche ai meno esperti.

Impatto sulle distribuzioni e sul mondo Ubuntu

La modifica riguarda direttamente gli utenti Ubuntu, dato che la distribuzione ha scelto di adottare sudo-rs come implementazione predefinita. Le versioni che integrano il progetto Rust mostrano quindi gli asterischi automaticamente. Una segnalazione di bug aperta da utenti contrari alla novità è stata classificata come “Won’t Fix”, segno che non è previsto un ritorno al comportamento tradizionale.

Negli ambienti server l’impatto è più contenuto. L’accesso privilegiato avviene spesso tramite chiavi SSH, riducendo l’uso di password interattive. Inoltre, molte configurazioni automatizzate utilizzano direttive NOPASSWD nel file sudoers, eliminando del tutto la richiesta di password.

Come disattivare gli asterischi e ripristinare il comportamento classico

Gli amministratori che preferiscono mantenere il modello storico possono intervenire facilmente. È sufficiente aggiungere la direttiva Defaults !pwfeedback nel file sudoers tramite visudo, riportando il sistema all’assenza di feedback visivo. Fino a Ubuntu 26.04 è anche possibile tornare all’implementazione originale in C tramite il sistema di alternative, selezionando nuovamente il binario classico.

Architettura di sudo-rs e vantaggi della riscrittura in Rust

sudo-rs rappresenta una riscrittura completa del codice storico di sudo, originariamente sviluppato in C. Rust introduce un modello di sicurezza basato sul borrow checker, che impedisce errori comuni come buffer overflow, use-after-free e dereferenziazioni non sicure. Il progetto, sviluppato dalla Trifecta Tech Foundation, ha superato due audit indipendenti: quello del 2025 non ha rilevato vulnerabilità sfruttabili, mentre quello del 2023 aveva individuato un problema di path traversal poi corretto.

La riscrittura non elimina i rischi logici, ma riduce drasticamente le vulnerabilità legate alla gestione della memoria, offrendo una base più solida per l’evoluzione futura di uno degli strumenti più critici dell’intero mondo Linux.

Fonte: OmgUbuntu

Lascia un commento