Les mainteneurs du noyau Linux expérimentent « Linux ID », une couche d’identité décentralisée et respectueuse de la vie privée pour vérifier qui signe du code. Remplaçant progressivement le vieux Web of Trust PGP, ce système s’appuie sur DIDs, verifiable credentials et registres de transparence pour rendre l’authentification des contributeurs plus robuste et plus révoquable — une évolution importante pour la sécurité de la chaîne d’approvisionnement logicielle.
Contexte
- Historiquement, la communauté du noyau Linux s’appuyait sur PGP et un Web of Trust (signatures de clés PGP obtenues souvent lors de rencontres en personne) pour identifier les contributeurs et valider les artefacts. Ce modèle est devenu lourd à maintenir, source de risques de confidentialité et fragile face à certaines attaques (ex. compromission de sites de développement ou de paquets).
- Après incidents passés (p. ex. intrusion sur kernel.org en 2011, et attaques ciblant certains utilitaires), les mainteneurs cherchent une méthode plus moderne et plus praticable pour prouver l’identité des personnes et l’origine du code.
Ce que proposent les mainteneurs : « Linux ID »
Objectif : remplacer ou compléter le modèle PGP par une couche d’identification décentralisée et modulable qui peut attester, de manière cryptographique, qu’une clé et un commit appartiennent bien à une personne reconnue par la communauté.
Principes clés
- Issuer-agnosticité : plusieurs émetteurs possibles (ID gouvernementales numériques, vérificateurs tiers, employeurs, la Linux Foundation, etc.).
- Composabilité : des chemins de confiance croisés permettent de relier des identités émises par différents organismes.
- Respect de la vie privée : utilisation de DIDs pair-à-pair éphémères pour empêcher le traçage permanent des relations sociales.
- Durée courte des attestations : privilégier des certificats/attestations à durée de vie limitée et permettre la révocation rapide.
- Transparence et audit : journalisation (transparency logs) pour traquer les attestations et faciliter la détection d’abus.
Comment ça marche (niveau technique résumé)
- Identifiants décentralisés (DIDs) : mécanisme W3C pour créer des identifiants uniques liés à des clés publiques et des endpoints (p. ex. did:web).
- Verifiable Credentials (VC) : attestations cryptographiques déclarant des faits (ex. « X est employé par Y », « Y reconnaît X comme mainteneur »). Ces credentials peuvent être émises par différents acteurs et vérifiés indépendamment.
- Messaging décentralisé (DIDComm, REST, etc.) : échange de credentials et établissement de relations pair-à-pair, avec DIDs éphémères pour réduire la corrélation et le profilage.
- Intégration avec Git/CI : une fois vérifiées, ces attestations peuvent être jointes aux signatures de commits/tags, alimenter des registres de transparence ou être utilisées par des systèmes d’intégration continue pour prendre des décisions d’autorisation.
- Délégation cryptographique : possibilité de déléguer des permissions limitées à des agents (y compris des agents automatisés/IA) avec des credentials séparés et révocables.
Avantages attendus
- Meilleure sécurité de la chaîne d’approvisionnement : accroissement du coût d’opération pour un attaquant (plus d’attestations à falsifier ou conserver).
- Gestion plus souple des identités : plus facile d’émettre, renouveler ou révoquer des preuves d’identité sans réunions physiques obligatoires.
- Confidentialité améliorée : minimise la surface exposée du réseau social des mainteneurs (pas de « qui vit où » public).
- Flexibilité : chaque projet peut définir son niveau de preuve requis et choisir ses autorités de confiance.
Limites et risques
- Ce n’est pas une garantie absolue contre les attaques supply-chain (les mainteneurs reconnaissent qu’un xz‑style reste théoriquement possible), mais c’est une forte barrière supplémentaire.
- Dépendance à un écosystème d’émetteurs fiables et à des registres de révocation bien tenus.
- Complexité technique et adoption : migration du Web of Trust existant, intégration avec les outils actuels (Git, workflows), formation des contributeurs.
- Risques de centralisation involontaire si trop de confiance est placée dans un petit nombre d’émetteurs.
- Ingénierie de la confidentialité : choix mal faits sur la durée/visibilité des credentials pourraient introduire de nouveaux vecteurs de social engineering.
Calendrier et prochaines étapes
À ce stade, le projet est en phase de prototypage et de discussions au sein de la Linux Foundation et d’instances comme le Kernel Summit / Linux Plumbers. Les mainteneurs prévoient des tests en parallèle avec l’infrastructure PGP existante, et une importation graduelle du Web of Trust pour faciliter la transition. Le déploiement complet ne sera pas immédiat : on peut s’attendre à des expérimentations publiques et une adoption progressive dans l’année(s) qui suit la maturation des outils et des politiques.
Ce que cela change pour les contributeurs
- Moins d’obligation de participer à des sessions de signature de clés en personne ; possibilité d’obtenir des preuves via diverses autorités.
- Besoin de comprendre et gérer de nouveaux artefacts (DIDs, verifiable credentials) et peut‑être d’utiliser de nouveaux outils pour produire/joindre ces attestations à leurs contributions.
- Possibilité d’utiliser des agents ou outils automatisés avec credentials dédiés pour CI/CD ou tests, tout en gardant la capacité de révoquer ces droits rapidement.
Conclusion
Linux ID est une évolution importante vers une authentification moderne, décentralisée et pragmatique des contributeurs et de leur code. Plutôt que d’abandonner PGP du jour au lendemain, le plan vise une transition progressive : importer l’existant, tester les nouveaux outils, et laisser chaque communauté définir son niveau de confiance. Si l’approche est bien conduite (diversité d’émetteurs, bonne gestion des révocations), elle peut significativement relever le niveau de sécurité des contributions open source et réduire la probabilité de compromissions à grande échelle.
Sources et lectures complémentaires
- Steven Vaughan-Nichols, ZDNet — « Linux explores new way of authenticating developers and their code »
- Spécification W3C sur les Identifiants Décentralisés (DID Core)
- Spécification W3C Verifiable Credentials Data Model
- DIDComm (protocole de messagerie pour DIDs)
- Guide existant du kernel sur l’usage de PGP pour les mainteneurs
Suggestions pour WordPress
- Utiliser le titre fourni et insérer le chapo en haut de l’article (déjà inclus ici).
- Ajouter une image d’illustration (ex. photo de conférence ou schéma DIDs) en tant qu’image à la une.
- Structurer l’article avec des H2/H3 (comme ici) pour la lisibilité et activer les anchors si possible.
- Ajouter les sources en bas de l’article avec liens cliquables (déjà fournis).
Souhaitez-vous que je fournisse ce contenu en HTML prêt à coller (formaté différemment selon l’éditeur Gutenberg ou l’éditeur classique) ou que j’ajoute des méta-données WordPress (ex. excerpt, categories, tags) dans le JSON ?
