Introduction
Waymark publie un guide de promenades pour un festival. Un fournisseur a livré plusieurs colis de mise à jour. Votre mission consiste à accepter la version demandée par l'organisateur, sans faire confiance à un colis simplement parce que sa somme de contrôle correspond.
Vous utiliserez une clé publique d'éditeur fournie indépendamment, vérifierez une véritable signature avec Cosign, comparerez le produit et la version demandés, puis contrôlerez l'empreinte de l'archive. Des connaissances de base du terminal et des chemins suffisent ; aucun compte cloud ni programmation n'est nécessaire. Ce TP sert à sélectionner une mise à jour. Le TP guidé suivant transforme ces décisions en un programme de réception réutilisable.
Commencer par le guide du festival et la demande de mise à jour
Dans cette étape, vous découvrirez le service en fonctionnement et trouverez la demande de l'organisateur avant de choisir une mise à jour. Ouvrez l'onglet Event Guide. L'édition actuelle de event-guide est 2.0. Ouvrez Old Mill Walk : le rendez-vous est à 11:00. Utilisez le lien All walks de la page pour revenir, puis téléchargez la fiche des itinéraires. Le site et le CSV décrivent les deux mêmes promenades.
La page d'accueil du guide indique l'édition au-dessus du titre et affiche l'heure de rendez-vous sur la carte de chaque promenade :
Passez maintenant à Workspace. Ce terminal partage le même conteneur que le guide ; les onglets sont des entrées différentes, pas des machines différentes. cd change le répertoire courant du terminal. Le chemin absolu fonctionne depuis n'importe quel répertoire :
cd /home/labex/project/waymark
cat affiche un petit fichier texte. Lisez la demande fournie par l'organisateur indépendamment des colis livrés :
cat /opt/labex-waymark/trust/request.json
L'objet JSON comporte deux champs nommés :
{
"product": "event-guide",
"version": "2.1"
}
Un produit identifie le guide à mettre à jour ; une version identifie l'édition demandée. Une édition antérieure authentique n'est pas cette mise à jour. La clé publique approuvée indépendamment est /opt/labex-waymark/trust/publisher.pub. Conservez cette clé et la demande sans les modifier.
ls liste les entrées d'un répertoire. Examinez le répertoire de livraison :
ls candidates
Les colis portent des étiquettes de livraison comme parcel-101 ; leur nom ne prouve aucune approbation. Chacun contient manifest.json, manifest.sigstore.json, guide.tar.gz et SHA256SUMS. Le manifeste décrit le produit, la version et l'empreinte de l'archive. Le bundle contient une signature. L'archive contient les véritables fichiers du guide. Gardez intacts les colis d'origine, le guide actuel, les versions précédentes et l'avis aux visiteurs. Vous placerez une copie du colis choisi dans accepted/.
Si une commande indique No such file or directory, exécutez le cd absolu ci-dessus, utilisez ls candidates pour vérifier l'orthographe et réessayez. Rien dans ce TP ne nécessite une réinitialisation.
Comprendre ce qu'indique une somme de contrôle concordante
Dans cette étape, vous comparerez deux colis qui réussissent tous deux la vérification de leur somme de contrôle jointe. Restez dans Workspace.
Une empreinte SHA-256 est calculée à partir des octets d'un fichier. Des empreintes identiques aident à détecter les modifications d'octets, à condition que l'empreinte attendue soit elle-même fiable. sha256sum -c lit une liste de sommes de contrôle et compare les fichiers indiqués à cette liste. Ici, -c signifie « vérifier ». Exécutez la commande à l'intérieur du colis, car la liste utilise un nom de fichier relatif :
cd candidates/parcel-103
sha256sum -c SHA256SUMS
Vous devez obtenir guide.tar.gz: OK. Revenez au projet et essayez un autre colis :
cd /home/labex/project/waymark/candidates/parcel-104
sha256sum -c SHA256SUMS
Vous devez à nouveau obtenir guide.tar.gz: OK. Les deux listes ont été livrées avec leurs archives. Une personne ayant remplacé une archive pourrait également calculer une nouvelle somme de contrôle jointe. OK établit la concordance entre ces deux fichiers ; il n'identifie pas leur éditeur et ne prouve pas qu'il s'agit de la mise à jour demandée.
Revenez au projet :
cd /home/labex/project/waymark
Vous vérifierez ensuite le manifeste à l'aide de la clé publique déjà approuvée par l'organisateur. L'empreinte attendue de l'archive proviendra alors de ce manifeste vérifié, plutôt que de la liste jointe non signée.
Vérifier l'éditeur avec une clé publique indépendante
Dans cette étape, vous distinguerez une signature authentique d'une signature réalisée avec une clé non approuvée. Commencez dans Workspace, dans /home/labex/project/waymark.
Un éditeur signe un fichier avec une clé privée. La clé publique correspondante permet au destinataire de vérifier cette signature et de détecter les modifications du fichier signé. La clé publique doit parvenir par un canal auquel vous faites déjà confiance. Un colis ne peut pas approuver sa propre clé. Cet exercice fixe une clé d'éditeur synthétique fournie séparément dans /opt/labex-waymark/trust/ ; la clé privée de l'éditeur ne vous est pas fournie.
Cosign est l'outil de signature préparé. verify-blob vérifie un fichier ; --key sélectionne la clé publique de confiance ; --bundle sélectionne le bundle de signature. Le dernier argument nomme précisément le manifeste dont les octets sont signés.
Ces colis synthétiques ont été signés sans journal public de transparence. --insecure-ignore-tlog omet volontairement la vérification de l'inclusion dans ce journal. Une signature valide avec la clé sélectionnée reste nécessaire. Cet exercice local ne vérifie ni identité OIDC publique, ni service de certificats, ni journal de transparence ; ne recopiez pas cette exception dans une politique exigeant ces services.
Le colis suivant est signé avec une autre clé. Cette vérification doit échouer, avec un code de sortie non nul et une erreur de vérification de signature :
/opt/labex-waymark/bin/cosign verify-blob --key /opt/labex-waymark/trust/publisher.pub --bundle candidates/parcel-102/manifest.sigstore.json --insecure-ignore-tlog candidates/parcel-102/manifest.json
echo affiche une valeur ; $? est le code de sortie de la commande immédiatement précédente. Zéro signifie une réussite et un nombre non nul un échec. Vérifiez-le immédiatement :
echo $?
Vérifiez maintenant un colis signé par l'éditeur dont la clé est fixée :
/opt/labex-waymark/bin/cosign verify-blob --key /opt/labex-waymark/trust/publisher.pub --bundle candidates/parcel-104/manifest.sigstore.json --insecure-ignore-tlog candidates/parcel-104/manifest.json
Vous devez voir l'avertissement sur le journal de transparence et Verified OK :
WARNING: Skipping tlog verification is an insecure practice that lacks transparency and auditability verification for the blob.
Verified OK
Vérifiez le code de sortie immédiatement précédent :
echo $?
Le résultat attendu est 0. Le manifeste est signé avec la clé de confiance. C'est une première décision ; il reste à vérifier ce que le manifeste autorise.
Vérifier le produit, la version et l'empreinte d'archive signés
Dans cette étape, vous utiliserez le manifeste vérifié pour déterminer si un colis authentique correspond à la version demandée. Restez dans Workspace.
Vérifiez d'abord une version antérieure authentique. Cette commande doit réussir :
/opt/labex-waymark/bin/cosign verify-blob --key /opt/labex-waymark/trust/publisher.pub --bundle candidates/parcel-101/manifest.sigstore.json --insecure-ignore-tlog candidates/parcel-101/manifest.json
jq lit du JSON. Le filtre .product, .version affiche les deux champs nommés. Les apostrophes conservent le filtre en un seul argument, sans laisser le shell interpréter sa ponctuation :
jq '.product, .version' candidates/parcel-101/manifest.json
Vous devez obtenir "event-guide" et "2.0". Ce guide est authentique, mais ce n'est pas la version 2.1 demandée. Une signature ne rend pas automatiquement appropriée une ancienne version.
Examinez le candidat vérifié à l'étape précédente :
cat candidates/parcel-104/manifest.json
Son produit et sa version correspondent à la demande indépendante. Le champ sha256 est l'empreinte hexadécimale à 64 caractères de guide.tar.gz ; ne l'apprenez pas par cœur. jq -r affiche un champ sans guillemets JSON. Affichez cette empreinte attendue :
jq -r .sha256 candidates/parcel-104/manifest.json
Calculez maintenant l'empreinte réelle de l'archive :
sha256sum candidates/parcel-104/guide.tar.gz
Le premier champ doit correspondre à l'empreinte du manifeste vérifié. Le nom de fichier affiché ensuite ne fait pas partie de l'empreinte.
L'archive modifiée examinée précédemment possède elle aussi un manifeste signé authentique, mais ses octets actuels ne correspondent plus à ce manifeste. Confirmez-le en vérifiant son manifeste, puis en comparant les deux empreintes :
/opt/labex-waymark/bin/cosign verify-blob --key /opt/labex-waymark/trust/publisher.pub --bundle candidates/parcel-103/manifest.sigstore.json --insecure-ignore-tlog candidates/parcel-103/manifest.json
jq -r .sha256 candidates/parcel-103/manifest.json
sha256sum candidates/parcel-103/guide.tar.gz
La signature est valide, mais les empreintes diffèrent. Refusez ce colis. Vous disposez désormais de trois décisions distinctes : signataire de confiance, produit/version demandés et octets d'archive concordants. L'échec d'une seule de ces vérifications signifie que la mise à jour n'est pas prête à être acceptée.
Accepter le colis demandé sans modifier le guide en service
Dans cette étape, vous enregistrerez le colis demandé et vérifié pour le transmettre. Commencez dans Workspace, dans /home/labex/project/waymark.
accepted/ existe déjà. cp copie des fichiers ; le dernier argument est le répertoire de destination. Copiez le manifeste, le bundle de signature et l'archive que vous avez vérifiés :
cp candidates/parcel-104/manifest.json candidates/parcel-104/manifest.sigstore.json candidates/parcel-104/guide.tar.gz accepted/
La copie produit un ensemble de fichiers distinct. Vérifiez cet ensemble, sans supposer qu'une vérification antérieure s'applique à une copie ultérieure :
/opt/labex-waymark/bin/cosign verify-blob --key /opt/labex-waymark/trust/publisher.pub --bundle accepted/manifest.sigstore.json --insecure-ignore-tlog accepted/manifest.json
jq '.product, .version' accepted/manifest.json
jq -r .sha256 accepted/manifest.json
sha256sum accepted/guide.tar.gz
Vous devez obtenir une signature valide, event-guide, 2.1 et des empreintes d'archive concordantes. L'autocontrôle préparé en lecture seule utilise ces fichiers réels, la clé et la demande indépendantes, ainsi que le contenu attendu du guide :
python3 /opt/labex-waymark/verify.py selected
Résultat attendu :
The accepted parcel is the independently signed, requested release with matching archive bytes.
En cas d'échec, identifiez laquelle des trois décisions a échoué, puis recommencez la copie depuis le bon colis d'origine et vérifiez à nouveau la copie. Ne modifiez pas les fichiers de confiance indépendants. Le contrôle ne choisit pas de colis à votre place et ne le déploie pas.
Passez à Event Guide et actualisez la page. Elle doit toujours afficher l'édition 2.0, et Old Mill Walk doit toujours prévoir le rendez-vous à 11:00. Ouvrez Visitor notice et confirmez que les conseils pratiques d'origine sont toujours présents. Cette unité accepte une livraison à transmettre ; la publication de la mise à jour est une opération distincte enseignée ensuite.
Résumé
Vous avez accepté une livraison réellement signée en combinant une clé d'éditeur approuvée indépendamment, la demande de produit et de version de l'organisateur, et l'empreinte de l'archive réelle. Vous avez aussi constaté pourquoi une somme de contrôle jointe, une signature valide sur une ancienne version ou un manifeste signé accompagné d'octets modifiés ne suffit pas à lui seul.
Le guide actuel reste disponible. Dans le prochain TP guidé, vous intégrerez ces décisions à un programme de réception réutilisable et veillerez à ce que seuls les octets vérifiés de l'archive atteignent le guide en service.
