Résumé

  • PyPI précise qu’enlever un utilisateur d’un projet ne retire pas les Trusted Publishers que cet utilisateur a pu enregistrer.
  • Le rôle d’un collaborateur, la configuration d’une identité CI, le jeton de téléversement et la provenance d’un fichier n’attestent pas de la même chose.
  • Une sortie de mainteneur défendable relie ces états sans transformer l’un d’eux en preuve universelle.

La sortie d’un mainteneur est volontiers racontée comme une opération unique : le compte disparaît, l’accès disparaît, le risque disparaît. PyPI demande davantage de précision. Sa documentation de sécurité sur Trusted Publishing indique qu’un utilisateur retiré d’un projet n’emporte pas automatiquement avec lui les Trusted Publishers qu’il avait pu enregistrer. Elle demande donc d’examiner tous les Trusted Publishers lors de l’offboarding d’un mainteneur.

Cette règle ne soupçonne personne. Elle ne dit ni qu’un ancien collaborateur a forcément inscrit un éditeur, ni qu’une configuration conservée est dangereuse, ni qu’un paquet a été publié. Elle fixe une limite de preuve : le registre des rôles humains et le registre des identités de publication ne sont pas la même chose. Une liste de collaborateurs modifiée établit un changement de rôle; elle ne décrit pas encore l’état des identités CI autorisées à publier.

Les rôles PyPI rendent cette séparation lisible. Dans un compte d’organisation, un Maintainer peut téléverser des versions, tandis qu’un Owner peut administrer le projet et ses collaborateurs. Trusted Publishing répond à une autre question : une configuration particulière auprès d’un service CI est-elle reconnue par PyPI pour échanger un jeton OpenID Connect contre un jeton de téléversement de courte durée, limité au projet ? La brièveté du jeton réduit l’exposition d’un secret; elle ne transforme pas la configuration de l’éditeur en conséquence automatique du retrait d’un compte humain.

Il faut donc éviter quatre phrases qui se remplacent trop facilement. « Le collaborateur a été retiré » décrit un état de compte. « La voie de publication a été révoquée » exige l’examen de chaque Trusted Publisher. « Aucune version n’a été publiée par cette voie » exige un registre d’événements. « Ce fichier a été téléversé par telle identité » peut être étayé plus étroitement par une attestation de publication et sa provenance. Ces propositions peuvent converger dans un cas donné, mais les documents PyPI ne permettent pas de les confondre.

L’attestation aide précisément parce qu’elle reste bornée. Une PyPI Publish Attestation peut établir qu’une distribution donnée a été téléversée au moyen d’un Trusted Publisher et identifier l’identité utilisée. L’Integrity API permet d’obtenir la provenance d’un projet, d’une version et d’un fichier nommés. C’est une observation sur un artefact déterminé. Ce n’est ni le procès-verbal intégral d’un départ, ni la preuve qu’un ancien utilisateur pilote encore un workflow, ni un jugement sur la sûreté du code.

PyPI le dit explicitement : une attestation renseigne sur l’origine, pas sur la confiance qu’un vérificateur devrait accorder à l’identité ou au programme.

Le risque institutionnel est la substitution de dossiers. Le ticket qui retire un compte est visible, horodaté et facile à archiver. La configuration des éditeurs peut relever d’une autre vue; les permissions du workflow CI, d’une autre encore. Plus tard, un lecteur retrouve le ticket et lui prête des réponses qu’il ne contient pas : quels éditeurs étaient présents, lesquels ont été revus, quel choix a été fait et quelle identité apparaît dans les publications ultérieures.

Daniel Kade propose un relevé de jointure d’offboarding, proportionné et sans secret. Il lie le projet, le changement de rôle, un inventaire daté des Trusted Publishers, les contraintes d’identité conservées à un niveau sûr, le relecteur responsable et le sort de chaque éditeur — maintien, modification ou retrait. Les provenances ultérieures restent des observations distinctes, liées à un fichier. Un relevé protégé peut contenir le détail opérationnel; une trace d’audit peut conserver l’acte, son auteur et sa portée.

Cette méthode rend aussi les situations ordinaires vérifiables. Il est possible qu’aucun éditeur ne soit concerné. Il est possible qu’une voie automatisée soit délibérément maintenue sous une autre responsabilité. Il est possible qu’une nouvelle identité remplace l’ancienne et que la provenance d’une distribution ultérieure le montre. Rien de cela ne doit être inféré d’un simple nom retiré. Le but est de préserver la valeur exacte de chaque trace, non de fabriquer un incident.

Sources

  1. PyPI — Modèle de sécurité Trusted Publishers
  2. PyPI — Publication avec un Trusted Publisher
  3. PyPI — Rôles et entités
  4. PyPI Publish Attestation v1
  5. PyPI — Modèle de sécurité des attestations
  6. PyPI Integrity API