Krunch a écrit 4133 commentaires

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.

[changeons l'ordre d'affichage des journals]

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.

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-13T15:03:33.113Z. Soit deux jours avant la release.

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

Ça compte pas si l'outil fait

execlp("curl", "curl", "-m30", "-Lksg", "-o", tmp_fname, "--", path, NULL);

?

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.

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.

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.

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.

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.

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.

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.

https://linuxfr.org/users/earendil_fr/journaux/et-ca-continue-dirtyfrag

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

Si c'est une bonne plateforme.

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.

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.

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.

Je pense que l'idéal serait que si quelqu'un poste une dépêche avec un titre en majuscules grasses rouges commençant par 👉URGENT👈 cela outrepasse la modération est soit immédiatement posté avec une notification à tous les membres du site via tous les moyens de communications enregistrés (e-mail, XMPP, Mastodon,…).

Alternativement, les gens que ça intéressent peuvent souscrire aux listes de diffusion adéquates. Par exemple linux-cve-announce ou debian-security-announce.

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

Du coup il est sous quelle licence ton miniscript ?

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

Il y a quoi comme vrais exemples de services webs pour le transfert de fichiers qui ne supporte pas le service d'octet HTTP en 2026 ?

Puis même si ça ne le supporte pas, ça fonctionne. C'est juste que ça recommence de zéro.

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

Sous OpenBSD et tout autre OS supportant pf, on peut limiter la bande passante d'un utilisateur ou d'un hôte distant par exemple. J'imagine que cela doit aussi être possible sous Linux sans installer un nouveau truc qui pèse 30 000 lignes ?

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

• impossibilité de modifier les limites après le début de la sauvegarde

Avec wget tu peux interrompre puis relancer avec -c et toutes les autres options pertinentes.

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

J'ai indiqué la mauvaise langue. Si la modération peut changer cela pour indiquer que le lien est en anglais, ça serait bien urbain. Merci.

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

Je voyais pas trop non plus comment on en serait arrivé à changer la licence de bsdmainutils. Le lien est derrière un paywall donc j'ai aucune idée de quoi il s'agit mais j'ai pas l'impression de perdre grand chose.

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

plus de contrôle aux frontières entre la France et la Belgique. Il y en a entre la Suisse et la France

C'est très théorique. J'ai été contrôlé par des douaniers français après être entré en France depuis le Luxembourg. Je ne me souviens pas avoir été contrôlé en traversant la frontière entre la Suisse et la France.

Mais oui, en pratique, si on est blanc et qu'on ne prend pas l'avion, il y a peu de chances d'être contrôlé entre Bruxelles et la Suisse.

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