Contexte et objectifs
Face à la croissance rapide de l’écosystème Python, PyPI est devenu une cible privilégiée pour les acteurs malveillants. Depuis 2024, la plateforme propose des attestations numériques qui enregistrent la provenance cryptographique d’un fichier de version. Malgré cette avancée, la plupart des utilisateurs ne saisissent pas la portée de ces attestations, et l’interface précédente ne les mettait pas en avant. L’objectif de la refonte, menée avec Kabu Creative et guidée par le OpenSSF Attestations Style Guide, est de rendre ces signaux visibles et interprétables directement dans l’UI.
Nouveau onglet sécurité et états de provenance
L’onglet Security centralise les informations de provenance. PyPI calcule l’état de chaque version en vérifiant la présence d’attestations par fichier. Deux états sont possibles : Full Provenance, où 100 % des fichiers possèdent une attestation, et No Provenance, où aucune n’est disponible. Les attestations peuvent être de type PyPI Publish, confirmant une publication par un Trusted Publisher, ou SLSA Build Provenance, qui lie le fichier à son commit source, à la plateforme de construction et aux instructions de build. L’utilisateur peut consulter les métadonnées d’attestation ou suivre le lien vers le journal de transparence.
Mise à jour de l’interface et gestion des avertissements
La page de détail du projet a été remodelée : les avertissements de provenance apparaissent en tête de page, aux côtés des bannières de versions yanked, archivées ou pré‑release. Le volet latéral indique l’état de provenance et renvoie à l’onglet sécurité. Le tableau des fichiers de version intègre un filtre de recherche et affiche, pour chaque fichier, son état de provenance ainsi qu’une icône orange lorsqu’il s’agit d’un « late file ». Un fichier est considéré comme tardif s’il est uploadé plus de 14 jours après le timestamp initial, règle appliquée depuis juillet 2026 pour rejeter les nouveaux fichiers après ce délai. Les avertissements de provenance signalent des incohérences : fichiers provenant de différents systèmes de build, changements de dépôt, ou retour à une publication sans attestations. Chaque alerte invite l’utilisateur à vérifier les notes de version ou à interroger le projet.
Analyse des impacts et limites
La visibilité accrue des attestations renforce la capacité des développeurs à valider l’origine d’un paquet avant installation, réduisant le risque d’exécution de code non vérifié. Cependant, les versions antérieures à l’adoption du Trusted Publishing restent sans provenance, ce qui oblige les utilisateurs à se reposer sur des signaux de confiance classiques (historique du mainteneur, activité du dépôt). Les avertissements peuvent générer de faux positifs : des migrations légitimes de dépôt ou des changements de workflow déclenchent les mêmes alertes que des compromissions. La politique de rejet des fichiers tardifs, effective depuis juillet 2026, limite la surface d’attaque mais impose aux mainteneurs une discipline stricte de publication. Enfin, la dépendance à des tiers (OpenSSF, Kabu Creative) pour le design et le financement introduit une chaîne de responsabilité supplémentaire qui doit être surveillée.
