Pour les systèmes de stockage en ligne (ce que certains appellent « nuage »), il y a aussi une justification technique potentielle. Il est assez compliqué de présenter les fichiers dans une applications/API web qui se veut fault-tolerant en restant compatible avec une sémantique de système de fichiers POSIX en dessous sans dégrader les performances de manière considérable. De ce que je comprend, même Nextcloud (qui n'a même pas vraiment la contrainte de « fault-tolerance ») ne permet pas de faire ça (e.g. au moins les permissions sont stockées séparément). Selon le logiciel/service il y a plus ou moins de désir de garder une certaine compatibilité mais à partir du moment ou 87.76% des utilisateurs passent 98.42% de leur temps sur un ordiphone et n'ont pas vraiment de notion de hiérarchie de système de fichiers, le désir s'amenuise.
Évidemment c'est pas neutre et « perdre le contrôle » sur l'organisation de ses données a un impact non-technique. Mais je pense qu'il y a aussi une justification technique.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
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.
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.
Par soucis d'équité, il faudra bien sûr faire passer le test rétroactivement à tous les utilisateurs existants sous peine de suppression de leur compte et contenu.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Si on n'a pas de CVE avant la release, ça peut compliquer la communication. Ce journal me semble un bon exemple.
On peut assigner un CVE sans donner aucun détails techniques. Pour un projet de la taille de Linux, savoir qu'il y a un CVE ne donne pas vraiment d'indication sur comment écrire une exploit. Donc je ne vois pas trop le rapport avec la divulgation responsable.
D'ailleurs, si on examine les détails de CVE-2026-46333 on voit que cet identifiant a été réservé à 2026年05月13日T15:03:33.113Z. Soit deux jours avant la release.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Du coup en lisant https://docs.kernel.org/process/cve.html je note qu'en général Linux n'assigne un CVE qu'une fois qu'il y a un fix disponible pour un noyau stable.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
L'argument écolo est un peu faible sachant qu'on ne s'est pas privé de parler cryptomonnaies, minage et blockchain.
Je pense qu'il n'y a pas de problème à discuter des LLM (ou de cryptomonnaie ou de blockchain ou de pétrole ou de guerre ou de pandémie etc). Si Linuxfr devenait un endroit où on utilise des cryptomonnaies (ou des LLM) de manière non-anecdotique, ça me semble plus problématique (d'un point de vue écologique notamment).
Y a t'il d'autres raisons que j'ignore ?
De mon point de vue, Linuxfr est un endroit fait pour que les humains francophones puissent échanger. Si une partie des utilisateurs ne sont pas humains, ça change complètement la dynamique. Personnellement je n'ai aucun intérêt à « discuter » avec un bot. Si je commence à soupçonner qu'une partie non-triviale de Linuxfr est constituée de bots, je risque de ne plus venir très souvent.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Surtout que la mitigation des précédents fonctionne aussi. Donc au final, fallait mitiger la première faille puis aller en vacances. On pourra patcher quand la vague sera passée.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Linuxfr n'est pas en position de divulguer ce genre de bogues de sécurité (à moins que la rédaction ne fasse du pentesting elle-même ou soit sur la liste de diffusion distros@ ou similaire). Linuxfr ne peut que relayer. Donc que la divulgation soit responsable ou pas n'a aucune importance dans ce contexte.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Je pense que linuxfr est une bonne plateforme pour discuter de ce genre de choses.
Je pense que linuxfr est une mauvaise plateforme pour être informé en temps voulu des mitigations et patches de sécurité à appliquer en urgence. Si l'équipe de linuxfr veut changer cela, il y a des évolutions qui peuvent être considérées mais ça ne me semble pas particulièrement pertinent dans le sens où il y a déjà d'autres plateformes qui jouent ce rôle et où ça dérouterait de l'énergie qui serait sans doute mieux investie à maintenir et améliorer le bon fonctionnement de l'aspect discussion.
Je contribue volontiers à la rédaction d'une dépêche de fond sur les bogues de sécurité en général ou cette série de bogues en particulier si quelqu'un veut se lancer là dedans.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
J'en pense que zéro fait référence au nombre de jours que les développeurs ont eu pour corriger le problème avant qu'il soit public. Dans ce cas, de ce que je comprend, il ont eu plus que zéro jours de notice. Ça semble aussi être la définition de Wikipedia.
Même s'il n'y a pas encore de correctif complet, ça fait plus que zéro jours qu'on a une mitigation tout à fait valable pour la plupart des utilisateurs. Donc même en prenant la définition de « jours depuis un correctif/mitigation », ça reste >0 . C'était techniquement 0 au moment de l'annonce, mais c'est pas très utile comme définition puisque c'est le cas de tous les bugs/correctifs de sécurité.
Pour Debian (et les autres distros), s'ils n'ont pas été mis au courant avant l'annonce publique (ce qui semble être le cas), j'accepte techniquement la définition de zéro jour mais ça me semble pas super pertinent. Au final ils attendent quand même le patch upstream pour pouvoir le porter. C'est plus sympa quand tout est coordonné mais il y a plein de logiciels de moindre envergures pour lesquels c'est pas fait et on crie pas au zero day parce que toutes les distros ont pas été informées en avance.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# communiqué de presse
Posté par Krunch (courriel, site web personnel) . En réponse au lien Infomaniak passe sous le contrôle d’une fondation d’utilité publique. Évalué à 2 (+1/-1).
Le communiqué de presse d'Infomaniak https://www.presseportal.ch/fr/pm/100057093/100940147
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: J'ai un peu la même conclusion
Posté par Krunch (courriel, site web personnel) . En réponse au journal gestion de failles de sécurité bazardeuse. Évalué à 4 (+2/-0).
Je viens de retomber sur https://www.openbsd.org/security.html#disclosure qui explique que OpenBSD supporte la divulgation complète.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# raisons techniques
Posté par Krunch (courriel, site web personnel) . En réponse au journal On nous cache tout on nous dit rien (rendez-moi mon filesystem !). Évalué à 2 (+0/-0).
rewind< a déjà expliqué le paradigme app-first pour les ordiphones.
Pour les systèmes de stockage en ligne (ce que certains appellent « nuage »), il y a aussi une justification technique potentielle. Il est assez compliqué de présenter les fichiers dans une applications/API web qui se veut fault-tolerant en restant compatible avec une sémantique de système de fichiers POSIX en dessous sans dégrader les performances de manière considérable. De ce que je comprend, même Nextcloud (qui n'a même pas vraiment la contrainte de « fault-tolerance ») ne permet pas de faire ça (e.g. au moins les permissions sont stockées séparément). Selon le logiciel/service il y a plus ou moins de désir de garder une certaine compatibilité mais à partir du moment ou 87.76% des utilisateurs passent 98.42% de leur temps sur un ordiphone et n'ont pas vraiment de notion de hiérarchie de système de fichiers, le désir s'amenuise.
Évidemment c'est pas neutre et « perdre le contrôle » sur l'organisation de ses données a un impact non-technique. Mais je pense qu'il y a aussi une justification technique.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: J'ai un peu la même conclusion
Posté par Krunch (courriel, site web personnel) . En réponse au journal gestion de failles de sécurité bazardeuse. Évalué à 4 (+2/-0).
La divulgation coordonnée requiert clairement plus de travail et favorise donc les projets qui ont les moyens.
On notera qu'en mai 2025, le mainteneur de libxml2 a décidé de passer de la divulgation coordonnée à la divulgation complète par manque de moyen. Puis en septembre il a « démissionné » (c'est passé ici). Puis en décembre le projet est revenu vers un modèle de divulgation coordonné.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Cathédrale
Posté par Krunch (courriel, site web personnel) . En réponse au journal gestion de failles de sécurité bazardeuse. É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 Libre
Posté par Krunch (courriel, site web personnel) . En réponse au journal gestion de failles de sécurité bazardeuse. É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 Krunch (courriel, site web personnel) . En réponse au journal gestion de failles de sécurité bazardeuse. Évalué à 2 (+0/-0).
Fossil et Pijul semblent publier leurs commits en temps réel.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Cathédrale
Posté par Krunch (courriel, site web personnel) . En réponse au journal gestion de failles de sécurité bazardeuse. É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: Modération à l'inscription
Posté par Krunch (courriel, site web personnel) . En réponse au journal [LinuxFr] Confiance, IA et contenu. Évalué à 3 (+1/-0).
Par soucis d'équité, il faudra bien sûr faire passer le test rétroactivement à tous les utilisateurs existants sous peine de suppression de leur compte et contenu.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Comment faire appliquer la règle!
Posté par Krunch (courriel, site web personnel) . En réponse au journal [LinuxFr] Confiance, IA et contenu. Évalué à 4 (+2/-0).
J'ai passé des heures à trouver le moment optimal pour poster et tu veux jeter tout ce travail à la poubelle ?!
https://linuxfr.org/users/krunch/journaux/dlfp-journalyser-2-0-pas-de-veille-techologique-le-weekend
https://linuxfr.org/users/krunch/journaux/dlfp-journalyser-2-1-rester-au-top
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: cve ?
Posté par Krunch (courriel, site web personnel) . En réponse au journal une ligne du temps de la dernière faille du noyau Linux (une autre). Évalué à 3 (+1/-0). Dernière modification le 16 mai 2026 à 17:03.
Si on n'a pas de CVE avant la release, ça peut compliquer la communication. Ce journal me semble un bon exemple.
On peut assigner un CVE sans donner aucun détails techniques. Pour un projet de la taille de Linux, savoir qu'il y a un CVE ne donne pas vraiment d'indication sur comment écrire une exploit. Donc je ne vois pas trop le rapport avec la divulgation responsable.
D'ailleurs, si on examine les détails de CVE-2026-46333 on voit que cet identifiant a été réservé à 2026年05月13日T15:03:33.113Z. Soit deux jours avant la release.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Incomplet
Posté par Krunch (courriel, site web personnel) . En réponse au lien gestion de dépendances modernes en C/C++. Évalué à 3 (+1/-0).
Ça compte pas si l'outil fait
?
La précompilation ça me semble aller à l'encontre de l'injonction d'utiliser le maximum de ressources possibles.
Par ailleurs je recommande la lecture du contenu de l'archive.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: cve ?
Posté par Krunch (courriel, site web personnel) . En réponse au journal une ligne du temps de la dernière faille du noyau Linux (une autre). Évalué à 4 (+2/-0).
Du coup en lisant https://docs.kernel.org/process/cve.html je note qu'en général Linux n'assigne un CVE qu'une fois qu'il y a un fix disponible pour un noyau stable.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: cve ?
Posté par Krunch (courriel, site web personnel) . En réponse au journal une ligne du temps de la dernière faille du noyau Linux (une autre). Évalué à 4 (+2/-0).
Je n'avais connaissance du CVE au moment de rédiger ce journal. Je vois maintenant qu'il s'agit de CVE-2026-46333 tel que publié par Greg Kroah-Hartman sur linux-cve-announce à 12:58 UTC.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# archive.org
Posté par Krunch (courriel, site web personnel) . En réponse au lien divulgation par carotte. Évalué à 2 (+0/-0).
Le site a l'air mort pour le moment donc voici un miroir : https://web.archive.org/web/20260429080727/https://dustri.org/b/carrot-disclosure.html
Aussi disponible dans Paged Out! #4 page 51.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# bloub
Posté par Krunch (courriel, site web personnel) . En réponse au journal Nouvelle Faille Linux CVE-2026-46300 Fragnesia. Évalué à 6 (+4/-0).
Tu as déjà une faille de retard. On en est à __ptrace_may_access aujourd'hui.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# pas libre
Posté par Krunch (courriel, site web personnel) . En réponse au journal Idée de code pour le weekend. Évalué à 7 (+6/-1).
C'est un peu bizarre de promouvoir un logiciel non-libre sur un site web conçu pour promouvoir les Logiciels libres.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: qu'est ce qui vous gêne ?
Posté par Krunch (courriel, site web personnel) . En réponse au journal [LinuxFr] Confiance, IA et contenu. Évalué à 10 (+25/-1).
Je pense qu'il n'y a pas de problème à discuter des LLM (ou de cryptomonnaie ou de blockchain ou de pétrole ou de guerre ou de pandémie etc). Si Linuxfr devenait un endroit où on utilise des cryptomonnaies (ou des LLM) de manière non-anecdotique, ça me semble plus problématique (d'un point de vue écologique notamment).
De mon point de vue, Linuxfr est un endroit fait pour que les humains francophones puissent échanger. Si une partie des utilisateurs ne sont pas humains, ça change complètement la dynamique. Personnellement je n'ai aucun intérêt à « discuter » avec un bot. Si je commence à soupçonner qu'une partie non-triviale de Linuxfr est constituée de bots, je risque de ne plus venir très souvent.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Pas universelle ?
Posté par Krunch (courriel, site web personnel) . En réponse au lien Fragnesia, une faille du noyau Linux avec élévation de privilèges. Évalué à 4 (+2/-0). Dernière modification le 13 mai 2026 à 19:43.
Surtout que la mitigation des précédents fonctionne aussi. Donc au final, fallait mitiger la première faille puis aller en vacances. On pourra patcher quand la vague sera passée.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Ah désolé je viens de poster à ce sujet en forum et liens, je n'avais pas vu ce journal
Posté par Krunch (courriel, site web personnel) . En réponse au journal Et ça continue [DirtyFrag]. Évalué à 6 (+4/-0). Dernière modification le 08 mai 2026 à 21:18.
Linuxfr n'est pas en position de divulguer ce genre de bogues de sécurité (à moins que la rédaction ne fasse du pentesting elle-même ou soit sur la liste de diffusion distros@ ou similaire). Linuxfr ne peut que relayer. Donc que la divulgation soit responsable ou pas n'a aucune importance dans ce contexte.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# bloub
Posté par Krunch (courriel, site web personnel) . En réponse au lien Dirty Frag : la nouvelle faille Linux qui donne root en local. Évalué à 4 (+2/-0).
https://linuxfr.org/users/earendil_fr/journaux/et-ca-continue-dirtyfrag
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Ah désolé je viens de poster à ce sujet en forum et liens, je n'avais pas vu ce journal
Posté par Krunch (courriel, site web personnel) . En réponse au journal Et ça continue [DirtyFrag]. Évalué à 8 (+6/-0).
Je pense que linuxfr est une bonne plateforme pour discuter de ce genre de choses.
Je pense que linuxfr est une mauvaise plateforme pour être informé en temps voulu des mitigations et patches de sécurité à appliquer en urgence. Si l'équipe de linuxfr veut changer cela, il y a des évolutions qui peuvent être considérées mais ça ne me semble pas particulièrement pertinent dans le sens où il y a déjà d'autres plateformes qui jouent ce rôle et où ça dérouterait de l'énergie qui serait sans doute mieux investie à maintenir et améliorer le bon fonctionnement de l'aspect discussion.
Je contribue volontiers à la rédaction d'une dépêche de fond sur les bogues de sécurité en général ou cette série de bogues en particulier si quelqu'un veut se lancer là dedans.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: mise à jour
Posté par Krunch (courriel, site web personnel) . En réponse au message Nouvelle faille zero-day Linux « Dirty Frag ». Évalué à 5 (+3/-0).
J'en pense que zéro fait référence au nombre de jours que les développeurs ont eu pour corriger le problème avant qu'il soit public. Dans ce cas, de ce que je comprend, il ont eu plus que zéro jours de notice. Ça semble aussi être la définition de Wikipedia.
Même s'il n'y a pas encore de correctif complet, ça fait plus que zéro jours qu'on a une mitigation tout à fait valable pour la plupart des utilisateurs. Donc même en prenant la définition de « jours depuis un correctif/mitigation », ça reste >0 . C'était techniquement 0 au moment de l'annonce, mais c'est pas très utile comme définition puisque c'est le cas de tous les bugs/correctifs de sécurité.
Pour Debian (et les autres distros), s'ils n'ont pas été mis au courant avant l'annonce publique (ce qui semble être le cas), j'accepte techniquement la définition de zéro jour mais ça me semble pas super pertinent. Au final ils attendent quand même le patch upstream pour pouvoir le porter. C'est plus sympa quand tout est coordonné mais il y a plein de logiciels de moindre envergures pour lesquels c'est pas fait et on crie pas au zero day parce que toutes les distros ont pas été informées en avance.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Ah désolé je viens de poster à ce sujet en forum et liens, je n'avais pas vu ce journal
Posté par Krunch (courriel, site web personnel) . En réponse au journal Et ça continue [DirtyFrag]. Évalué à 5 (+3/-0).
C'est uniquement de l'humour si on considère que LinuxFr n'est pas la bonne plateforme pour diffuser « ce type d'info urgente ».
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: mise à jour
Posté par Krunch (courriel, site web personnel) . En réponse au message Nouvelle faille zero-day Linux « Dirty Frag ». Évalué à 4 (+2/-0).
Techniquement c'est pas un 0 day. La faille a été connue des développeurs pendant environ une semaine avant qu'elle n'ai été publiée.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.