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 !

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"

"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