L’ancien sudo (écrit en C) a été récréé en Rust (sudo-rs), par une autre équipe, pour des raisons de sécurité mémoire notamment. Plusieurs distributions intègrent cette nouvelle implémentation dans leurs paquets et, en particulier, Ubuntu 25.10 l’utilise par défaut.

Pour mémoire (source) : Cette commande permet à un administrateur système d’accorder à certains utilisateurs (ou groupes d’utilisateurs) la possibilité de lancer une commande en tant qu’administrateur, ou en tant qu’autre utilisateur, tout en conservant une trace des commandes saisies et des arguments.

Le récent changement est que, par défaut, la saisie du mot de passe sudo affiche désormais des astérisques via sudo-rs, à l’inverse du comportement antérieur.

Le débat porte principalement sur l’utilisabilité en opposition à la tradition de sécurité Unix de ne rien afficher du tout.

Les arguments du choix portent notamment sur les aspects sécurité, utilisabilité, et tradition. Là où les pro-astérisques estiment la fuite de longueur tolérable, qu’elle confirme l’entrée fonctionnelle, et qu’il s’agit d’une amélioration moderne, les anti-astérisques considèrent que cela expose la longueur aux observateurs, que c’est inutile pour les experts, et que cela casse l’héritage Unix.

Du côté des arguments pour les astérisques, la rétroaction visuelle confirme que les frappes s’enregistrent, ce qui aide les nouveaux utilisateurs ou ceux avec des claviers défaillants et réduit les erreurs de saisie.

Les partisans notent que les risques d’épaulement (voir les caractères réels) sont faibles aujourd’hui avec l’accès distant courant, et que les indices de longueur sont mineurs comparés aux gains d’utilisabilité.

Du côté des arguments contre les astérisques, la conception Unix traditionnelle cache la longueur du mot de passe pour contrer les attaquants observant de loin, préservant une norme de sécurité de 46 ans même si imparfaite.

Les admins vétérans y voient un risque inutile dans les environnements partagés ou physiques, avec des solutions faciles comme pwfeedback pour revenir en arrière.

Vous savez peut-être comment configurer votre choix, notamment en écrivant dans /etc/sudoers soit Defaults pwfeedback (ce qui sera de toutes façons le comportement par défaut avec astérisques), soit Defaults !pwfeedback (avec le point d’exclamation en préfixe).

Si ce paramètre vous rappelle quelque chose, c’est normal. Les plus préoccupés d’entre nous par la sécurité se rappellent de l’incident de sécurité (CVE-2019-18634) lié à ce paramètre il y a quelques années : le paramètre pwfeedback introduit, en version 1.7.1 de sudo, avait hélas introduit un bug qui n’avait été corrigé que bien après.

Un peu de politique FOSS (un tout petit peu hors sujet ;-) )

Je profite de cette dépêche pour faire un appel, car ce débat et l’ancien bug lié à pwfeedback nous rappellent les risques qui pèsent sur les composants FOSS parfois vitaux et répandus comme XZ Utils, qui manquent de main d’œuvre et de moyens.
La récente attaque (CVE-2024-3094) contre OpenSSH en 2024 via sa dépendance logistique à XZ Utils, par un pirate qui avait exploité de l’ingénierie sociale sur Lasse Collin, le mainteneur fatigué et esseulé deXZ Utils, a failli compromettre un grand nombre d’ordinateurs utilisantOpenSSH`.
C’est un tiers, Andres Freund, employé de Microsoft, qui a contré le piratage en détectant puis identifiant l’erreur.

De même, vous avez su que Todd, C. Miller, l’unique mainteneur de sudo depuis 30 ans, appelait au secours et aux financements en début d’année 2026. Certes, ce point particulier a peut-être été réglé par la ré-écriture en Rust (sudo-rs) avec l’aide de Miller, mais le sujet est global pour le FOSS.

Mon souhait : donnons plus de notre personne ou de notre poche aux projets et personnes du FOSS.

Les informations que vous n’avez pas demandées (ou Too much information you didn't ask for)

Rust veut dire « rouille » en anglais, mais l’auteur de Rust faisait apparemment référence aux « rouilles » biologiques, qui sont les maladies dues à des champignons, les Pucciniales, qui donnent ainsi un aspect rouillé aux plantes parasitées, comme la rouille grillagée du poirier. Graydon Hoare a choisi ce terme, pour s’inspirer de ces champignons qui sont extrêmement sophistiqués dans leur capacité à survivre, comme on pourrait le vouloir pour nos programmes.

Alors que les solutions de monitoring serveur deviennent toujours plus complexes et dépendantes de stacks lourdes, deux projets open source (NdM: absence de licence) récents prennent le contre-pied de cette tendance : MonitorBox et Monitux. Leur objectif commun : revenir à un monitoring lisible, fiable et maîtrisable, pensé avant tout pour les administrateurs Linux.

MonitorBox : réduire le bruit pour mieux gérer l’urgence

MonitorBox part d’un constat largement partagé dans les équipes techniques : la multiplication des alertes engendre une fatigue des notifications, au point que les incidents critiques risquent d’être ignorés.
Le projet introduit une logique volontairement simple mais efficace : réduction des faux positifs par vérifications successives, séparation claire entre alertes critiques et informationnelles, et retour d’un outil longtemps abandonné mais redoutablement efficace : le pager (bipper).

En complément des notifications classiques, MonitorBox propose :

• une interface terminal pensée pour l’exploitation,
• un dashboard web léger,
• et une alerte matérielle dédiée pour les situations réellement urgentes.

Le projet assume une philosophie pragmatique : mieux vaut peu d’alertes fiables que beaucoup d’alertes ignorées.

Code source : https://github.com/simple-group/MonitorBox
Présentation : https://www.ihaveto.be/2026/01/pourquoi-jai-ressuscite-le-pager-des.html

Monitux : un monitoring “zero-dependency” pour réduire la surface d’attaque

Monitux s’inscrit dans une démarche encore plus radicale de sobriété technique. Le projet se définit comme un outil de monitoring serveur sans base de données, sans langage interprété (PHP, Python, Node.js), et sans dépendances externes.

Il repose exclusivement sur :

• les outils natifs GNU/Linux (top, df, ss, systemd…), un affichage web minimaliste, et une protection d’accès via les mécanismes standards d’Apache (.htaccess / .htpasswd).

Ce choix permet de limiter fortement la surface d’attaque, de simplifier l’installation et de garantir une excellente lisibilité du code. Monitux se destine particulièrement aux environnements où la stabilité, la sécurité et la compréhension priment sur la sophistication fonctionnelle.

Code source : https://github.com/simple-group/Monitux/
Présentation : https://www.ihaveto.be/2025/12/monitux-le-monitoring-serveur-revient.html

Une même philosophie : simplicité, contrôle et responsabilité

Bien que différents dans leur approche, MonitorBox et Monitux partagent une vision commune :
le monitoring ne doit pas devenir une boîte noire, ni un empilement de dépendances difficile à auditer. Ces projets s’adressent aux administrateurs et équipes techniques qui souhaitent reprendre le contrôle, réduire la complexité et privilégier des outils compréhensibles, durables et open source.

Les deux projets sont publiés sous licence libre et ouverts aux contributions.

NdM: aucune licence n'est mentionnée sur les deux projets en question, qui ne sont donc pas libres en l'état.