Avec Ex.skill, un projet open source publié sur GitHub, l’IA s’invite désormais jusque dans les ruptures amoureuses. À partir de messages, photos et souvenirs, l’outil propose de recréer une version artificielle de son ex pour continuer à discuter avec elle après la séparation.

Avec Ex.skill, un projet open source publié sur GitHub, l’IA s’invite désormais jusque dans les ruptures amoureuses. À partir de messages, photos et souvenirs, l’outil propose de recréer une version artificielle de son ex pour continuer à discuter avec elle après la séparation.

Un développeur connu sous le pseudonyme krauseler a glissé un ordinateur complet, écran e-paper et NFC compris, dans une carte de 1 mm d'épaisseur. Le projet, baptisé Muxcard, n'est pas commercial, mais il esquisse à quoi pourrait ressembler l'informatique discrète des prochaines années.

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 "[email protected]"

# 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 "[email protected]"

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

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 <[email protected]> à 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"

Des chercheurs en sécurité de Wiz ont découvert une vulnérabilité critique dans l'infrastructure interne de GitHub, permettant à n'importe quel utilisateur authentifié d'exécuter du code arbitraire sur les serveurs de la plateforme, le tout avec une seule commande git.

Des chercheurs en sécurité de Wiz ont découvert une vulnérabilité critique dans l'infrastructure interne de GitHub, permettant à n'importe quel utilisateur authentifié d'exécuter du code arbitraire sur les serveurs de la plateforme, le tout avec une seule commande git.

"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

Une simple commande git push pour compromettre un serveur ? C'est possible grâce à la faille CVE-2026-3854 qui affecte GitHub.com et GitHub Enterprise Server.

Le post Cette faille GitHub est exploitable par un simple Git Push (CVE-2026-3854) a été publié sur IT-Connect.

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'éteint 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 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 !

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>.

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

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

Dans un article de blog publié le 1er avril 2026, les chercheurs de Zscaler ThreatLabz ont mis en lumière une campagne cybercriminelle opportuniste : des acteurs malveillants ont exploité la récente fuite du code source de Claude Code pour piéger des développeurs et leur faire télécharger des infostealers.

Des milliers de faux messages imitant des notifications de sécurité Visual Studio Code ont été postés sur GitHub. Le but : rediriger les développeurs vers un site malveillant qui collecte leurs données système. La méthode est franchement vicieuse.

Une campagne massive sur GitHub Discussions

Les chercheurs en sécurité de Socket viennent de mettre le doigt sur une opération d'ampleur. Des centaines, voire des milliers de messages quasi identiques ont été publiés en quelques minutes sur la section Discussions de nombreux dépôts GitHub.

Chaque message reprend le même modèle : un titre alarmiste du type "Vulnérabilité grave Mise à jour immédiate requise", un faux identifiant CVE pour faire sérieux, et un lien vers une prétendue extension VS Code corrigée hébergée sur Google Drive.

Les comptes utilisés sont soit tout neufs, soit quasi inactifs, mais ils se font passer pour des mainteneurs de projets ou des chercheurs en sécurité. Et comme GitHub envoie des notifications par e-mail aux personnes qui suivent un dépôt ou qui sont taguées, les fausses alertes arrivent directement dans la boîte mail des développeurs. Vous pouvez donc vous faire avoir sans même ouvrir GitHub.

Un système de filtrage avant le malware

Bien sûr, le lien Google Drive ne vous amène pas d'un coup vers un fichier infecté. Il déclenche avant une série de redirections qui vous emmènent inlassablement vers un domaine bien foireux, où un script JavaScript va se charger du sale boulot.

Ce script collecte automatiquement le fuseau horaire, la langue, le système d'exploitation, l'identifiant du navigateur et même des indicateurs d'automatisation. Tout est envoyé vers un serveur de commande sans que vous n'ayez à cliquer sur quoi que ce soit.

L'idée derrière ce dispositif, c'est de trier les visiteurs. Les robots et les chercheurs en sécurité sont écartés, et seuls les vrais humains reçoivent la suite de l'attaque. Les chercheurs de Socket n'ont d'ailleurs pas réussi à capturer le malware de deuxième étape, ce qui montre que le filtrage fonctionne plutôt bien.

Ce n'est pas la première fois

GitHub a déjà été ciblé par ce genre de campagne. En mars 2025, une attaque similaire avait touché 12 000 dépôts avec de fausses alertes de sécurité qui poussaient les développeurs à autoriser une application OAuth malveillante.

Cette fois-là, les pirates obtenaient un accès direct aux comptes GitHub des victimes. En juin 2024, c'était via des commentaires et des demandes de fusion bidon que les attaquants redirigeaient vers des pages d'hameçonnage.

Le procédé est malin. Utiliser les notifications GitHub pour donner une apparence officielle à des messages bidons, c'est le genre d'astuce qui marche bien sur des développeurs pressés. 

Bon par contre, un lien Google Drive dans une alerte de sécurité, ça devrait quand même mettre la puce à l'oreille. Si vous recevez ce type de message, vérifiez toujours le CVE sur le site du NVD ou de MITRE avant de cliquer où que ce soit. Et si le lien pointe ailleurs que sur la boutique officielle de VS Code, passez votre chemin.

Source : Bleeping Computer

GitHub change son fusil d'épaule. Après avoir laissé planer un temps l’idée que les données de ses utilisateurs serviraient avant tout à améliorer Copilot sans forcément être réinjectées dans les modèles d’IA, la plateforme annonce désormais qu’elles seront bel et bien utilisées pour entraîner ses IA, à certaines conditions.

À partir du 24 avril, GitHub activera par défaut la collecte des données d'interaction Copilot pour les utilisateurs Free, Pro et Pro+. Le gros sujet ici, c'est que le code, les suggestions acceptées et même la structure de vos dépôts pourront servir à améliorer les modèles d'IA de la plateforme.

Ce qui change à partir du 24 avril

GitHub vient d'annoncer une mise à jour de sa politique de confidentialité qui concerne directement Copilot. À compter du 24 avril 2026, la plateforme collectera par défaut les données d'interaction de ses utilisateurs pour entraîner ses modèles d'intelligence artificielle.

On parle ici des suggestions de code acceptées ou modifiées, des extraits de code envoyés au modèle, du contexte autour du curseur, des commentaires, de la documentation, des noms de fichiers, de la structure des dépôts, et même des retours comme les pouces en l'air ou en bas sur les suggestions.

Mario Rodriguez, le directeur produit de GitHub, assure que cette collecte permettra aux modèles de mieux comprendre les méthodes de développement et de proposer des suggestions de code plus précises et sécurisées.

Qui est concerné

Tous les abonnés Copilot Free, Pro et Pro+ sont concernés par ce changement. Et c'est automatique, pas besoin de cocher quoi que ce soit. Par contre, les comptes Copilot Business et Enterprise échappent à cette collecte, tout comme les étudiants et enseignants qui bénéficient de Copilot Pro gratuitement.

GitHub précise aussi que les utilisateurs qui avaient déjà désactivé le partage de données pour l'amélioration du produit conserveront leur réglage. Pour les autres, c'est l'opt-out qui s'applique, c'est-à-dire que c'est activé par défaut et c'est à vous de faire la démarche pour refuser.

Comment désactiver la collecte

Pour ceux qui ne souhaitent pas que leur code serve à nourrir les modèles de GitHub, la manipulation est assez simple. Il faut se rendre dans les paramètres du compte, section Copilot, puis dans les options de confidentialité.

L'option à désactiver s'appelle "Allow GitHub to use my data for AI model training". GitHub insiste sur le fait que le contenu des dépôts privés n'est pas collecté "au repos", mais attention, si vous utilisez Copilot activement avec le partage activé, vos interactions dans un dépôt privé sont bien concernées.

La tendance est lourde : après Anthropic, JetBrains et Microsoft lui-même, GitHub suit le mouvement et pioche dans les données de ses utilisateurs pour alimenter ses modèles.

Le choix de l'opt-out plutôt que de l'opt-in est quand même un classique américain qui passe toujours un peu mal de ce côté de l'Atlantique. D'ailleurs, sur la page de discussion GitHub, les réactions parlent d'elles-mêmes : 59 pouces vers le bas contre 3 petites fusées.

Difficile de faire plus clair comme signal. Bon par contre, au moins les comptes pro entreprise et les étudiants sont protégés, c'est déjà ça. Reste que pour tous les développeurs indépendants et les contributeurs open source en offre gratuite, c'est un peu l'histoire du produit gratuit dont on finit par être la matière première. Allez, un petit tour dans les paramètres et on n'en parle plus.

Source : Ghacks.net

GitHub vient d'annoncer que les interactions avec l'IA Copilot seront utilisées pour entraîner les modèles IA. Voici comment désactiver la collecte de données.

Le post GitHub va activer par défaut la collecte de données Copilot pour entraîner l’IA a été publié sur IT-Connect.

Dans un article de blog publié le 24 mars 2026, les chercheurs de l'entreprise de cybersécurité Snyk reviennent sur le déroulé d'une attaque menée contre la bibliothèque Python LiteLLM. Le projet, utilisé par des millions de développeurs, a été compromis pendant trois heures. Derrière l'attaque, un groupe nommé TeamPCP qui avait préparé son coup cinq jours à l'avance.