Android sans tags Git : quand l’open source perd sa transparence

Google vient de faire quelque chose de discret, sans annonce, sans billet de blog, sans ticket public : l’équipe de GrapheneOS — le fork Android orienté vie privée et sécurité — a remarqué que Google a cessé de pousser les tags Git sur certains dépôts du code source Android. Ça n’a l’air de rien comme ça. En pratique, c’est le genre de changement qui, s’il se généralise, peut rendre l’audit du code Android bien plus complexe qu’il ne devrait l’être.

On parle d’un détail technique que 99 % des utilisateurs d’Android ne verront jamais. Mais pour les équipes qui maintiennent des forks d’AOSP, pour les chercheurs en sécurité qui veulent vérifier ce qui tourne sur leur appareil, ou pour quiconque croit encore qu’Android est réellement open source dans l’esprit du terme, cette décision mérite qu’on s’y attarde sérieusement.

D’autant plus qu’elle n’a pas été communiquée. Et dans le monde du logiciel libre, un changement silencieux dans un dépôt public aussi central qu’AOSP, ça soulève des questions qui vont bien au-delà d’un simple détail de workflow Git.

Un tag Git, c’est quoi et pourquoi ça compte vraiment

Un tag Git, c’est un marqueur attaché à un commit particulier. Là où une branche est mobile — elle avance avec chaque nouveau commit — un tag est statique : il pointe toujours vers le même état du code. Dans le contexte d’un projet comme Android, les tags correspondent aux releases officielles et aux patches de sécurité mensuels. C’est grâce à eux qu’on peut dire « ce code, c’est exactement ce qui correspond à la version 14.0.0_r21 » sans avoir à croiser dix sources différentes.

Sans tags, le code source reste accessible — c’est public, c’est AOSP, ça reste là. Mais identifier précisément quel commit correspond à quelle version de l’OS devient un exercice de détective. Tu dois croiser les dates de commits, les messages, les changelogs publiés ailleurs, les bulletins de sécurité mensuels… Bref, tu perds la référence canonique qui rend l’audit rapide et fiable. Un simple git checkout android-14.0.0_r21 se transforme en chasse au trésor.

Pour ceux qui maintiennent des reproductible builds — c’est-à-dire qui veulent s’assurer que le binaire qu’ils compilent est strictement identique au binaire distribué — les tags sont une brique fondamentale. Leur absence ne rend pas la chose impossible, mais elle rajoute une couche de friction et d’incertitude que personne n’avait demandée. Et dans un contexte de sécurité, la friction, c’est exactement ce qui conduit à louper un patch critique.

GrapheneOS a sonné l’alarme — Google n’a pas répondu

C’est l’équipe de GrapheneOS qui a publié la découverte via leur compte Mastodon. Pas un ticket ouvert chez Google, pas une réponse officielle de l’équipe AOSP — juste un constat factuel posté par une équipe qui scrute le code Android de très près parce que c’est littéralement leur métier. GrapheneOS, pour rappel, c’est un fork Android connu pour ses choix techniques pointus : sandboxed Google Play, durcissement du noyau, vérifications d’intégrité renforcées. Certaines de leurs innovations ont fini par atterrir dans Android mainline quelques années après leur introduction dans GrapheneOS.

Leur signalement est factuel et sobre : certains dépôts du projet AOSP n’ont plus reçu de nouveaux tags depuis plusieurs releases. Ce n’est pas un bug, ce n’est pas un oubli ponctuel — les patterns sont trop cohérents pour ça. Quelqu’un, quelque part chez Google, a décidé (ou oublié de décider, ce qui revient souvent au même dans une grande organisation) de ne plus pousser ces tags.

Le problème avec ce genre de changement, c’est l’asymétrie d’information qu’il crée. Google sait exactement à quel commit correspond chaque release Android — c’est leur code, leur infrastructure, leurs builds internes. Les développeurs externes, eux, doivent désormais faire du reverse-engineering pour retrouver une information qui était auparavant accessible en une commande git tag -l. Ce n’est pas une rupture de contrat open source. Mais c’est une dégradation réelle de la transparence.

Les forks Android, premiers perdants de l’affaire

GrapheneOS n’est pas le seul concerné. LineageOS, CalyxOS, DivestOS, et les dizaines d’autres projets qui basent leur travail sur AOSP ont besoin de savoir exactement sur quoi ils s’appuient. Quand tu développes une application sur mesure ou un système d’exploitation dérivé, la première chose que tu fais, c’est d’ancrer ton travail à une référence stable et vérifiable. Les tags Git jouent exactement ce rôle — ils sont le point de départ de tout diff, de tout cherry-pick, de toute comparaison avec l’upstream.

Sans eux, la synchronisation entre les mises à jour de sécurité Google et les forks devient plus hasardeuse. Tu peux rater un patch critique parce que tu n’arrives pas à identifier précisément à quel moment il a été intégré dans le code source upstream. Dans un écosystème où les patches de sécurité Android protègent chaque mois des centaines de millions d’appareils contre des vulnérabilités actives, c’est un vrai problème opérationnel, pas juste un inconfort de développeur.

L’ironie de la situation, c’est que les projets comme GrapheneOS contribuent activement à renforcer la sécurité d’Android en général. Certaines de leurs innovations ont été reprises par Google dans AOSP. Rendre leur travail plus difficile, même indirectement, c’est scier une branche sur laquelle Google lui-même est assis.

AOSP : open source de façade ou vraie transparence ?

Android est officiellement open source sous licence Apache 2.0. Mais « open source » ne veut pas dire « transparent ». Google a depuis longtemps une pratique bien rodée : publier le code source d’AOSP après coup, souvent en même temps que la release publique, parfois après. Les modifications propriétaires — Google Play Services, les applications Google — restent fermées. Les binaires des composants constructeurs, encore plus. Le code est là, légalement accessible, mais les conditions de sa consultation sont de plus en plus contrôlées.

Publier du code sans les métadonnées qui permettent de le contextualiser, c’est publier un livre sans numéros de pages ni table des matières. Techniquement accessible, pratiquement opaque.

Ce que révèle l’affaire des tags, c’est une tendance de fond : Google publie le code, mais contrôle de plus en plus la lisibilité de ce code. Chaque couche d’opacité ajoutée — que ce soit retarder les publications, retirer les tags, ou fragmenter le code entre dépôts de plus en plus nombreux — augmente le coût d’entrée pour les auditeurs extérieurs. Pas illégalement. Juste… stratégiquement.

La question n’est pas de savoir si Google enfreint sa licence open source — il ne l’enfreint pas. La question est de savoir si « publier le code » est suffisant pour qu’on puisse réellement parler de transparence. Et la réponse, avec cette décision, penche clairement vers le non.

Ce que les développeurs font concrètement pour compenser

La communauté ne reste pas inactive. Certains projets ont commencé à maintenir leurs propres tags sur des mirrors du code AOSP, ou à documenter manuellement les correspondances commit/version dans des fichiers de référence versionnnés. C’est du travail en plus, du travail qui ne devrait pas exister — mais l’écosystème open source est habitué à combler les lacunes laissées par les grands acteurs. Ce n’est pas glorieux, mais ça fonctionne.

D’autres équipes ont mis en place des scripts d’automatisation pour détecter les nouveaux commits significatifs via des heuristiques sur les messages de commit et les fichiers modifiés, et les corréler avec les bulletins de sécurité officiels. C’est le genre de maintenance proactive qui distingue un fork sérieux d’un projet qui accumule silencieusement de la dette sécurité. Pour tout ce qui touche à la maintenance et au suivi de sécurité de tes environnements, cette rigueur de l’upstream tracking n’est jamais optionnelle — que tu maintiens un fork Android ou n’importe quelle dépendance critique.

Il faut aussi noter que cette situation met en lumière l’importance des outils de comparaison de code entre releases. Des projets comme repo (l’outil de Google lui-même pour gérer les dépôts AOSP multi-composants) deviennent plus critiques, mais aussi plus lourds à exploiter sans la sémantique des tags pour naviguer l’historique. C’est un cercle vicieux : moins de métadonnées = plus de dépendance aux outils propriétaires de Google pour s’y retrouver.

Mon avis : ce n’est pas anodin, et ça ne va pas s’arranger

Je pense que cette décision est symptomatique d’une évolution plus large : Google traite de plus en plus AOSP comme une obligation légale à honorer plutôt qu’comme un engagement de transparence à entretenir. Publier le code, oui. Faciliter son audit par des tiers, beaucoup moins. C’est une posture qui a une logique commerciale compréhensible — Google n’a pas grand intérêt à ce que des forks comme GrapheneOS prospèrent trop facilement. Mais c’est une posture qui érode lentement la confiance dans l’écosystème Android open source.

Le fait que ce soit GrapheneOS qui ait dû signaler le problème, et non Google qui l’ait communiqué proactivement, en dit long. Une entreprise réellement engagée dans la transparence open source ne laisse pas ses partenaires de l’écosystème découvrir par eux-mêmes qu’une pratique fondamentale vient de changer. Mon pari : si la pression communautaire ne force pas Google à rétablir les tags sur l’ensemble des dépôts concernés dans les prochains mois, d’autres simplifications discrètes de ce type suivront.

L’open source n’est pas un état binaire. On peut publier du code tout en le rendant progressivement moins utilisable par des tiers. La vraie question que cette affaire pose à l’industrie, c’est : à quel moment accepte-t-on de qualifier d’ »open source » quelque chose qui l’est de moins en moins dans la pratique ? Pour l’instant, la réponse collective semble être « encore un peu ». Ce n’est pas une bonne trajectoire.