Quand vous installez un paquet Python depuis PyPI, vous téléchargez souvent un fichier wheel déjà construit par quelqu’un d’autre.
Vous pouvez lire le code source du projet sur GitHub. Vous pouvez vérifier que le compte qui a publié la release utilise un mécanisme de Trusted Publishing. PyPI peut aussi fournir une attestation qui relie un fichier distribué à une identité et à un workflow de publication.2
Il reste pourtant une question différente : est-ce que ce wheel correspond réellement au code source que vous avez lu ?
Un papier publié en juillet 2026 essaie de mesurer cet écart à grande échelle sur PyPI.1 Brett Cannon, développeur Python, l’a remis en circulation le 15 août avec une question simple : qu’est-ce qui manque encore pour que les builds reproductibles deviennent une propriété ordinaire des paquets Python ?4
La réponse commence par distinguer trois preuves que l’on mélange facilement.
Provenance ne veut pas dire contenu vérifié
La documentation officielle de PyPI est très claire sur la limite de ses attestations actuelles : elles peuvent dire d’où vient un artefact et quel publisher l’a produit, mais pas si vous devriez faire confiance au contenu du paquet.2
C’est déjà important.
Si une nouvelle release censée être produite par un workflow GitHub Actions apparaît soudainement depuis une autre identité, le changement de provenance devient visible. Une attestation peut aussi aider à détecter qu’un artefact a été modifié après sa construction, pendant son stockage ou sa distribution.2
Mais ce mécanisme ne répond pas automatiquement à ce qui s’est passé avant le build.
Un dépôt peut contenir un code source propre et un pipeline de construction compromis peut produire autre chose. À l’inverse, deux builds honnêtes du même code peuvent différer à cause d’un timestamp, d’un ordre de fichiers, d’un chemin absolu ou d’une version d’outil.
Un build reproductible cherche précisément à fermer cette seconde zone d’ombre : une partie indépendante reconstruit l’artefact à partir des mêmes sources et compare le résultat.3
Idéalement, les deux fichiers sont identiques octet pour octet.
Dans la pratique Python, c’est là que les ennuis commencent.
Sur 12 180 releases, l’identité parfaite reste rare
L’étude « No Snake Oil » analyse 12 180 releases populaires de PyPI et s’appuie sur deux systèmes de reconstruction indépendants : macaron d’Oracle et oss-rebuild de Google.1
Le résultat le plus brutal est le taux d’égalité bit-à-bit.
Dans l’échantillon reconstruit par macaron, 15,4 % des rebuilds sont identiques au wheel publié. Du côté d’oss-rebuild, le taux rapporté est de 19,1 %.1
Ce chiffre ne signifie pas que 80 % des paquets sont compromis.
Il signifie qu’un test très strict, « mêmes octets ou échec », confond encore beaucoup de différences malicieuses et de différences banales de construction.
Un wheel est une archive ZIP. Son ordre interne, ses métadonnées, des timestamps ou certains détails générés par le build peuvent changer sans modifier le code qui sera exécuté. À l’inverse, ignorer aveuglément toutes les différences rendrait la vérification inutile.
Les auteurs proposent donc daleq4py, un outil qui compare deux distributions Python en normalisant certaines différences considérées comme non sémantiques tout en conservant des éléments nécessaires à la provenance.1
Avec cette comparaison plus structurée, la part des rebuilds jugés équivalents augmente fortement : 60,2 % pour l’ensemble macaron étudié et 78,9 % côté oss-rebuild lorsque les sources sont elles-mêmes considérées équivalentes.1
C’est beaucoup mieux.
Ce n’est toujours pas 100 %.
La reproductibilité n’est pas seulement un interrupteur oui/non
Le papier est intéressant parce qu’il montre qu’une vérification de build a plusieurs niveaux.
Le niveau le plus simple demande si les archives sont exactement identiques. C’est facile à comprendre, facile à automatiser et difficile à tricher. C’est aussi fragile face aux métadonnées qui ne changent rien au programme.
Le niveau suivant essaie de savoir si les différences sont explicables et sans effet sur l’exécution. C’est plus utile, mais il faut alors écrire des règles de normalisation et prouver qu’elles ne masquent pas la différence importante précisément le jour où quelqu’un en aura besoin.1
Le projet Reproducible Builds insiste depuis longtemps sur la même idée : la reproductibilité ne consiste pas à faire confiance à un serveur de build particulier. Elle sert à rendre possible une vérification indépendante du chemin source-vers-binaire.3
C’est une différence fondamentale avec une signature.
Une signature dit : « cette identité affirme avoir produit ce fichier ».
Un rebuild indépendant essaie de dire : « à partir de ces sources et de ces instructions, j’arrive moi aussi à ce fichier, ou à un artefact dont les différences ont été expliquées ».
Les deux preuves se complètent. Elles ne s’annulent pas.
PyPI a déjà une partie du puzzle
Il serait facile de lire l’étude comme une critique des attestations PyPI. Ce serait rater le point.
Le modèle de sécurité officiel de PyPI reconnaît explicitement sa frontière. L’attestation actuelle protège surtout la chaîne de publication et l’identité du producteur. La documentation renvoie elle-même vers les builds reproductibles pour les garanties qui portent sur ce qui s’est passé pendant la construction.2
Autrement dit, PyPI ne prétend pas avoir résolu le problème que le papier mesure.
Ce qui manque est plutôt une articulation plus ordinaire entre les couches : source connue, workflow connu, artefact attesté, environnement de build suffisamment déterministe, puis reconstruction indépendante quand le niveau de risque le justifie.
Des projets comme oss-rebuild travaillent déjà sur cette dernière partie à grande échelle.5
Le papier montre toutefois que Python possède un obstacle particulier : le simple fait de reconstruire ne suffit pas si la chaîne fabrique des différences non pertinentes à chaque passage.
Avant de détecter les modifications malveillantes, il faut donc réduire le bruit normal.
La preuve devient une propriété du processus de fabrication
Pour un développeur, un wheel ressemble à un fichier logiciel.
Pour la chaîne de sécurité, il ressemble davantage à une pièce fabriquée.
Le dépôt source joue le rôle du plan. Le système de build est l’atelier. Le wheel est l’objet qui sort de la machine. Une attestation documente qui a lancé la production et dans quel contexte. Un rebuild indépendant tente de refaire la pièce avec le même plan pour voir si elle ressort identique.
Cette analogie a une limite évidente : copier un binaire ne ressemble pas physiquement à usiner deux pièces. Mais elle aide à voir le problème.
Lire le plan ne suffit pas à prouver ce qui se trouve dans le colis.
PyPI sait de mieux en mieux montrer le trajet du colis. L’étude de 2026 montre qu’il reste encore beaucoup de travail pour faire de la reconstruction du contenu une vérification banale plutôt qu’une opération de recherche.
Ce n’est pas une raison de moins faire confiance aux attestations.
C’est une raison de leur demander exactement la preuve qu’elles savent fournir, puis de construire la preuve suivante au lieu d’utiliser le même mot « confiance » pour toute la chaîne.