Supposons qu’une application soit téléchargeable sur sa page de versions et sur un miroir. Même nom de fichier, même numéro de version : il reste pourtant à savoir si les fichiers sont identiques, qui les publie, s’ils proviennent du code et du processus attendus, et s’ils conviennent à l’appareil de l’utilisateur.
Ces questions exigent des preuves différentes. Regrouper toutes les vérifications sous une « certification de sécurité » crée des attentes qu’elles ne peuvent satisfaire et risque de masquer les lacunes du processus de distribution.
La somme de contrôle vérifie la concordance des fichiers
Calculer un hachage après téléchargement et le comparer à la valeur attendue permet de vérifier le contenu du fichier. Encore faut-il que cette valeur provienne d’une source fiable. Si fichier et somme de contrôle viennent de la même page non vérifiée, leur concordance ne prouve pas l’identité de l’éditeur.
À l’inverse, une différence de hachage révèle des fichiers différents, sans suffire à établir une intention malveillante. Compilation distincte, reconditionnement ou mauvais téléchargement peuvent l’expliquer. Il faut cesser de considérer le fichier comme vérifié et reconfirmer sa source, sa plateforme cible et la somme correspondante.
Les éditeurs devraient maintenir ensemble noms explicites, versions et inventaire des sommes de contrôle. L’utilisateur ne devrait pas copier un hachage d’un ancien article pour le comparer à un installateur d’une autre plateforme ou compilation.
Une signature demande de vérifier l’identité attendue
La signature numérique associe un signataire aux données signées, mais la vérification doit aussi établir si cette identité est celle attendue. La documentation Sigstore demande de contrôler la signature ainsi que l’identité et l’émetteur pertinents, précisément pour cette raison. Documentation de vérification Sigstore
Devant « signature valide », l’utilisateur doit donc identifier l’éditeur ou le workflow correspondant ; le développeur doit préciser les identités autorisées à signer les versions officielles. Une signature mathématiquement vérifiable ne confère pas automatiquement ce statut.
Un changement de certificat ou de méthode de signature demande aussi une explication vérifiable. Faire accepter à la dernière minute un certificat d’origine inconnue n’est pas un processus de mise à jour complet.
La provenance relie le paquet à son processus de fabrication
Les attestations d’artefacts GitHub peuvent enregistrer la provenance de compilation et aider à vérifier les liens avec un dépôt ou un workflow. Elles apportent des preuves sur la production du fichier, mais il faut toujours vérifier l’artefact réel et l’identité attendue. Documentation des attestations GitHub
Les niveaux de compilation SLSA distinguent présence d’une provenance, provenance signée produite par une plateforme hébergée et protections plus strictes de la plateforme de compilation. Citer un niveau exige de préciser périmètre et justification, sans en faire une note couvrant tous les risques logiciels. Niveaux de compilation SLSA
| Preuve | Question principale | Ce qu’elle ne prouve pas seule |
|---|---|---|
| Somme de contrôle | A-t-on reçu le contenu attendu ? | Identité de l’éditeur ou comportement sûr |
| Signature numérique | Qui a signé quelles données ? | Adéquation du signataire à vos exigences de confiance |
| Attestation de provenance | Quel processus a produit l’artefact ? | Absence de problèmes dans tout le code et les dépendances |
| Compilation reproductible | Peut-on reconstruire le même artefact dans les conditions définies ? | Absence de vulnérabilités ou de comportements inappropriés |
Ces preuves se complètent. Le développeur devrait indiquer celles qu’il fournit et les vérifications restant à effectuer indépendamment.
La reproductibilité exige des entrées et un environnement explicites
Le projet Reproducible Builds définit une compilation reproductible comme la production d’artefacts spécifiés identiques octet par octet à partir du même code source, du même environnement et des mêmes instructions. C’est un objectif plus précis que « cela compile sur mon ordinateur ». Définition des compilations reproductibles
Nous conseillons de conserver chaîne d’outils, verrouillage des dépendances, paramètres et correspondance avec les artefacts. Si la reproductibilité n’est pas atteinte, décrire exactement jusqu’où la reconstruction fonctionne, au lieu d’omettre les différences pour annoncer un succès.
Le périmètre du dépôt public doit également être clair. Il peut contenir le code principal, ou surtout des outils, des configurations et des paquets générés en amont. L’utilisateur doit savoir ce qu’il peut effectivement examiner et reconstruire pour juger les preuves de provenance.
Un ordre de vérification pour l’utilisateur
- Confirmer le dépôt de distribution depuis l’entrée officielle du projet, sans dépendre seulement des publicités de recherche ou des liens transmis.
- Lire les notes de version et vérifier système, architecture du processeur et canal de publication.
- Comparer le fichier à sa somme de contrôle ; s’il existe une signature ou une attestation, vérifier aussi identité attendue et périmètre.
- Examiner maintenance et limitations connues, sans assimiler l’étiquette « latest » à un usage en production approprié.
- En cas d’incohérence, conserver version et nom du fichier, puis interroger le support du projet.
Ce parcours ne demande pas à chacun de devenir ingénieur de compilation. Le produit peut organiser les preuves dans une page claire : origine des fichiers, public visé, mode de vérification et interlocuteur en cas d’anomalie.
Pour le développeur, entretenir cette chaîne d’information dans le temps vaut davantage qu’un badge « vérifié » ponctuel. Les explications doivent rester accessibles lors du retrait d’une ancienne version, d’un changement de signature ou d’un échec de mise à jour.
La description publique du dépôt AlphaBiz distingue outils de compilation et paquets d’application produits en amont. Il faut expliquer ce périmètre réel sans confondre dépôt public, totalité du code source et distribution reproductible. Présentation du projet AlphaBiz
Les développeurs peuvent commencer par compléter un inventaire des preuves de distribution ; les utilisateurs, par examiner un téléchargement d’une application habituelle. Partagez les informations de vérification que vous aimeriez trouver sur les pages de versions dans AlphaBiz Discussions.