Il ne faut pas considérer le Trusted Publishing de PyPI comme un signal de confiance pour un paquet
(blog.yossarian.net)- La « confiance » dans Trusted Publishing ne signifie pas qu’un humain peut faire confiance au paquet, mais désigne une relation d’authentification de publication entre une identité machine externe, comme un pipeline CI/CD, et l’index de paquets
- L’implémentation de PyPI repose sur une fédération OIDC et émet des identifiants de publication courts et à portée limitée au lieu de jetons API de longue durée, afin de réduire l’exposition d’identifiants durables et surdimensionnés
- Après son lancement public par PyPI en 2023, le modèle s’est étendu à npm, RubyGems, crates.io, NuGet, etc., mais la complexité du modèle de données, le traitement spécifique à chaque fournisseur OIDC et le risque de compromission CI/CD demeurent
- PyPI ne met pas en avant l’état de Trusted Publishing avec une coche verte sur la page du projet, et l’affiche seulement comme une simple métadonnée Yes/No dans le détail des fichiers, afin de réduire le risque d’interprétation comme signal de sécurité
- Trusted Publishing et les attestations PyPI indiquent seulement une authentification de publication ou la présence d’une signature fondée sur une identité machine ; sans faire confiance séparément à cette identité, on ne peut pas en déduire la sécurité ou la qualité du paquet
La portée de la confiance traitée par Trusted Publishing
- Trusted Publishing n’est pas une fonctionnalité disant aux humains de faire confiance à un paquet, mais une méthode d’authentification qui traite de la confiance entre machines
- Considérer Trusted Publishing comme une question de confiance humaine est une erreur de catégorie
- L’essentiel consiste à établir une relation de confiance pour l’authentification des publications entre une identité machine externe, comme un workflow CI/CD, et l’identité du projet sur l’index de paquets
L’architecture du Trusted Publishing de PyPI
- « Trusted Publishing » est le terme employé par PyPI pour décrire sa méthode d’authentification basée sur une fédération OpenID Connect
- PyPI l’a lancée en 2023, puis npm, RubyGems, crates.io, NuGet l’ont également adoptée
- Le point de départ repose sur deux problèmes
- Les identifiants de longue durée, comme les jetons API d’index, sont difficiles à gérer de manière sûre, et les utilisateurs ont du mal à définir un principe de moindre privilège et une date d’expiration, ce qui les rend facilement surdimensionnés
- De nombreux utilisateurs créent des identifiants pour les injecter dans des plateformes CI/CD, alors même que ces plateformes disposent aussi, via OIDC, de mécanismes pour prouver le contrôle d’identités machine spécifiques
- L’utilisateur enregistre une fois une identité machine CI/CD comme Trusted Publisher dans l’index de paquets ; lorsque le CI/CD présente un jeton d’identité, l’index le vérifie puis émet un identifiant de publication court et à portée limitée
Avantages et limites persistantes
- Le modèle d’identifiants courts et à portée intrinsèquement limitée est considéré comme une approche très réussie pour les utilisateurs de PyPI
- Les utilisateurs préfèrent une méthode où ils n’ont pas à gérer eux-mêmes des identifiants lorsqu’il n’y en a pas besoin
- Les grands projets open source et les entreprises apprécient le fait que le droit de publication soit lié à une identité source plutôt qu’à un mainteneur individuel
- Trusted Publishing conserve toutefois une complexité structurelle
- Les « pending publishers » de PyPI résolvent le problème des projets inexistants, mais compliquent le modèle de données et sont plus déroutants pour les utilisateurs que le Trusted Publishing classique
- Les fournisseurs OIDC peuvent placer des valeurs variées dans le jeu de claims au-delà de certains claims communs, si bien que l’index doit traiter séparément les formes propres à chaque fournisseur
- Pour cette raison, les identités machine ne sont pas interchangeables entre IdP OIDC, ce qui explique aussi pourquoi PyPI ajoute lentement de nouveaux fournisseurs Trusted Publishing
- Si un workflow CI/CD est compromis, un attaquant peut exfiltrer des identifiants Trusted Publishing ou les jetons OIDC ID qui leur servent de graine
- C’est comparable au cas où des identifiants de longue durée sont présents dans le workflow, mais les identifiants Trusted Publishing n’exposent pas les mêmes risques de portée et de durée de vie
- PyPI atténue le risque de compromission CI/CD en refusant l’échange de jetons pour les identités machine correspondant à des déclencheurs facilement exploitables, comme
pull_request_target
Pourquoi ce n’est pas un signal de confiance pour un paquet
- Trusted Publishing n’est qu’une méthode d’authentification et ne fournit aucune information sur la sécurité, la qualité ou l’opportunité d’utiliser un paquet
- PyPI est un index public où n’importe qui peut publier, et n’importe qui peut aussi publier via un Trusted Publisher
- Il est possible de publier un malware ou du code vulnérable même avec un Trusted Publisher
- Sur ce point, c’est identique aux jetons API, l’autre méthode d’authentification de publication de PyPI
- Trusted Publishing n’est pas obligatoire sur PyPI et ne pourra probablement jamais le devenir
- L’imposer aux utilisateurs est irréalisable sur le plan de l’ingénierie, et peu souhaitable à la fois techniquement et socialement
- Trusted Publishing restera toujours une option
Comment l’interface de PyPI réduit les malentendus
- PyPI veille à éviter que les utilisateurs interprètent l’état de Trusted Publishing comme un signal de confiance pour le paquet
- Il n’y a pas de coche verte indiquant l’état de Trusted Publishing sur la page du projet
- Les coches vertes relatives à un état contrôlé par l’utilisateur sont réservées aux liens pour lesquels PyPI peut prouver qu’ils proviennent de la même source que le paquet lui-même
- Une URL vérifiée prouve seulement qu’au moment de la vérification, cette URL était sous le contrôle du propriétaire du paquet PyPI ; cela n’implique aucune sécurité supplémentaire concernant l’URL ou le projet
- L’état Trusted Publishing d’un fichier donné est affiché comme une simple valeur Yes/No dans le détail du fichier
- La zone de métadonnées du fichier n’est pas rendue comme une information importante pour le jugement de confiance de l’utilisateur
- Même le blob JSON provenant du user agent du client d’upload n’est pas particulièrement mis en forme
Distinction avec les attestations
- Cette question est distincte des attestations de PyPI
- Les attestations utilisent elles aussi actuellement des identités machine OIDC, mais ce ne sont pas des signaux de confiance
- Une attestation ressemble à une signature reposant sur une identité machine, mais comme n’importe qui peut publier sur PyPI, n’importe qui peut aussi signer avec une identité machine qu’il contrôle
- La présence d’un Trusted Publisher ne signifie pas nécessairement qu’une attestation existe, et la présence d’une attestation ne signifie pas non plus qu’un utilisateur final devrait faire confiance à une identité donnée
- Le modèle de fiabilité des attestations de PyPI documente également ce point dans sa documentation
1 commentaires
Avis sur Lobste.rs
Bon article. Trusted Publishing et les attestations (attestation) offrent des garanties différentes face à des modes de défaillance distincts, et les deux sont aussi séparés de ce que la plupart des utilisateurs appellent la confiance.
Si Trusted Publishing est devenu possible, c’est parce qu’au cours des 15 dernières années, de nombreux projets open source sont passés de l’auto-hébergement — listes de diffusion, dépôts Git, bug trackers, serveurs de build — à des forges centralisées.
Maintenant que les inconvénients des forges centralisées deviennent plus évidents, les projets envisagent à nouveau l’auto-hébergement.
Dans les années 2010, la commodité et les effets de réseau social ont poussé les projets vers les forges centralisées, mais aujourd’hui les facteurs qui les y retiennent sont bien plus nombreux, y compris Trusted Publishing.
Méfiez-vous de l’autorité — encouragez la décentralisation
— « The Hacker Ethics », Hackers: Heroes of the Computer Revolution (Steven Levy, 1984)
Il y a une certaine ironie à qualifier l’identité fédérée de forme de verrouillage.
À peu près à la même époque, il y a environ 25 ans, il y avait aussi l’ASF, mais l’ASF impliquait aussi une lourde charge de gouvernance. Avant cela, il y avait le projet GNU, qui mettait davantage l’accent sur l’idéologie du logiciel libre et se concentrait moins sur un service structuré d’hébergement de projets. GNU existait en effet avant qu’il y ait une idée claire des services dont les projets de logiciel libre avaient besoin.
Dans les années 1990, les projets de logiciel libre étaient généralement hébergés sur des services en temps partagé d’universités ou sur le serveur en colocation d’un ami. Par exemple PuTTY ou Hyperreal.org, qui hébergeait Apache httpd avant l’ASF.
Peu de projets devenaient assez gros pour justifier leur propre infrastructure, et l’hébergement bon marché n’est devenu possible que relativement récemment.