Trusted Publishing ne doit pas être considéré comme un signal de confiance pour les packages

 (blog.yossarian.net)
1 points par GN⁺ 5 시간 전 | 1 commentaires | Partager sur WhatsApp
  • La « confiance » dans Trusted Publishing ne signifie pas qu’un humain peut faire confiance au package, mais désigne la relation d’authentification d’upload entre une identité machine externe, comme un CI/CD, et un index de packages
  • L’implémentation de PyPI fonctionne au-dessus d’une fédération OIDC et réduit l’exposition d’identifiants de longue durée ou sur-privilégiés en émettant, au lieu de jetons API longue durée, des identifiants de publication de courte durée et à portée limitée
  • Après son lancement public par PyPI en 2023, le mécanisme s’est étendu à npm, RubyGems, crates.io, NuGet, etc., mais la complexité du modèle de données, le traitement propre à chaque fournisseur OIDC et la possibilité de compromission du CI/CD demeurent
  • PyPI ne met pas en avant l’état Trusted Publishing sur la page projet avec une coche verte ; il l’affiche seulement comme une simple métadonnée Yes/No dans les détails des fichiers, afin de réduire le risque qu’il soit interprété comme un signal de sécurité
  • Trusted Publishing et les attestations PyPI indiquent seulement si l’authentification d’upload ou la signature fondée sur une identité machine est utilisée ; avant de faire séparément confiance à cette identité, ils ne permettent pas de juger la sécurité ou la qualité d’un package

Le périmètre de confiance couvert par Trusted Publishing

  • Trusted Publishing n’est pas une fonctionnalité qui dit aux humains de faire confiance à un package, mais une méthode d’authentification qui traite de la confiance entre machines
  • Voir Trusted Publishing comme une question de confiance ou non par les humains revient à se tromper de catégorie
  • Le point central est d’établir une relation de confiance pour l’authentification d’upload entre une identité machine externe, comme un workflow CI/CD, et l’identité de projet dans l’index de packages

La structure de Trusted Publishing dans PyPI

  • « Trusted Publishing » est le terme employé par PyPI pour décrire une méthode d’authentification au-dessus d’une fédération OpenID Connect
  • PyPI l’a rendu public en 2023, puis npm, RubyGems, crates.io, NuGet, entre autres, l’ont aussi adopté
  • Le point de départ est double
    • Les jetons d’API d’index, qui sont des identifiants de longue durée, sont difficiles à gérer de façon sûre ; les utilisateurs ont du mal à définir le moindre privilège et une durée d’expiration, ce qui les conduit facilement à les configurer avec trop de droits
    • Beaucoup d’utilisateurs créent des identifiants pour les placer dans des plateformes CI/CD, et ces plateformes disposent elles aussi de mécanismes permettant de prouver, via OIDC, le contrôle d’une identité machine spécifique
  • L’utilisateur enregistre une fois dans l’index de packages un Trusted Publisher, c’est-à-dire l’identité machine du CI/CD ; lorsque le CI/CD présente un jeton d’identité, l’index le vérifie et émet des identifiants de publication de courte durée et à portée limitée

Avantages et limites restantes

  • L’approche consistant à utiliser des identifiants de courte durée, avec une portée intrinsèquement définie, est considérée comme un grand succès pour les utilisateurs de PyPI
    • Les utilisateurs préfèrent ne pas gérer directement des identifiants lorsqu’ils n’en ont pas besoin
    • Les grands projets open source et les entreprises apprécient que les droits de publication soient liés à une identité source plutôt qu’à un mainteneur individuel
  • Trusted Publishing conserve malgré tout une complexité structurelle
    • Les « pending publishers » de PyPI résolvent le problème des projets inexistants, mais complexifient le modèle de données et sont plus déroutants pour les utilisateurs que le Trusted Publishing ordinaire
    • Les fournisseurs OIDC peuvent placer différentes valeurs dans le claim set, au-delà de quelques claims communs ; l’index doit donc traiter séparément les formes propres à chaque fournisseur
    • De ce fait, les identités machine ne sont pas interchangeables entre IdP OIDC, et c’est l’une des raisons pour lesquelles PyPI ajoute lentement de nouveaux fournisseurs Trusted Publishing
  • Si un workflow CI/CD est compromis, un attaquant peut exfiltrer les identifiants Trusted Publishing ou le jeton d’identité OIDC qui leur sert de graine
    • C’est similaire au cas où des identifiants de longue durée se trouvent dans le workflow, mais les identifiants Trusted Publishing ne présentent pas le même risque en termes de portée et de durée de vie
    • PyPI atténue le risque de compromission du 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 les packages

  • Trusted Publishing n’est qu’une méthode d’authentification et ne donne aucune information sur le fait qu’un package soit sûr, de qualité ou digne d’être utilisé
  • PyPI est un index public : tout le monde peut y uploader, et tout le monde peut uploader en utilisant un Trusted Publisher
    • Il est aussi possible d’uploader du code malveillant ou vulnérable via un Trusted Publisher
    • Sur ce point, c’est identique à une autre méthode d’authentification d’upload de PyPI : les jetons API
  • Trusted Publishing n’est pas obligatoire sur PyPI et ne pourra pas le devenir à l’avenir
    • Imposer Trusted Publishing aux utilisateurs est irréalisable du point de vue de l’ingénierie, et n’est souhaitable ni techniquement ni socialement
    • Trusted Publishing restera toujours optionnel

Comment l’UI de PyPI réduit les malentendus

  • PyPI veille à ce que les utilisateurs ne confondent pas l’état Trusted Publishing avec un signal de confiance pour un package
  • La page projet ne comporte pas de coche verte indiquant l’état Trusted Publishing
  • Les coches vertes concernant des états contrôlés par l’utilisateur ne sont utilisées que pour des liens dont PyPI peut prouver qu’ils proviennent de la même source que le package 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 package PyPI ; elle n’implique aucune sécurité supplémentaire pour l’URL ou le projet
  • L’état Trusted Publishing d’un fichier donné est affiché dans les détails du fichier comme une simple valeur Yes/No
    • La zone des métadonnées de 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’y est pas rendu correctement

Distinction avec les attestations

  • Ce point est distinct des attestations de PyPI
  • Les attestations utilisent actuellement elles aussi des identités machine OIDC, mais ne constituent pas un signal de confiance
  • Une attestation ressemble à une signature au-dessus d’une identité machine, mais comme tout le monde peut uploader sur PyPI, n’importe qui peut signer avec une identité machine qu’il contrôle
  • La présence d’un Trusted Publisher ne garantit pas qu’une attestation existe, et l’existence d’une attestation ne signifie pas non plus que l’utilisateur final peut faire confiance à une identité donnée
  • Le modèle de fiabilité des attestations de PyPI documente également ce point

À lire aussi

1 commentaires

 
GN⁺ 5 시간 전
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)

    • Trusted Publishing n’implique pas de verrouillage (lock-in). On peut utiliser à tout moment une autre méthode d’authentification, y compris des hôtes avec lesquels PyPI peut s’intégrer.
      Il y a une certaine ironie à qualifier l’identité fédérée de forme de verrouillage.
    • L’auto-hébergement a pratiquement toujours été une préférence de niche. L’objectif de SourceForge était précisément de prendre en charge ce fardeau.
      À 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.
    • Y a-t-il une raison pour laquelle Trusted Publishing ne pourrait pas fonctionner avec un Forgejo auto-hébergé ? S’il y en a une, j’ai dû passer à côté.