Source

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

Source

Source

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"