En tout logique, les projets bazardesques devraient soit utiliser un modèle de divulgation complet soit utiliser un modèle cathédralesque pour leurs correctifs de sécurité.
C'est ce que je me disais aussi. D'ailleurs, j'avais imaginé que c'était déjà le cas pour le noyau, je me trompais :).
Sur des projets un peu conséquents et/ou structurés (noyau Linux, systemd, Apache We Server), ça semble réaliste et finançable par des éditeurs de distribs (Canonical, Redhat) et des hébergeurs (Scaleway, OVHcloud) et que sais-je. Mais des failles de sécurité critiques, il peut y en avoir dans plein de composants. sudo et son développeur unique en burn-out ?
Si on ne regarde que sur les binaires suid, je trouve ceux-ci sur mon laptop perso :
Est-ce que chaque projet derrière a une équipe qui sait gérer les failles critiques correctement ?
Est-ce que ces vieilles versions d'electron (= chromium) sont bien sérieuses ?
Pourquoi le truc qui permet de changer le champ GECOS (chfn) de mon utilisateur a besoin des mêmes droits que pour formatter mon stockage ?
Sur un autre sujet, je trouve que ça remet aussi un peu en cause le modèle d'avoir plein de protocoles implémentés dans le noyau directement. Avons-nous vraiment besoin de SMB ou NFS dans le noyau ? N'y a-t-il pas un moyen aussi efficace d'avoir des couches en mode utilisateur qui soient aussi performantes que dans le noyau ?
N'étant pas développeur bas niveau, je ne vais pas me lancer dans ce genre de débat, mais je vois un parallèle entre le noyau tout puissant, le compte root tout puissant, et le fait que la moindre faiblesse à ces niveaux mène à un truc assez catastrophique.
# J'ai un peu la même conclusion
Posté par cg . En réponse au journal gestion de failles de sécurité bazardeuse. Évalué à 4 (+2/-0). Dernière modification le 17 mai 2026 à 12:36.
C'est ce que je me disais aussi. D'ailleurs, j'avais imaginé que c'était déjà le cas pour le noyau, je me trompais :).
Sur des projets un peu conséquents et/ou structurés (noyau Linux, systemd, Apache We Server), ça semble réaliste et finançable par des éditeurs de distribs (Canonical, Redhat) et des hébergeurs (Scaleway, OVHcloud) et que sais-je. Mais des failles de sécurité critiques, il peut y en avoir dans plein de composants.
sudoet son développeur unique en burn-out ?Si on ne regarde que sur les binaires suid, je trouve ceux-ci sur mon laptop perso :
cdda2wav
cdrecord
chage
chfn
chrome-sandbox
chsh
crontab
dbus-daemon-launch-helper
expiry
fusermount
fusermount3
fusermount-glusterfs
gpasswd
ksu
libgtop_server2
mount
mount.cifs
newgrp
passwd
pkexec
qemu-bridge-helper
readcd
rscsi
sg
ssh-keysign
su
sudo
suexec
umount
unix_chkpwd
xf86-video-intel-backlight-helper
Xorg.wrap
qui appartiennent à ces paquets :
apache
cdrtools
chromium
cifs-utils
cronie
dbus
electron13/36/37/38/39/41/42
fuse2
fuse3
glusterfs
krb5
libgtop
openssh
pam
polkit
qemu-common
shadow
sudo
util-linux
xf86-video-intel
xorg-server
Est-ce que chaque projet derrière a une équipe qui sait gérer les failles critiques correctement ?
Est-ce que ces vieilles versions d'electron (= chromium) sont bien sérieuses ?
Pourquoi le truc qui permet de changer le champ GECOS (chfn) de mon utilisateur a besoin des mêmes droits que pour formatter mon stockage ?
Sur un autre sujet, je trouve que ça remet aussi un peu en cause le modèle d'avoir plein de protocoles implémentés dans le noyau directement. Avons-nous vraiment besoin de SMB ou NFS dans le noyau ? N'y a-t-il pas un moyen aussi efficace d'avoir des couches en mode utilisateur qui soient aussi performantes que dans le noyau ?
N'étant pas développeur bas niveau, je ne vais pas me lancer dans ce genre de débat, mais je vois un parallèle entre le noyau tout puissant, le compte root tout puissant, et le fait que la moindre faiblesse à ces niveaux mène à un truc assez catastrophique.