Rust règle une querelle qui date d'avant laenaissance d'emacs: il existe des langages de programmation dans lesquels il est quasiment impossible d'avoir des bugs de gestion de mémoire (utiliser de la mémoire déjà libérée, libérer deux fois un bloc de mémoire, …). Par exemple en lisp, en smalltalk, en python, …
Tous ces langages utilisent diverses stratégies de gestion de la mémoire qui ont un coût à l'exécution en termes de performances: le programme plante moins, mais il est aussi plus lent.
Rust propose une approche qui semble avoir mis tout le monde d'accord: sa méthode de gestion oe la mémoire met en jeu une algorthmique complexe, il est donc lent comme tous les langages gérant la mémoire tout seuls, mais ce coût est déporté vers la compilation plutôt que l'exécution. La concurrence étant C++ qui est très lent à compiler lui aussi, cela a permis de faire enfin admettre aux derniers réfractaires des langages non sûrs qu'ils avaient tort depuis le début.
Ah et Rust a aussi un mode "unsafe" dans lequel la gestion sûre de la mémoire est désactivée. Ainsi les gens persuadés que un langage à la fois rapide et parfaitement sécurisé est impossible, peuvent continuer d'avoir raison, mais les dommages sont limités car très peu de code devrait utiliser cette possibilité, poussant le débat un pas plus loin vers une querelle purement théorique et cessant de mettre en danger toute personne ou donnée qui se trouve dans un ordinateur contenant du code non sûr susceptible d'exploser à tout moment.
J'ai tenté un MITM avec du ARP spoofing pour observer le trafic entre le robot et le serveur mais sans succès. Ce sont des connexions HTTPS et les certificats sont réellement vérifiés des deux côtés, pas possible de se substituer à l'un ou l'autre.
Est-ce que le robot dispose par hasard du fameux certificat emudhra dont la clé privée est 4? Parce que cela peut être un moyen de contourner ce problème en créant un certificat valide.
Si le serveur de l'autre côté vérifie le certificat du robot, par contre, ça ne suffira pas.
J'avais vu une démo d'une autre méthode (lors des rmll il me semble) qui consiste à mettre un breakpoint dans les fonctions read et write oes sockets de openssl, là où l'application envoie et reçoit (en clair) les données qui vont ensuite être chiffrées en https, afin d'espionner le traffic.
Vu que ça va peut-être être le dernier robot à se connecter au service, il est temps de faire un peu d'enregistrement de données avant que le serveur soit hors ligne, cela facilitera grandement l'écriture d'un serveur de remplacement le jour où ce sera nécessaire.
Chez Python la maintenance des anciennes versions c'est 5 ans dont 2 pendant lesquels ils s'autorisent des corrections de bugs (source: https://devguide.python.org/versions/).
En tout cas, avoir des versions fixes avec uniquement de la correction de bug permet de faire les montées en version à son propre rythme, pas dans la panique harce que un matin on essaie de déployer un truc et que d'un coup ça marche plus. Mais avoir quelques mois ou idéalement quelcues années de support est suffisant pour ça, non?
Une fois qu'il est banni des app stores, perdu pour perdu, tu peux faire une version qui s'installe toute seule sur les téléphones à proximité en exploitant les failles de sécurité d'Android et iOS. Comme ça tu vas dans une manifestation et le réseau se déploie tout seul!
En résumé: la faille permet d'abord d'extraire l'adresse de base du code et du tas pour l'allocation mémoire (qui sont toutes les deux choisies aléatoirement au démarrage d'un worker PHP). à partir de ces deux valeurs et en connaissant exactement le binaire de PHP utilisé (en l'occurence, celui compilé par Alpine Linux), on peut arriver, en utilisant la faille une troisième fois, à injecter une structure de données qui sera appelée par la fonction cleanup de php. On peut à ce niveau exécuter le code révélant l'adresse du portefeuille bitcoin (mais en principe on pourrait exécuter n'importe quelle autre commande sur le serveur).
Il reste donc la contrainte que ce script ne s'applique qu'à une version compilée spécifique de PHP, mais il est adaptable à d'autres versions (il y a plusieurs valeurs codées en dur dans le script pour correspondre à ce build spécifique de PHP, mais ça peut être ajusté pour cibler un autre build et probablement pour essayer d'en reconnaître plusieurs différents).
L'attaque se déroule au total en une vingtaine de requêtes HTTP, et réussit environ 7 fois sur 10 (ça dépend entre autres du fait d'arriver à exécuter plusieurs requêtes sur le même worker, en fonction de la configuration et de la charge de la cible, cela peut être plus compliqué sur un site qui reçoit beaucoup plus de traffic).
On peut donc être "rassuré", la faille est bien exploitable et l'estimation de risque plutôt correcte.
Cela ne démontre pas que l'exploitation est impossible, mais, soit qu'elle coûte plus de 2000 dollars de token de LLM, soit que c'est suffisament compliqué pour être hors de portée du premier script kiddie venu, et qu'une attaque éventuelle reste entre les mains de gens qui préfèrent garder leurs attaques sous la main pour des cibles plus intéressantes
Un LLM est peut-être négessaire, mais pas suffisant.
L'article de Sansec qui prévoyait la fin du monde une exploitation massive dans les 15 minutes suivant la publication a été mis à jour avec un bandeau expliquant que finalement, l'attaque nécessite de très bien connaître l'intérieur du serveur cible, et que l'exploit publié ne fonctionne pas de façon aussi générule qu'annoncé. Les exploits publiés, soit ont besoin d'un fichier déjà vulnérable à une attaque par inclusion de fichier local, soit sont générées par un LLM qui injecte lui-même une telle vulnérabilité dans le système qu'on lui demande de tester.
Recorded future (qui existe depuis 2012) annonce de nombreuses tentatives de scan et d'attaque, mais pas de chiffres disponibles sur le succès des attaquants.
Les vendeurs de solution de sécurité semble profiter un peu de la panique pour se faire de la publicité, avec un argument infaillible du genre "ce type d'attaque est irréalisable si votre serveur est équipé de notre solution" (sans préciser que c'est irréalisable aussi sur les serveurs non équipés de leur solution).
En attendant on est noyés sous les tentatives de proof of concept ne fonctionnant pas vraiment, dont certains prétendant exploiter une faille basée sur des rumeurs avant publication des détails et qui n'existe tout simplement pas. Malheureusement, la déconnexion avec la réalité rend difficile de trouver et de faire confiance à des vraies informations.
La réaction à l'annonce est la bonne, vu le score élevé et le risque d'exécution de code arbitraire. Mais il y a eu pas mal de site hors ligne pendant une demi journée.
La question est, est-ce que l'annonce elle-même n'était pas un peu exagérée? Est-ce que finalement la réaction de tout mettre hors ligne ne cause pas plas d'ennuis que la faille qui finalement n'est pas si simple à exploiter que ça?
Est-ce que si on commence à avoir des failles annoncées comme ça tous les jours, alors que inalement ce n'est pas exploitable, les gens vont arrêter de mettre leur site hors ligne à chaque fois?
Appeler "soleil ASCII" un caractère qui n'est ni un soleil, ni présent dans ASCII, et l'illustrer par un autre caractère soleil d'Unicode, c'est vraiment difficile à suivre, votre truc.
Tu dis que ça a été refusé sans donner de motif, mais je me permet de reposer la question à savoir pourquoi la raison classique "il n'y a pas de place, on a du faire des choix difficiles", raison qui est listé dans l'appel, ne suffit pas ? Il y a quoi qui fait qu'il faudrait motiver plus pour cette proposition et pas les autres ?
Ben justement c'est ça la question.
Qu'il y aie pas de place pour tout le monde, effectivement, c'est un problème bien connu du FOSDEM (et la solution serait d'avoir plus de conférences à d'autres endroits).
Donc la justification "on ne peut pas accepter tout le monde parce que y'a pas la place" ben… ça justifie rien du tout. Si la justification était "on a fait un tirage au sort", au moins on sait que c'est équitable et non biaisé par les préférences personnelles des organisateurs. Ou si la justification est "on a fait un vote et ce sujet a perdu", on sait que ce sont les préférences personnelles des organisateurs qui pensent que d'autres sujets sont plus intéressants, c'est un process démocratique qui entretient les biais des votants. Ou encore si c'est "on en a marre de vos trucs de gauchistes woke, ici c'est une conférence sur la technologie neutre, on a donc choisi de privilégier les sujets techniques", au moins on sait à quoi s'en tenir. Ou alors si c'est "votre proposition était mal rédigée et ne nous a pas convaincus", ou "les thèmes proposés peuvent être abordés dans d'autres devrooms", OK, très bien.
Je pense que recevoir un refus sans explication à part "y'avait plus de place", ça donne un sentiment d'impuissance car on ne peut pas comprendre où est le problème et comment faire pour réessayer l'année suivante avec de meilleures chances de succès (ou se dire que c'est définitivement sans espoir et organiser une contre-conférence).
Et surtout, tu n'as pas posté sur le sujet de ce que je vois (ou tout cas pas cette année), alors qu'un message a été posté.
Comme tu n'as pas posté, personne n'a mis ton message en lien sur Linuxfr avec un titre sans donner trop de contexte.
Non pas cette année, l'appel à participation pour les stands est encore ouvert et j'ai pas encore envoyé la candidature (vous me direz, si on ne candidate pas, pas de risque d'être refusé). On verra le moment venu.
C'était l'an dernier et il a 3 ans que nous n'avons pas eu de stand.
Nous avons aussi été avec ReactOS les premiers projets à n'avoir droit qu'à un demi-stand, soit une journée chacun, soit la moitié de l'espace alloué à d'autres projets, après avoir auto-organisé ça les années où un seul des deux projets étaient acceptés.
Avant ça, vous avez peut-être connu mmu_man faisant homme sandwich pour présenter Haiku malgré l'absence de stand, puis ensuite le stand dans le bâtiment AW tout au fond de l'université, avec les projets d'électronique et de systèmes embarqués.
Pendant ce temps, en face on a une poignée de distributions Linux qui disent toutes être un clone de l'autre (y'a 3 ans c'était l'explosion de CentOS avec ses 3 ou 4 forks qui font tous exactement la même chose mais qui ont eu chacun un stand complet).
Quand je râle et que je suis déçu parce que le FOSDEM n'accepte pas le stand de Haiku (ce qui arrive régulièrement), ou qu'il y a une devroom "kernel" qui ne prend même pas la peine de préciser qu'il s'agit uniquement de Linux et pas des autres noyaux, personne ne dit que j'utilise les "mécanismes d'outrages des forces réactionnaires".
Pourquoi le ressenti est différent quand il s'agit d'une devroom sur la diversité et l'inclusion? (sujet autrement plus important que Haiku, à mon avis).
J'imagine que les contraintes et critères d'une devroom sont distincts de celle pour une conf'.
Les devrooms sont les salles dans lesquelles il y a des conférences. Une fois la devroom acceptée, son (ou sa) responsable lance son propre "cfp" (call for participation) et monte lui/elle-même le programme en choisissant parmi les conférences proposées.
Les organisateurs du FOSDEM vont sans doute répondre qu'ils sont désolés, que la place est limitée et qu'ils ont préféré choisir d'autres sujets même si c'est toujours une décision difficile (ce qui est vrai).
Pourtant c'est un sujet pour lequel il y aurait plein de choses à dire et à faire, ce que soit pour l'accessibilité des logiciels, pour l'internationalisation, pour ce qu'on attend des développeurs (est-il nécessaire de pouvoir se payer un abonnement à un LLM à 3000$ par mois pour pouvoir contribuer par exemple?) ainsi que toutes les problématiques de harcèlement, sexisme, racisme, la mise en place de codes de conduite et leur application lorsque c'est nécessaire, et ainsi de suite.
Ce n'est pas dans l'annonce publique (on ne va pas non plus donner aux attaquants les moyens de reproduire l'attaque) mais plusieurs personnes ont pu confirmer que l'une des clés priâées en question étaxt bien 4.
Il ne s'agit pas de cryptographie RSA (ou la clé est deux nombres premiers) mais de courbes elliptiques (où la clé peut être n'importe quelle valeur aléatoire de 256 bits).
Ce n'est pas encore tout à fait clair ce qu'il s'est passé pour que 8 certificats soient signés avec des clés dont les 248 bits oe poids fort sont tous à 0. Les valeurs des 8 clés (et des liens vers plus oe détails) par exemple sur ce fil fediverse.
Concernant les caractères autorisés dans une chaîne de caractères JSON, tout est autorisé sauf les caractères de contrôle ascii (dont notamment \n), le caractère \ et les guillemets fermants, qui doivent être échappés.
Ces caractères de contrôle sont donc interdits dans les chaînes de caractères en JSON.
All code points may be placed within the quotation marks except for the code points that must be escaped: quotation mark (U+0022), reverse solidus (U+005C), and the control characters U+0000 to U+001F.
De façon surprenante, le codepoint U+007F, lui, est autorisé sans échappement. En ASCII et en Unicode il s'agit de DELETE qui est un caractère de contrôle. Les tabulations et retours à la ligne (dans leur forme ASCII) sont, eux, interdits.
Le programme unicode me sort un truc assez surprenant, il me les désigne tous les quatre comme des “paragraph separators” ou “segment separator” pour \x1f ou encore “information separators” four three two one…
Ce sont bien les noms choisis par Unicode. Ils sont différents des noms qui étaient utilisés dans la spécification ASCII, même si ce sont les mêmes caractères.
Cette fois ci il est question de "ripping off", avec des exemples de paragraphes identiques.
This was a ripoff. My post yesterday was trying to be as charitable as possible given what I knew, and in particular that the similarity to Mononoke was mostly unintentional and the lack of credit was the result of not doing due diligence. However, after publishing the post I privately received confirmation that Scion intentionally and blatantly ripped off Mononoke, and in particular that there was overlap in personnel.
Donc Anthropic a embauché des gens qui avaient travaillé auparavant sur Mononoke, et leur on demandé de développer un nouveau système qui est en fait assez identique et sans citer son inspiration. Puis fait passer cela pour nouveau et révolutionnaire.
Suite à ces deux messages de blog, Anthropic a tout de même fini par mettre à jour son article (c'est indiqué au début des deux: l'article d'Anthropic et le deuxième blog ci-dessus).
Dans le cas qui nous concerne ici, c'est du plagiat, aved des paragraphes recopiés tels quels et sans attribution. C'est illégal et irrespectueux du travail original. Que ça soit fait par un humain ou un LLM ne change rien au problème.
La grosse nouvelle précédente était sur un clone de photoshop qui, s'il n'y a pas plagiat, pourrait au moins être qualifié de parasitisme.
Pourquoi c'est à chaque fois comme ça? Pourquoi personne ne parle des projets innovants et révolutionnaires qui vont là ou aucun humain n'est jamais allé? Logiquement il devrait y en avoir plein?
Il y a plein de choses qui peuvent être faites avec un ordinateur sans avoir besoin d'un analyste programmeur professionnel.
Ça va de la simhle utilisation de traitement de texte à du développement python. Quelque part entre les deux il y a Excel et les tableurs, qu'on peut agrémenter de macros, les bases de données access ou similaire, et il y a aussi des solutions comme windev.
De ce point de vue là ça ne me semble pas délirant, et c'est même assez cohérent avec ma vision du logiciel libre (partager mes connaissances et le résultat de mon travail au plus grand nombre et donner à chacun la possibilité de s'en emparer).
Là où ça diverge, c'est dans le choix d'une techno fermée avec une license restrictive et qui peut changer. Pour autant, je ne pense pas qu'il faut se moquer ou dévaloriser ces utilisations d'outils informatiques. Pas besoin de faire de l'élitisme.
s’il n’aime pas utiliser github pour linux, il n’a aucun problème pour s’en servir pour ces petits projets
historiquement Linux était hébergé sur bitkeeper, un système de gestion de versions très propriétaire. Le projet avait un accès gratuit tant qu'il ne tentait pas de développer un client libre, ce qu'un autre développeur a tout de même commencé à faire.
Les relations se sont gâtées et Linus a fini par démarrer le développement de Git pour remplacer bitkeeper.
Sans toute cette histoire, Github n'existerait pas. Peut-être que tous les projets seraient toujours chez Sourceforge ou chez Google Code Project Hosting.
Même facilité pa un LLM, le reverse engineering ou la réimplémentation d'un logiciel demande du temps et des compétences. C'est pas un truc où on clique sur un bouton et pouf, on a un logiciel qui fait tout comme on veut.
Peut-être que, oui, patcher un logiciel existant (même sans les sources) est moins cher que d'en réécrire un, et c'est sûrement plus facile de le faire avec l'aide d'un LLM si on a pas l'habitude de manipuler un désassembleur (compétence relativement rare).
Le problème, c'est que patcher un logiciel existant sans l'accord de l'auteur, c'est illégal.
J'ai travaillé dans une entreprise qui était de l'autre côté de ce problème: impossible de vendre notre solution à des gens qui n'avait pas confiance dans la perrenité de l'entreprise (bien que convaincus sur le plan technique). La solution était un dépôt régulier des sources à l'agence pour la protection des programmes, avec une garantie que nos clients pourraient en récupérer une copie en cas de faillite (ça s'appelle apparament en français un entiercement.
Si vous êtes inquiets de la santé de vos fournisseurs, faites ça plutôt que de compter sur un LLM pour rattraper votre insouciance?
Bonjour, dans Haiku les contributions contenant du code généré par IA sont interdites en raison de risques au niveau du copyright. On est particulièrement inquiet sur ce sujet car les LLM ont été entraînés par exemple sur le code de linux qui est sous GPL, et si on demande d'écrire un driver pour du matériel spécifique, il y a d'assez fortes chances que le code ressemble beaucoup à celui de Linux.
Par ailleurs nous avons tout plein d'autres raisons de détester et de vouloir interdire l'utilisation de LLM une fois que ce problème aura une réponse.
Les contributions où les gens demandent de l'aide à un LLM mais rédigent le code eux-même sont autorisées, mais mal vues, surtout si cela a causé une déconnexion avec la réalité (c'est malheureusement le cas de plusieurs de nos utilisateurs, ça l'était déjà avant l'arrivée des LLM mais le phénomène est renforcé). C'est difficile d'être plus restrictif que ça là dessus, car on ne peut pas vraiment savoir ce que les gens ont fait et aussi parce que l'argument du copyright ne s'applique pas. Pour l'instant un rejet pour des raisons perçues comme politiques par une partie de la communauté n'est pas envisageable. Personellement je prévois de continuer à me battre pour que le projet se politise un peu plus.
Au niveau de Haikuports, on rejette les paquets de logiciels vibe codés, mais on ne va pas faire la chasse à la moindre contribution assistée par LLM dans chaque logiciel. Les recettes doivent être écrites et envoyées par des humains (sinon nous étions exposés à une avalanche de trucs faits par des robots).
S'agit-il d'une politique laxiste? Que faudrait-il faire de plus?
Nous avons également un gros travail à faire pour mettre à jour notre documentation afin de faciliter les contributions par des humains, afin de rester constructifs et de ne pas juste se lamenter sur la fin du monde.
[^] # Re: 50 ans...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Emacs a 50 ans. Évalué à 9 (+6/-0).
Rust règle une querelle qui date d'avant laenaissance d'emacs: il existe des langages de programmation dans lesquels il est quasiment impossible d'avoir des bugs de gestion de mémoire (utiliser de la mémoire déjà libérée, libérer deux fois un bloc de mémoire, …). Par exemple en lisp, en smalltalk, en python, …
Tous ces langages utilisent diverses stratégies de gestion de la mémoire qui ont un coût à l'exécution en termes de performances: le programme plante moins, mais il est aussi plus lent.
Rust propose une approche qui semble avoir mis tout le monde d'accord: sa méthode de gestion oe la mémoire met en jeu une algorthmique complexe, il est donc lent comme tous les langages gérant la mémoire tout seuls, mais ce coût est déporté vers la compilation plutôt que l'exécution. La concurrence étant C++ qui est très lent à compiler lui aussi, cela a permis de faire enfin admettre aux derniers réfractaires des langages non sûrs qu'ils avaient tort depuis le début.
Ah et Rust a aussi un mode "unsafe" dans lequel la gestion sûre de la mémoire est désactivée. Ainsi les gens persuadés que un langage à la fois rapide et parfaitement sécurisé est impossible, peuvent continuer d'avoir raison, mais les dommages sont limités car très peu de code devrait utiliser cette possibilité, poussant le débat un pas plus loin vers une querelle purement théorique et cessant de mettre en danger toute personne ou donnée qui se trouve dans un ordinateur contenant du code non sûr susceptible d'exploser à tout moment.
# La réponse est 4
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Robot cuiseur abandonné et reverse engineering. Évalué à 6 (+3/-0).
Est-ce que le robot dispose par hasard du fameux certificat emudhra dont la clé privée est 4? Parce que cela peut être un moyen de contourner ce problème en créant un certificat valide.
Si le serveur de l'autre côté vérifie le certificat du robot, par contre, ça ne suffira pas.
J'avais vu une démo d'une autre méthode (lors des rmll il me semble) qui consiste à mettre un breakpoint dans les fonctions read et write oes sockets de openssl, là où l'application envoie et reçoit (en clair) les données qui vont ensuite être chiffrées en https, afin d'espionner le traffic.
Vu que ça va peut-être être le dernier robot à se connecter au service, il est temps de faire un peu d'enregistrement de données avant que le serveur soit hors ligne, cela facilitera grandement l'écriture d'un serveur de remplacement le jour où ce sera nécessaire.
[^] # Re: 50 ans...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Emacs a 50 ans. Évalué à 6 (+3/-0).
Bien sûr que si, il y a le mode doctor qui est une implémentation de ELIZA, le top de l'intelligence artificielle d'il y a 50 ans! A priori cela a été implémenté en 1987 d'après la notice de copyright de https://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/areas/classics/eliza/emacs/doctor.el
[^] # Re: Changements rsync
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Debian, IA, vibe coding & rsync : la croisée des chemins ?. Évalué à 5 (+2/-0). Dernière modification le 28 octobre 2026 à 17:38.
Chez Python la maintenance des anciennes versions c'est 5 ans dont 2 pendant lesquels ils s'autorisent des corrections de bugs (source: https://devguide.python.org/versions/).
PHP c'est 4 ans avec également 2 ans de correction de bugs: https://www.php.net/supported-versions.php
Go c'est environ 1 an: https://versionlog.com/golang/ c'est effectivement très court.
Javascript je sais pas, puisque il y a plusieurs interpréteurs. Chez NodeJS c'est 3 ans d'après https://github.com/nodejs/release#release-schedule
En tout cas, avoir des versions fixes avec uniquement de la correction de bug permet de faire les montées en version à son propre rythme, pas dans la panique harce que un matin on essaie de déployer un truc et que d'un coup ça marche plus. Mais avoir quelques mois ou idéalement quelcues années de support est suffisant pour ça, non?
[^] # Re: Ça pourrait être utile à l'avenir…
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Liberté de communiquer - Où l'on reparle de Bitchat mesh, "messagerie sans Internet qui cartonne". Évalué à 5 (+2/-0).
Une fois qu'il est banni des app stores, perdu pour perdu, tu peux faire une version qui s'installe toute seule sur les téléphones à proximité en exploitant les failles de sécurité d'Android et iOS. Comme ça tu vas dans une manifestation et le réseau se déploie tout seul!
[^] # Re: a-t-on paniqué ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Il n'y a pas d'exploitation de la faille php, a-t-on paniqué pour rien?. Évalué à 6 (+3/-0).
Le gagnant a quand même publié le script utilisé et quelques explications:
https://github.com/KillaBoi/StealMyBitcoin-PoC
En résumé: la faille permet d'abord d'extraire l'adresse de base du code et du tas pour l'allocation mémoire (qui sont toutes les deux choisies aléatoirement au démarrage d'un worker PHP). à partir de ces deux valeurs et en connaissant exactement le binaire de PHP utilisé (en l'occurence, celui compilé par Alpine Linux), on peut arriver, en utilisant la faille une troisième fois, à injecter une structure de données qui sera appelée par la fonction cleanup de php. On peut à ce niveau exécuter le code révélant l'adresse du portefeuille bitcoin (mais en principe on pourrait exécuter n'importe quelle autre commande sur le serveur).
Il reste donc la contrainte que ce script ne s'applique qu'à une version compilée spécifique de PHP, mais il est adaptable à d'autres versions (il y a plusieurs valeurs codées en dur dans le script pour correspondre à ce build spécifique de PHP, mais ça peut être ajusté pour cibler un autre build et probablement pour essayer d'en reconnaître plusieurs différents).
L'attaque se déroule au total en une vingtaine de requêtes HTTP, et réussit environ 7 fois sur 10 (ça dépend entre autres du fait d'arriver à exécuter plusieurs requêtes sur le même worker, en fonction de la configuration et de la charge de la cible, cela peut être plus compliqué sur un site qui reçoit beaucoup plus de traffic).
On peut donc être "rassuré", la faille est bien exploitable et l'estimation de risque plutôt correcte.
[^] # Re: a-t-on paniqué ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Il n'y a pas d'exploitation de la faille php, a-t-on paniqué pour rien?. Évalué à 5 (+2/-0).
Il y a maintenant un défi avec
votre poids2000 dollars en bitcoin à la clé si vous êtes capables d'exploiter cette faille.Cela ne démontre pas que l'exploitation est impossible, mais, soit qu'elle coûte plus de 2000 dollars de token de LLM, soit que c'est suffisament compliqué pour être hors de portée du premier script kiddie venu, et qu'une attaque éventuelle reste entre les mains de gens qui préfèrent garder leurs attaques sous la main pour des cibles plus intéressantes
[^] # Re: a-t-on paniqué ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Il n'y a pas d'exploitation de la faille php, a-t-on paniqué pour rien?. Évalué à 8 (+5/-0). Dernière modification le 25 octobre 2026 à 10:14.
Un LLM est peut-être négessaire, mais pas suffisant.
L'article de Sansec qui prévoyait
la fin du mondeune exploitation massive dans les 15 minutes suivant la publication a été mis à jour avec un bandeau expliquant que finalement, l'attaque nécessite de très bien connaître l'intérieur du serveur cible, et que l'exploit publié ne fonctionne pas de façon aussi générule qu'annoncé. Les exploits publiés, soit ont besoin d'un fichier déjà vulnérable à une attaque par inclusion de fichier local, soit sont générées par un LLM qui injecte lui-même une telle vulnérabilité dans le système qu'on lui demande de tester.Recorded future (qui existe depuis 2012) annonce de nombreuses tentatives de scan et d'attaque, mais pas de chiffres disponibles sur le succès des attaquants.
Les vendeurs de solution de sécurité semble profiter un peu de la panique pour se faire de la publicité, avec un argument infaillible du genre "ce type d'attaque est irréalisable si votre serveur est équipé de notre solution" (sans préciser que c'est irréalisable aussi sur les serveurs non équipés de leur solution).
En attendant on est noyés sous les tentatives de proof of concept ne fonctionnant pas vraiment, dont certains prétendant exploiter une faille basée sur des rumeurs avant publication des détails et qui n'existe tout simplement pas. Malheureusement, la déconnexion avec la réalité rend difficile de trouver et de faire confiance à des vraies informations.
[^] # Re: a-t-on paniqué ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Il n'y a pas d'exploitation de la faille php, a-t-on paniqué pour rien?. Évalué à 5 (+2/-0). Dernière modification le 23 octobre 2026 à 16:16.
La réaction à l'annonce est la bonne, vu le score élevé et le risque d'exécution de code arbitraire. Mais il y a eu pas mal de site hors ligne pendant une demi journée.
La question est, est-ce que l'annonce elle-même n'était pas un peu exagérée? Est-ce que finalement la réaction de tout mettre hors ligne ne cause pas plas d'ennuis que la faille qui finalement n'est pas si simple à exploiter que ça?
Est-ce que si on commence à avoir des failles annoncées comme ça tous les jours, alors que inalement ce n'est pas exploitable, les gens vont arrêter de mettre leur site hors ligne à chaque fois?
[^] # Re: problème de base
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Unicode, NDJSON et bug subtil. Évalué à 6 (+3/-0).
Appeler "soleil ASCII" un caractère qui n'est ni un soleil, ni présent dans ASCII, et l'illustrer par un autre caractère soleil d'Unicode, c'est vraiment difficile à suivre, votre truc.
[^] # Re: Mouaif
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien le FOSDEM aime pas trop les gens pas normaux. Évalué à 5 (+3/-1).
Ben justement c'est ça la question.
Qu'il y aie pas de place pour tout le monde, effectivement, c'est un problème bien connu du FOSDEM (et la solution serait d'avoir plus de conférences à d'autres endroits).
Donc la justification "on ne peut pas accepter tout le monde parce que y'a pas la place" ben… ça justifie rien du tout. Si la justification était "on a fait un tirage au sort", au moins on sait que c'est équitable et non biaisé par les préférences personnelles des organisateurs. Ou si la justification est "on a fait un vote et ce sujet a perdu", on sait que ce sont les préférences personnelles des organisateurs qui pensent que d'autres sujets sont plus intéressants, c'est un process démocratique qui entretient les biais des votants. Ou encore si c'est "on en a marre de vos trucs de gauchistes woke, ici c'est une conférence sur la technologie neutre, on a donc choisi de privilégier les sujets techniques", au moins on sait à quoi s'en tenir. Ou alors si c'est "votre proposition était mal rédigée et ne nous a pas convaincus", ou "les thèmes proposés peuvent être abordés dans d'autres devrooms", OK, très bien.
Je pense que recevoir un refus sans explication à part "y'avait plus de place", ça donne un sentiment d'impuissance car on ne peut pas comprendre où est le problème et comment faire pour réessayer l'année suivante avec de meilleures chances de succès (ou se dire que c'est définitivement sans espoir et organiser une contre-conférence).
[^] # Re: Mouaif
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien le FOSDEM aime pas trop les gens pas normaux. Évalué à 7 (+4/-0).
Non pas cette année, l'appel à participation pour les stands est encore ouvert et j'ai pas encore envoyé la candidature (vous me direz, si on ne candidate pas, pas de risque d'être refusé). On verra le moment venu.
C'était l'an dernier et il a 3 ans que nous n'avons pas eu de stand.
Nous avons aussi été avec ReactOS les premiers projets à n'avoir droit qu'à un demi-stand, soit une journée chacun, soit la moitié de l'espace alloué à d'autres projets, après avoir auto-organisé ça les années où un seul des deux projets étaient acceptés.
Avant ça, vous avez peut-être connu mmu_man faisant homme sandwich pour présenter Haiku malgré l'absence de stand, puis ensuite le stand dans le bâtiment AW tout au fond de l'université, avec les projets d'électronique et de systèmes embarqués.
Pendant ce temps, en face on a une poignée de distributions Linux qui disent toutes être un clone de l'autre (y'a 3 ans c'était l'explosion de CentOS avec ses 3 ou 4 forks qui font tous exactement la même chose mais qui ont eu chacun un stand complet).
[^] # Re: Mouaif
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien le FOSDEM aime pas trop les gens pas normaux. Évalué à 7 (+4/-0).
Quand je râle et que je suis déçu parce que le FOSDEM n'accepte pas le stand de Haiku (ce qui arrive régulièrement), ou qu'il y a une devroom "kernel" qui ne prend même pas la peine de préciser qu'il s'agit uniquement de Linux et pas des autres noyaux, personne ne dit que j'utilise les "mécanismes d'outrages des forces réactionnaires".
Pourquoi le ressenti est différent quand il s'agit d'une devroom sur la diversité et l'inclusion? (sujet autrement plus important que Haiku, à mon avis).
[^] # Re: Pas normaux ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien le FOSDEM aime pas trop les gens pas normaux. Évalué à 9 (+6/-0).
Les devrooms sont les salles dans lesquelles il y a des conférences. Une fois la devroom acceptée, son (ou sa) responsable lance son propre "cfp" (call for participation) et monte lui/elle-même le programme en choisissant parmi les conférences proposées.
Les organisateurs du FOSDEM vont sans doute répondre qu'ils sont désolés, que la place est limitée et qu'ils ont préféré choisir d'autres sujets même si c'est toujours une décision difficile (ce qui est vrai).
Pourtant c'est un sujet pour lequel il y aurait plein de choses à dire et à faire, ce que soit pour l'accessibilité des logiciels, pour l'internationalisation, pour ce qu'on attend des développeurs (est-il nécessaire de pouvoir se payer un abonnement à un LLM à 3000$ par mois pour pouvoir contribuer par exemple?) ainsi que toutes les problématiques de harcèlement, sexisme, racisme, la mise en place de codes de conduite et leur application lorsque c'est nécessaire, et ainsi de suite.
[^] # Re: Prémonitoire :
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Une autorité de certificats tls a utilisé 4 comme clé privée, mettez à jour vos certificats. Évalué à 6 (+3/-0).
Ce n'est pas dans l'annonce publique (on ne va pas non plus donner aux attaquants les moyens de reproduire l'attaque) mais plusieurs personnes ont pu confirmer que l'une des clés priâées en question étaxt bien 4.
Il ne s'agit pas de cryptographie RSA (ou la clé est deux nombres premiers) mais de courbes elliptiques (où la clé peut être n'importe quelle valeur aléatoire de 256 bits).
Ce n'est pas encore tout à fait clair ce qu'il s'est passé pour que 8 certificats soient signés avec des clés dont les 248 bits oe poids fort sont tous à 0. Les valeurs des 8 clés (et des liens vers plus oe détails) par exemple sur ce fil fediverse.
[^] # Re: ASCII’s not dead ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Unicode, NDJSON et bug subtil. Évalué à 6 (+3/-0).
La réponse est dans la question:
Ces caractères de contrôle sont donc interdits dans les chaînes de caractères en JSON.
Pour citer précisément la spécification:
De façon surprenante, le codepoint U+007F, lui, est autorisé sans échappement. En ASCII et en Unicode il s'agit de DELETE qui est un caractère de contrôle. Les tabulations et retours à la ligne (dans leur forme ASCII) sont, eux, interdits.
Ce sont bien les noms choisis par Unicode. Ils sont différents des noms qui étaient utilisés dans la spécification ASCII, même si ce sont les mêmes caractères.
[^] # Re: C'est du vol
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Anthropic écrit son propre système de gestion de code. Évalué à 5 (+2/-0).
J'ai lié un premier article, mais il y a au début un lien vers la suite:
https://sunshowers.io/posts/anthropic-mononoke-2/
Cette fois ci il est question de "ripping off", avec des exemples de paragraphes identiques.
Donc Anthropic a embauché des gens qui avaient travaillé auparavant sur Mononoke, et leur on demandé de développer un nouveau système qui est en fait assez identique et sans citer son inspiration. Puis fait passer cela pour nouveau et révolutionnaire.
Suite à ces deux messages de blog, Anthropic a tout de même fini par mettre à jour son article (c'est indiqué au début des deux: l'article d'Anthropic et le deuxième blog ci-dessus).
[^] # Re: C'est du vol
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Anthropic écrit son propre système de gestion de code. Évalué à 9 (+6/-0).
Dans le cas qui nous concerne ici, c'est du plagiat, aved des paragraphes recopiés tels quels et sans attribution. C'est illégal et irrespectueux du travail original. Que ça soit fait par un humain ou un LLM ne change rien au problème.
La grosse nouvelle précédente était sur un clone de photoshop qui, s'il n'y a pas plagiat, pourrait au moins être qualifié de parasitisme.
Pourquoi c'est à chaque fois comme ça? Pourquoi personne ne parle des projets innovants et révolutionnaires qui vont là ou aucun humain n'est jamais allé? Logiquement il devrait y en avoir plein?
[^] # Re: Calcul économique ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Prix multipliés par 30, clients captifs : la fronde s'organise contre l'éditeur PC Soft. Évalué à 3 (+0/-0).
Il y a plein de choses qui peuvent être faites avec un ordinateur sans avoir besoin d'un analyste programmeur professionnel.
Ça va de la simhle utilisation de traitement de texte à du développement python. Quelque part entre les deux il y a Excel et les tableurs, qu'on peut agrémenter de macros, les bases de données access ou similaire, et il y a aussi des solutions comme windev.
De ce point de vue là ça ne me semble pas délirant, et c'est même assez cohérent avec ma vision du logiciel libre (partager mes connaissances et le résultat de mon travail au plus grand nombre et donner à chacun la possibilité de s'en emparer).
Là où ça diverge, c'est dans le choix d'une techno fermée avec une license restrictive et qui peut changer. Pour autant, je ne pense pas qu'il faut se moquer ou dévaloriser ces utilisations d'outils informatiques. Pas besoin de faire de l'élitisme.
# C'est du vol
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Anthropic écrit son propre système de gestion de code. Évalué à 10 (+13/-0).
En fait leur "propre" système est (au moins en partie) un plagiat de celui développé depuis une dizaine d'années chez Meta. Comme d'habitude, les LLM n'inventent rien et piochent dans leurs données d'entraînement ou ailleurs.
[^] # Re: Ah si si c'est un problème
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Linus Torvalds a utilisé Claude pour une modification sur le noyau Linux… et ce n'est pas un problème. Évalué à 6 (+3/-0).
historiquement Linux était hébergé sur bitkeeper, un système de gestion de versions très propriétaire. Le projet avait un accès gratuit tant qu'il ne tentait pas de développer un client libre, ce qu'un autre développeur a tout de même commencé à faire.
Les relations se sont gâtées et Linus a fini par démarrer le développement de Git pour remplacer bitkeeper.
Sans toute cette histoire, Github n'existerait pas. Peut-être que tous les projets seraient toujours chez Sourceforge ou chez Google Code Project Hosting.
[^] # Re: inatteignables
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal C'est historique, le développement logiciel est entièrement automatisable. Évalué à 10 (+11/-0).
si ça repousse assez loin pour que ça tombe sur la génération suivante, c'est plus du suicide mais du meurtre.
Mais je crois qu'on est bien partis pour le suicide.
[^] # Re: APL
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Kateryna Iouchtchenko, fondatrice de la programmation théorique en Ukraine. Évalué à 6 (+3/-0).
Puisqu'on parle d'APL (l'autre, l'américain) et d'Unicode, on peut signaler la particularité de ce langage d'avoir obstinément refusé de se conformer aux limitations de l'ASCII, et de se fait, d'avoir un ensemble de caractères Unicode définis rien que pour son usage, de 2336 jusqu'à 237A dans la catégorie "Miscellaneous Technical Symbols", juste avant RIGHT ANGLE WITH DOWNWARDS ZIGZAG ARROW, Angzarr de son petit nom, le symbole dont personne ne se souvient pourquoi il a été ajouté dans Unicode.
[^] # Re: ça peut étre utile
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Vers la fin du logiciel propriétaire?. Évalué à 7 (+4/-0).
Même facilité pa un LLM, le reverse engineering ou la réimplémentation d'un logiciel demande du temps et des compétences. C'est pas un truc où on clique sur un bouton et pouf, on a un logiciel qui fait tout comme on veut.
Peut-être que, oui, patcher un logiciel existant (même sans les sources) est moins cher que d'en réécrire un, et c'est sûrement plus facile de le faire avec l'aide d'un LLM si on a pas l'habitude de manipuler un désassembleur (compétence relativement rare).
Le problème, c'est que patcher un logiciel existant sans l'accord de l'auteur, c'est illégal.
J'ai travaillé dans une entreprise qui était de l'autre côté de ce problème: impossible de vendre notre solution à des gens qui n'avait pas confiance dans la perrenité de l'entreprise (bien que convaincus sur le plan technique). La solution était un dépôt régulier des sources à l'agence pour la protection des programmes, avec une garantie que nos clients pourraient en récupérer une copie en cas de faillite (ça s'appelle apparament en français un entiercement.
Si vous êtes inquiets de la santé de vos fournisseurs, faites ça plutôt que de compter sur un LLM pour rattraper votre insouciance?
[^] # Re: Redox et haiku
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien NetBSD s'est peut-être trouvé un nouveau rôle : l'OS libre sans IA. Évalué à 10 (+8/-1).
Bonjour, dans Haiku les contributions contenant du code généré par IA sont interdites en raison de risques au niveau du copyright. On est particulièrement inquiet sur ce sujet car les LLM ont été entraînés par exemple sur le code de linux qui est sous GPL, et si on demande d'écrire un driver pour du matériel spécifique, il y a d'assez fortes chances que le code ressemble beaucoup à celui de Linux.
Par ailleurs nous avons tout plein d'autres raisons de détester et de vouloir interdire l'utilisation de LLM une fois que ce problème aura une réponse.
Les contributions où les gens demandent de l'aide à un LLM mais rédigent le code eux-même sont autorisées, mais mal vues, surtout si cela a causé une déconnexion avec la réalité (c'est malheureusement le cas de plusieurs de nos utilisateurs, ça l'était déjà avant l'arrivée des LLM mais le phénomène est renforcé). C'est difficile d'être plus restrictif que ça là dessus, car on ne peut pas vraiment savoir ce que les gens ont fait et aussi parce que l'argument du copyright ne s'applique pas. Pour l'instant un rejet pour des raisons perçues comme politiques par une partie de la communauté n'est pas envisageable. Personellement je prévois de continuer à me battre pour que le projet se politise un peu plus.
Au niveau de Haikuports, on rejette les paquets de logiciels vibe codés, mais on ne va pas faire la chasse à la moindre contribution assistée par LLM dans chaque logiciel. Les recettes doivent être écrites et envoyées par des humains (sinon nous étions exposés à une avalanche de trucs faits par des robots).
S'agit-il d'une politique laxiste? Que faudrait-il faire de plus?
Nous avons également un gros travail à faire pour mettre à jour notre documentation afin de faciliter les contributions par des humains, afin de rester constructifs et de ne pas juste se lamenter sur la fin du monde.