Journal gestion de failles de sécurité bazardeuse

Posté par  (courriel, site web personnel) . Licence CC By‑SA.
Étiquettes :
18
16
mai
2026

le bazar a gagné

La typologie cathédrale/bazar pour décrire deux modes de développement du Logiciel Libre / Open Source a été établie par Eric S. Raymond il y a bientôt 30 ans. Depuis, les grands exemples de cathédrales se sont transformés en bazars et ce modèle a été largement adopté1 par la plupart des projets de Logiciel Libre. C'est à dire que les modification du code sont publiée en temps plus ou moins réel sans attendre qu'une nouvelle version du logiciel soit disponible. De nos jours, cela se fait souvent via un dépôt git2 (voire GitHub3) disponible à la lecture publiquement sur internet.

trois écoles de divulgation

En parallèle de ce développement, au début du XXIème siècle on débattait furieusement de la meilleure manière de divulguer les failles de sécurité. En gros il y a trois écoles : non-divulgation, divulgation complète et divulgation coordonnée.

L'école de la non-divulgation dit qu'il ne faut jamais divulguer les failles publiquement. L'idée est que moins il y a de personnes qui sont au courant, moins il y a de chances que cela pose problème.

L'école de la divulgation complète dit qu'il est désirable de publier les détails de toutes failles publiquement aussitôt que possible. L'idée est que les utilisateurs et administrateurs ne peuvent prendre des décisions utiles concernant leur propre gestion de risque que s'ils sont informés de ces risques.

L'école de la divulgation coordonnée4 tente de réconcilier les deux. L'idée est d'informer d'abord les personnes qui sont en mesure de corriger le problème (typiquement les développeurs) et de se mettre d'accord avec eux sur le bon moment pour faire une annonce publique.

En 2026, il existe encore nombre d'organisations et individus prônant chacune de ces trois écoles selon leurs motivations financières, modèles de valeurs ou la propagande à laquelle ils ont été la plus efficacement exposés. Cependant, jusqu'à présent je n'avais encore jamais entendu personne articuler clairement que la divulgation coordonnée est fondamentalement incompatible avec le bazar.

le bazar ne peut pas être coordonné

Une faille est publique dès le moment où le correctif est publié (que ça soit sous forme de binaire, de source ou de diff). L'auteur d'un correctif dans un projet bazardesque peut tenter d'obscurcir la nature du changement5 jusqu'à ce qu'une nouvelle version soit disponible (ce qui ne peut arriver qu'après la soumission du changement dans le dépôt). Mais, selon l'importance relative du projet pour les attaquants (et donc les ressources qu'ils ont pour examiner les changements en temps réel), cela ne les trompera pas. Par contre ça fait des changements plus compliqués à comprendre (ce qui me semble aller à l'encontre de la philosophie du bazar) et des utilisateurs/administrateurs qui sont informés plus tard que les attaquants motivés.

Je ne vois donc pas comment réconcilier la divulgation coordonnée avec le bazar. 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é. Ce modèle cathédralesque ne peut pas se limiter à une liste de diffusion privée et des messages de soumission obscurcis. Il faudrait une vraie branche privée dont la publication est retardée jusqu'à ce que l'avis de sécurité soit publié. À ma connaissance, aucun projet bazardesque ne fait cela.

  1. En 2026, combien de projets libres connaissez-vous qui utilisent le modèle de la cathédrale ? Sans chercher, je peux en citer juste un. ↩

  2. malgré l'existence de solutions supérieures ↩

  3. On n'a vraiment rien appris de l'histoire de Microsoft… ↩

  4. Certains appellent cela « divulgation responsable » mais ça implique un jugement de valeur qui décrédibilise les personnes qui adhèrent à la divulgation totale dans des contextes qui peuvent être bien plus responsables que de ralentir la publication. De plus, la terminologie de « divulgation responsable » a été répudiée par l'organisation6 qui l'a inventée/popularisée en faveur de « divulgation coordonnée ». ↩

  5. Comme on a pu le voir dans cet exemple récent. ↩

  6. Microsoft, encore. ↩

  • # Cathédrale

    Posté par  . Évalué à 4 (+2/-0).

    J'en ai deux : sqlite et postfix.

    Je me trompe ?

    • [^] # Re: Cathédrale Libre

      Posté par  (site web personnel, Mastodon) . Évalué à 1 (+0/-1).

      sqlite

      et son VCS décentralisé : Fossil

      Pour rester dans le même domaine, il me semble que Pijul aussi…

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: Cathédrale Libre

      Posté par  (site web personnel, Mastodon) . Évalué à 1 (+0/-1). Dernière modification le 17 mai 2026 à 11:16.

      sqlite

      Dans la même catégorie, SGBD SQL, on a :

      On doit en trouver aussi côté NoSQL, mais j’ai la flemme de vérifier.

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: Cathédrale Libre

        Posté par  (courriel, site web personnel) . Évalué à 2 (+0/-0).

        H2 semble publier ses commits en temps réel, tout comme les deux autres projets cités dans ton autre commentaire. Je comprend pas pourquoi tu penses que c'est pertinent donc je vais pas prendre la peine de vérifier les autres projets que tu cites.

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: Cathédrale Libre

          Posté par  (site web personnel, Mastodon) . Évalué à 2 (+0/-0).

          Organisation de type cathédrale (verticale) vs bazar (± horizontal, ± étoilé/multiple). Je pointe l’organisation du projet, ce qui semblait être l’origine du fil non ?

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: Cathédrale

      Posté par  (courriel, site web personnel) . Évalué à 3 (+1/-0).

      J'avais aussi pensé à SQLite mais ils semblent bien publier leur commitlog en temps réel https://www.sqlite.org/src/timeline

      Le seul que j'ai trouvé est xscreensaver.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: Cathédrale

      Posté par  (courriel, site web personnel) . Évalué à 5 (+3/-0).

      Il semblerait effectivement que Postfix ne publie pas ses commits hors des releases (y compris « releases expérimentales ») et tomberait donc sous la définition de projet cathédralesque dans le sens de ce journal.

      Du coup je peux maintenant dire que je connais deux projets de ce type.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: Cathédrale

        Posté par  . Évalué à 2 (+0/-0).

        Moi aussi j'ai appris des trucs, surtout sur PostFix et SQLite (my love).

        car, pour la Cathédrale vs le Bazaar vs ces diables de CVE, je n'ai pas de religion mais je pencherais plutôt de ton coté à ce sujet ;)

        Merci pour ton journal et les commentaires associés.

        "Si tous les cons volaient, il ferait nuit" F. Dard

    • [^] # Re: Cathédrale

      Posté par  (courriel, site web personnel) . Évalué à 2 (+0/-0).

      J'ai trouvé quelques autres exemples dans https://lcamtuf.coredump.cx/soft/ dont p0f.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # J'ai un peu la même conclusion

    Posté par  . Évalué à 4 (+2/-0). Dernière modification le 17 mai 2026 à 12:36.

    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 :

    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.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.