Parfois, c'est galère de chercher des logiciels sur GitHub... et je sais de quoi je parle car je passe littéralement mes journées à faire ça... Faut trouver un projet cool, faut aller dans les releases ou le compiler, l'installer, le tester et ensuite déterminer si ça vous sera utile avant de passer à la rédaction d'un article comme celui que vous êtes en train de lire.

J'adore faire ça mais aller digger Github, ça peut vite devenir pénible.

Alors ça tombe bien car voici un projet qui transforme GitHub en véritable App Store. Ça s'appelle Github Store , c'est disponible sur Android et desktop (Windows, macOS, Linux), et ça vous propose une interface propre qui présente les logiciels open source comme dans un store classique, avec des catégories, des screenshots, des descriptions, et un bouton pour installer en un clic.

Comme c'est bien pensé, l'application va automatiquement indexer les repos GitHub qui contiennent des binaires installables dans leurs releases. Elle filtre les vrais installeurs (.apk, .exe, .msi, .dmg, .pkg, .deb, .rpm) et ignore les archives de code source que GitHub génère automatiquement, du coup, vous ne voyez que les trucs que vous pouvez réellement installer.

L'interface est organisée avec des sections "Populaire", "Récemment mis à jour" et "Nouveautés" et vous pouvez aussi filtrer par plateforme pour ne voir que les apps compatibles avec votre système. Puis quand vous cliquez sur une app, vous avez tous les détails : nombre d'étoiles, forks, issues, le README complet rendu en markdown, les notes de release, et la liste des fichiers disponibles avec leur taille.

Pour qu'un repo apparaisse dans Github Store, il faut qu'il soit public, qu'il ait au moins une release publiée (pas de brouillon), et que cette release contienne un installeur dans un format supporté. Et y'a pas de soumission manuelle à faire, puisque tout est automatique.

Côté technique, c'est du Kotlin Multiplatform avec Compose pour l'interface. Sur Android, quand vous installez une app, ça délègue au gestionnaire de paquets natif et sur desktop, ça télécharge le fichier et l'ouvre avec l'application par défaut de votre système.

Vous pouvez vous connecter avec votre compte GitHub via OAuth. C'est pas obligatoire, mais ça permet de passer de 60 à 5000 requêtes par heure sur l'API GitHub, ce qui est bien si vous êtes du genre à explorer plein de repos.

L'app est dispo sur les releases GitHub du projet et aussi sur F-Droid pour Android. C'est sous licence Apache 2.0, donc vous pouvez en faire ce que vous voulez.

Attention quand même, les développeurs le précisent bien que Github Store ne fait que vous aider à découvrir et télécharger des releases. La sécurité et le comportement des logiciels que vous installez, c'est la responsabilité de leurs auteurs respectifs et la votre, donc comme d'hab, faites gaffe à ce que vous installez.

Un grand merci à Lorenper pour l'info !

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.