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.

Créer un système d’exploitation complet from scratch pour s’amuser, c’est le genre de projet un peu foufou qu’on ne voit plus tellement aujourd’hui. Pourtant SkiftOS existe !

SkiftOS c’est un OS écrit entièrement depuis zéro, et pas un n-ième fork de Linux ou d’une distribution BSD. Non, c’est un vrai OS avec son propre kernel, son interface graphique et même les bases d’un moteur de navigateur web.

J’ai découvert ce projet en me baladant sur les Top GitHub et ça m’a rappelé cette époque d’avant ma naissance où créer son OS était un genre de rite de passage pour tous les développeurs passionnés. Sauf qu’ici, on n’est plus dans les années 70 et le projet utilise du C++20 moderne avec une architecture microkernel très propre.

Et malgré son statut de projet “hobby”, il fonctionne réellement. Il tourne pour le moment sur du hardware x86_64 et l’équipe travaille sur le support RISC-V.

L’architecture modulaire du projet est d’ailleurs particulièrement bien pensée. Chaque module a son petit nom, c’est rigolo. Hjert gère le microkernel avec les fonctions essentielles telles que la gestion mémoire, l’ordonnancement et l’IPC (Inter-Process Communication). Karm fournit la bibliothèque C++ de base sans dépendre de la STL (Standard Template Library) . KarmUI propose un framework d’interface réactive. Hideo s’occupe du bureau et de l’environnement graphique. Et Vaev ambitionne de devenir un moteur de navigateur web complet.

Pour compiler tout ça, l’équipe a également développé CuteKit, leur propre système de build qui gère les dépendances et la cross-compilation. Bah oui, quand on réinvente un OS, autant réinventer aussi tous les outils pour le construire.

Cette approche “tout fait maison” rend en tout cas le projet fascinant d’un point de vue pédagogique. Car oui le code source est disponible sur GitHub donc si vous voulez comprendre comment fonctionne un OS moderne sans vous perdre dans les millions de lignes de code de Linux ou de Windows (pour les vieilles versions qui ont leakée), c’est une excellente opportunité pour apprendre. Pas besoin donc d’être Microsoft ou Apple pour développer un système d’exploitation fonctionnel.

Faut “juste” de la motivation, du temps, des compétences en C++ moderne, et surtout l’envie de construire quelque chose de différent.

Vous l’aurez compris, SkiftOS ne remplacera probablement jamais votre OS principal, c’est clair mais pour les développeurs curieux qui veulent comprendre les entrailles d’un système d’exploitation, ou pour ceux qui cherchent un projet open source technique sympa où contribuer, c’est une sacrée mine d’or.

Et qui sait, peut-être que dans quelques années on parlera de SkiftOS comme on parle aujourd’hui des débuts de Linux…

Depuis que j’ai découvert OSGameClones, je kiffe chercher et retrouver certains de mes jeux d’enfance en version open source et bien sûr gratuite !

Car oui, le projet OSGameClones c’est un peu la caverne d’Ali Baba pour tous ceux qui ont grandi avec une manette dans les mains (ou un clavier pour ma part). Le site répertorie méticuleusement tous les remakes, clones et réimplémentations open source de jeux commerciaux, et le meilleur c’est que la plupart sont jouables sur des machines modernes, y compris Linux et même votre Steam Deck.

Vous y retrouvez donc des pépites comme OpenRCT2 pour RollerCoaster Tycoon 2, qui non seulement fait tourner le jeu original mais ajoute le support des hautes résolutions et du multijoueur. Ou encore OpenMW qui réimplémente complètement le moteur de Morrowind avec des graphismes améliorés. Sans oublier CorsixTH pour Theme Hospital, qui fonctionne maintenant sur n’importe quel OS moderne.

Le projet est hébergé sur GitHub , et est activement maintenu. Tout est organisé dans des fichiers YAML structurés qui catégorisent les jeux par langages de programmation (50+ langages différents !), genres (30+ catégories), et même par thèmes comme fantasy ou sci-fi.

Ce qui est vraiment cool je trouve, c’est surtout la distinction que fait le site entre les différents types de projets. Un “remake” c’est quand l’exécutable et parfois les assets sont recréés en open source. Un “clone” c’est un jeu très similaire ou inspiré par l’original. Et parfois on trouve même des “projets officiels” où les créateurs originaux ont libéré le code source eux-mêmes.

D’ailleurs, pour les fans de jeux de stratégie, vous avez OpenXcom qui réimplémente UFO: Enemy Unknown et X-COM: Terror From the Deep. Pour les amateurs d’action, DevilutionX fait revivre Diablo sur pratiquement n’importe quelle plateforme. Et si vous êtes plutôt RPG, Daggerfall Unity a recréé tout Daggerfall dans le moteur Unity avec des mods et des améliorations graphiques de malade.

Tous ces projets sont utiles pour les joueurs ayant des machines peu puissantes ou pour ceux qui veulent faire tourner leurs classiques préférés sous Linux. C’est aussi top pour la préservation du patrimoine JV, vu que beaucoup de ces vieux jeux ne fonctionnent de toute façon plus sur les systèmes modernes.

Un autre aspect sympa, c’est que comme tout est open source, n’importe qui peut contribuer à améliorer ces jeux. Vous pouvez donc corriger des bugs qui existaient dans l’original, ajouter de nouvelles fonctionnalités, ou même porter le jeu sur de nouvelles plateformes.

Et pour ceux qui veulent explorer d’autres ressources similaires, il existe aussi Awesome Game Remakes sur GitHub, qui est une liste maintenue activement de remakes open source ainsi que cette page de SensCritique qui recense des remakes open source vraiment chouettes, même si la plupart nécessitent les données du jeu original pour fonctionner.

Puis quand on voit des projets comme Julius pour Caesar III, fheroes2 pour Heroes of Might and Magic II, ou OpenTTD pour Transport Tycoon Deluxe, je le dit que la communauté open source fait un boulot incroyable pour préserver et améliorer ces classiques. Ces développeurs permettent à toute une génération de redécouvrir ces jeux mythiques sans avoir à galérer avec DOSBox ou des émulateurs.

Le plus impressionnant reste peut-être re3 et ses dérivés qui ont reverse-engineered GTA III et Vice City, même si Rockstar n’a pas vraiment apprécié l’initiative et l’a fait disparaitre. Ou OpenJK qui maintient et améliore Jedi Academy et Jedi Outcast pour la communauté Star Wars.

Voilà et si vous cherchez par où commencer, le site propose des tags “complete” et “playable” pour identifier rapidement les projets les plus aboutis. Vous pouvez aussi filtrer par langage de programmation si vous voulez contribuer à un projet dans votre langage de prédilection.

Bref, OSGameClones c’est la ressource ultime pour tous les nostalgiques du gaming qui veulent revivre leurs souvenirs d’enfance tout en profitant des bénéfices du monde de l’open source !

Saviez-vous qu’il y a plus de 3,7 millions de fausses étoiles qui polluent GitHub , et que 16% des repos étaient déjà touchés fin 2024. C’est pour cela que DataDog a sorti GHBuster , un outil qui détecte justement les comptes et repos GitHub suspects grâce à des algos heuristiques bien senties.

Le principe c’est qu’au lieu de chercher bêtement des patterns, GHBuster analyse plusieurs comportements louches en même temps. Genre, il repère quand un repo a plein d’étoiles venant de comptes créés le même jour et check aussi d’autres trucs sympas comme les commits avec des emails non liés au profil GitHub (pratique pour repérer les acteurs malveillants qui utilisent plusieurs comptes bidons). Il trouve aussi les utilisateurs qui n’ont que des forks de repos supprimés, ou ceux dont tous les commits viennent d’emails non vérifiés.

L’installation est super simple pour ceux qui veulent tester :

uv pip install "git+https://github.com/DataDog/ghbuster.git"
export GITHUB_TOKEN=votre_token_github
ghbuster

Vous avez déjà vu ces README GitHub avec du texte qui s’écrit tout seul comme si quelqu’un tapait en temps réel ? Hé bien voilà ce qu’il vous faut pour faire pareil sur votre propre site. Ça s’appelle TypingSVG , ça a été créé par un certain whiteSHADOW1234 et c’est donc un générateur d’animations SVG qui transforme n’importe quel texte en animation de frappe dynamique. Et surtout c’est complètement gratuit et ça tourne directement dans votre navigateur.

Le truc sympa avec TypingSVG, c’est qu’il ne se contente pas de faire défiler bêtement du texte. Non non, c’est un vrai système complet avec support multi-lignes, gestion des emojis 😎🚀, et même la possibilité de personnaliser la vitesse de suppression du texte. Parce que oui, l’outil simule aussi l’effacement, comme si quelqu’un revenait en arrière pour corriger une faute de frappe…

L’interface web est dispo sur typingsvg.vercel.app . Vous tapez votre texte, vous réglez quelques paramètres (police, taille, couleur, vitesse d’animation), et hop, vous avez un aperçu en temps réel de votre animation. Pas besoin d’installer quoi que ce soit, pas de compte à créer, juste vous et votre créativité.

Pour les dev, c’est du pain béni car vous pouvez intégrer ces animations directement dans vos README GitHub, vos portfolios, ou même vos sites web. Le générateur vous donne ainsi plusieurs formats d’export : une URL directe, du Markdown pour GitHub, ou du HTML pur pour vos pages web. Et comme c’est du SVG, ça reste léger et ça scale parfaitement sur tous les écrans.

Au niveau de la personnalisation, vous avez le choix entre plusieurs styles de curseur (droit, souligné, bloc, ou même invisible si vous préférez). La police Monaco par défaut donne un côté terminal très classe, mais vous pouvez changer pour n’importe quelle police web. L’espacement des lettres est ajustable, vous pouvez centrer le texte horizontalement et verticalement, et même ajouter une bordure autour de votre SVG si l’envie vous prend.

Le code derrière tout ça, c’est du Next.js avec TypeScript et Tailwind CSS ce qui fait que c’est moderne et maintenable et whiteSHADOW1234 a fait un sacré boulot pour que l’API soit simple à utiliser. Un simple appel à /api/svg avec les bons paramètres et vous récupérez votre animation. Par exemple, pour un “Hello, World!” qui clignote, il suffit d’ajouter ?text=Hello,+World! à l’URL.

Et pour ceux qui veulent aller plus loin, vous pouvez même déployer votre propre instance sur Vercel. Un bouton “Deploy to Vercel” est disponible sur le repo GitHub, et en quelques clics vous avez votre propre générateur personnel. Pratique si vous voulez des fonctionnalités custom ou si vous préférez garder le contrôle total sur vos animations.

Bref, pas de fioritures inutiles mais juste ce qu’il faut pour créer des animations de texte qui claquent, que ce soit pour pimper votre profil GitHub, ajouter un peu de dynamisme à votre site, ou juste pour le fun !

Vous savez ce qui m’a toujours ennuyé avec git blame ? C’est qu’à chaque refactoring, chaque reformatage de code, chaque déplacement de fichier, tous les noms disparaissent pour être remplacés par celui de la personne qui a fait ces modifications. Du coup, impossible de savoir qui a vraiment écrit le code original. Heureusement, un développeur nommé Sinclair Target vient de sortir un outil qui résout ce problème.

git-who (c’est son nom) fait donc exactement ce que git blame aurait dû faire depuis le début à savoir analyser qui a vraiment contribué à votre codebase, et pas juste qui a touché les lignes en dernier. Au lieu de se contenter d’une analyse ligne par ligne comme git blame, git-who analyse les patterns de contribution sur des fichiers entiers, des dossiers, voire des composants complets.

L’installation est simple comme bonjour. Si vous êtes sur Mac avec Homebrew, un petit brew install git-who et c’est réglé. Pour les autres, vous pouvez passer par Go avec go install github.com/sinclairtarget/git-who@latest ou compiler depuis les sources si vous aimez les défis. Docker est aussi supporté pour ceux qui préfèrent…

Ce qui rend git-who vraiment intéressant, c’est ses trois modes d’analyse. Le mode table (par défaut) vous donne un tableau récapitulatif des contributions par auteur, triable par nombre de commits, lignes de code, fichiers touchés ou date de modification. C’est pratique pour identifier rapidement qui sont les principaux contributeurs d’un projet. Le mode tree affiche l’arborescence du projet avec le contributeur principal annoté pour chaque fichier et dossier. Et le mode hist génère une timeline de l’activité des commits avec le top contributeur par période.

Pour vous donner une idée concrète, Sinclair Target a fait une démo sur le projet Vim pour analyser les patterns de maintenance après le décès de Bram Moolenaar. L’outil a permis d’identifier rapidement qui avait pris le relais sur différentes parties du code. C’est quelque chose qu’il aurait été impossible à voir clairement avec un git blame classique.

La différence fondamentale donc avec git blame, c’est que git-who “comprend” le contexte. Si quelqu’un déplace un fichier ou fait un reformatage massif, git blame lui attribuera toutes les lignes alors git-who, lui, va chercher plus loin dans l’historique pour identifier les véritables auteurs du code. Il respecte même les fichiers .mailmap pour consolider les identités multiples d’un même développeur et prend en compte le fichier .git-blame-ignore-revs pour ignorer certains commits de maintenance.

Pour utiliser git-who, il suffit de faire un git who à la racine de votre projet afin d’obtenir l’analyse de base. Vous pouvez filtrer par chemin avec git who Parser/ pour analyser seulement un dossier spécifique. Le tri est customisable avec des options comme -l pour trier par lignes de code ou -m pour la date de dernière modification. Et pour une vue historique entre deux versions, git who hist v3.10.9..v3.11.9 fait le job.

Bien sûr, git-who n’est pas le seul dans sa catégorie. GitLens pour VS Code reste l’extension la plus populaire, offrant une intégration visuelle directement dans l’éditeur. Git Quick Stats est aussi une autre alternative en ligne de commande qui propose des statistiques détaillées sur les repositories. Mais aucun ne va aussi loin que git-who dans l’analyse de la véritable propriété du code.

Qui maintient réellement cette partie critique du code ? Quelle équipe a le plus contribué à ce module ? Comment les contributions ont évolué au fil du temps ? Git-who vous aide à répondre à ces questions essentielles sur la gestion de votre projet, les audits de code ou simplement pour comprendre l’histoire d’un projet open source.

Bref, j’ai trouvé ça cool… Et qui sait, peut-être qu’un jour git-who sera intégré directement dans Git ?