Vous savez ce moment où vous regardez votre historique Git et vous vous demandez qui est le débile qui a écrit ce code dégueulasse ?

Ah bah ouais, c’était vous il y a 3 mois ^^. Eh bien GitType a trouvé la meilleure des thérapies qui est de vous faire retaper tout ça, lettre par lettre, comme une punition de primaire version développeur, totalement gamifiée avec des points, un chrono, et la possibilité de mesurer à quel point vos doigts sont devenus flasques depuis que Copilot fait tout le boulot à votre place.

Le tagline du projet, c’est “Show your AI who’s boss: just you, your keyboard, and your coding sins”. Et c’est pas une blague, c’est un manifeste car pendant que Copilot, ChatGPT, Claude Code et compagnie écrivent du code à notre place, GitType vous fait faire exactement l’inverse… il vous force à retaper du code pour redevenir bon !

Et contrairement aux tests de frappes classiques comme Ttyper ou tt qui vous font taper du texte générique, GitType utilise du VRAI code source. Votre code, celui de vos repos préférés, ou des repos trending de GitHub. Comme ça, vous ne vous entraînez pas sur du “ the quick brown fox jumps over the lazy dog ” à la con, mais sur vos propres merdes spaghettico-syntaxiques en Rust, TypeScript, Python ou Go.

Le jeu vous propose plusieurs modes. Y’a le mode Normal pour vous échauffer tranquillement, le Time Attack quand vous voulez vous mettre la pression, et des niveaux de difficulté de Easy à Zen pour ceux qui veulent méditer en tapant du code. Le tout avec un tracking en temps réel de votre WPM (words per minute) et de votre précision. Comme ça, plus vous progressez, plus vous montez dans le ranking avec des titres de développeur qui évoluent.

GitType supporte plus de 15 langages de programmation et propose plus de 15 thèmes visuels en mode Dark ou Light, avec possibilité de personnaliser le vôtre. L’installation est simple…

curl -sSL https://raw.githubusercontent.com/unhappychoice/gittype/main/install.sh | bash

Vous saviez qu’en ce moment, les attaques sur la supply chain faisaient des ravages ? En effet, les attaquants exploitent régulièrement la possibilité de modifier des tags existants pour injecter du code malveillant dans les pipelines CI/CD.

Mais heureusement, GitHub a enfin sorti LA fonctionnalité qui peut empêcher ce carnage : les Immutable Releases et je pense que c’est le genre de truc que tous les développeurs devraient activer illico sur leurs repos. Je vais vous expliquer pourquoi.

En fait, une fois que vous publiez une release avec cette option activée, plus personne ne peut toucher ni aux assets ni au tag associé. C’est comme si vous mettiez votre release dans un coffre-fort dont vous jetez la clé. Même vous, en tant que mainteneur, vous ne pouvez plus modifier les binaires ou déplacer le tag vers un autre commit.

D’après la documentation officielle , chaque release immuable génère automatiquement une attestation cryptographique. Cette attestation contient le SHA du commit, le tag et la liste des assets. Vos utilisateurs peuvent vérifier l’intégrité de ce qu’ils téléchargent en s’assurant que cela correspond exactement à ce que vous avez publié.

Pour activer cette option merveilleuse, c’est dans les settings de votre repo ou de votre organisation. Une fois activé, toutes les nouvelles releases deviennent alors automatiquement immuables. Les anciennes releases restent toutefois modifiables (pour éviter de casser vos workflows existants), mais bon, c’est mieux de migrer progressivement.

Attention quand même, il y a quelques pièges à éviter. Premièrement, vous ne pouvez plus ajouter d’assets après publication. Donc si votre CI upload les binaires après avoir créé la release, il faut inverser : Créez d’abord une draft release, uploadez les assets, puis publiez. Deuxièmement, si vous supprimez une release immuable, vous ne pourrez JAMAIS réutiliser le même tag. C’est définitif.

Pour les projets qui utilisent des tags de version majeure style v1 qu’ils mettent à jour régulièrement (coucou GitHub Actions), pas de panique. Vous pouvez continuer à utiliser cette pratique pour les tags qui ne sont pas associés à des releases. L’immuabilité ne s’applique qu’aux releases publiées, pas aux tags simples.

Les équipes de sécurité recommandent d’ailleurs d’activer cette fonctionnalité sur tous les repos qui publient du code versionné. C’est particulièrement critique pour les bibliothèques open source, les GitHub Actions, et tout ce qui est consommé par d’autres projets. En gros, si votre code finit dans la supply chain de quelqu’un d’autre, vous leur devez cette protection.

Le truc cool aussi, c’est que ça protège contre les erreurs humaines. Combien de fois j’ai vu des mainteneurs qui écrasaient accidentellement une release avec la mauvaise version ? Ou qui supprimaient un asset critique par erreur ? Avec les Immutable Releases, ces accidents appartiennent au passé.

Pour les entreprises, c’est un argument de vente en or. Ça permet de garantir à vos clients que vos releases ne peuvent pas être altérées après publication, c’est un niveau de confiance supplémentaire surtout dans des secteurs régulés où la traçabilité est cruciale.

Bref, GitHub est en train de déployer progressivement cette fonctionnalité en public preview. Pour l’instant, il faut l’activer manuellement pour chaque repo, mais ils travaillent sur une API pour permettre l’activation en masse. D’ici là, prenez donc 2 minutes pour l’activer sur vos projets critiques.

Voilà, après les dégâts causés par les attaques de type tag hijacking ces dernières années, ne pas activer les Immutable Releases sur vos repos publics, c’est comme laisser votre porte d’entrée grande ouverte avant de partir en vacances. Vous pouvez le faire, mais ne venez pas pleurer si ça tourne mal.