Introduction
Waymark publishes a walking festival guide. A supplier has delivered several update parcels. Your job is to accept the release the organizer requested without trusting a parcel merely because its checksum matches.
You will use an independently provided publisher public key, verify a real signature with Cosign, compare the requested product and version, and check the archive digest. You need basic terminal and path skills; no programming or cloud account is required. This lab selects an update. The next guided lab turns these decisions into a reusable receiver.
Start with the Festival Guide and Update Request
In this step, you will see the working service and find the organizer's request before choosing an update. Open the Event Guide tab. The current event-guide edition is 2.0. Open Old Mill Walk: it meets at 11:00. Use the page's All walks link to return, then download the route sheet. The website and CSV describe the same two walks.
The guide home page identifies the edition above the heading and shows each walk’s meeting time on its card:
Now switch to Workspace. This terminal shares the same container as the guide; the tabs are different entrances, not different machines. cd changes the terminal's current directory. The absolute path works from any directory:
cd /home/labex/project/waymark
cat prints a small text file. Read the request supplied by the organizer independently of the delivery parcels:
cat /opt/labex-waymark/trust/request.json
The JSON object has two named fields:
{
"product": "event-guide",
"version": "2.1"
}
A product identifies which guide is being updated; a version identifies the requested edition. A genuine earlier edition is not this update. The independently pinned public key is /opt/labex-waymark/trust/publisher.pub. Keep that key and request unchanged.
ls lists directory entries. Inspect the delivery directory:
ls candidates
The parcels have delivery labels such as parcel-101; their names are not approval evidence. Each contains manifest.json, manifest.sigstore.json, guide.tar.gz, and SHA256SUMS. The manifest describes the product, version and archive digest. The bundle holds a signature. The archive holds the actual guide files. Keep the original parcels, current guide, previous releases and visitor notice intact. You will put a copy of your selected parcel into accepted/.
If a command reports No such file or directory, run the absolute cd command above, use ls candidates to check spelling, and retry. Nothing in this lab needs a reset.
Learn What a Matching Checksum Can Tell You
In this step, you will compare two parcels that both pass their adjacent checksum. Stay in Workspace.
A SHA-256 digest is a fingerprint calculated from file bytes. Matching fingerprints help detect byte changes, provided the expected fingerprint itself is trusted. sha256sum -c reads a checksum list and compares the named files against it. Here, -c means “check.” Run it inside the parcel because the list uses a relative filename:
cd candidates/parcel-103
sha256sum -c SHA256SUMS
Expect guide.tar.gz: OK. Return to the project and try another parcel:
cd /home/labex/project/waymark/candidates/parcel-104
sha256sum -c SHA256SUMS
Again, expect guide.tar.gz: OK. Both lists came in the same delivery as their archives. Someone who replaced an archive could also calculate a new adjacent checksum. OK establishes agreement between those two files; it does not identify their publisher or establish that this is the requested update.
Return to the project:
cd /home/labex/project/waymark
Next, you will verify the manifest against the public key the organizer already trusts. The archive's expected digest will then come from that verified manifest, rather than from the unsigned adjacent list.
Verify the Publisher with an Independent Public Key
In this step, you will distinguish a real signature from a signature made by an unapproved key. Start in Workspace, in /home/labex/project/waymark.
A publisher signs a file with a private key. A corresponding public key lets a recipient verify that signature and detect changes to the signed file. The public key must arrive through a channel you already trust. A parcel cannot approve its own key. This exercise pins a synthetic publisher key supplied separately under /opt/labex-waymark/trust/; the publisher's private key is not supplied to you.
Cosign is the prepared signature tool. verify-blob verifies a file; --key selects the trusted public key; --bundle selects the signature bundle. The last argument names the exact manifest whose bytes are signed.
These synthetic parcels were signed without a public transparency log. --insecure-ignore-tlog deliberately skips log-inclusion verification. It still requires a valid signature under the selected key. This local exercise does not verify a public OIDC identity, certificate service or transparency log; do not copy this exception into a policy that requires those services.
The following parcel is signed by a different key. Expect this verification to fail with a nonzero exit status and a signature-verification error:
/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 prints a value; $? is the exit status of the immediately preceding command. Zero means success and a nonzero number means failure. Check it immediately:
echo $?
Now verify a parcel signed by the pinned publisher:
/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
Expect the transparency-log warning and Verified OK:
WARNING: Skipping tlog verification is an insecure practice that lacks transparency and auditability verification for the blob.
Verified OK
Check the immediately preceding status:
echo $?
Expect 0. The manifest is signed by the trusted key. That is one decision; you still need to check what the manifest authorizes.
Check the Signed Product, Version and Archive Digest
In this step, you will use the verified manifest to decide whether a genuine parcel is the requested release. Stay in Workspace.
First verify an earlier genuine release. This command is expected to succeed:
/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 reads JSON. The filter .product, .version prints the two named fields. Single quotes preserve the filter as one argument rather than letting the shell interpret its punctuation:
jq '.product, .version' candidates/parcel-101/manifest.json
Expect "event-guide" and "2.0". This is a genuine guide but not the requested 2.1. A signature does not automatically make an old release appropriate.
Inspect the verified candidate from the previous step:
cat candidates/parcel-104/manifest.json
Its product and version match the independent request. The sha256 field is a 64-character hexadecimal digest of guide.tar.gz; do not memorize it. jq -r prints a field without JSON quote marks. Print that expected digest:
jq -r .sha256 candidates/parcel-104/manifest.json
Now calculate the actual archive digest:
sha256sum candidates/parcel-104/guide.tar.gz
The first field must match the digest from the verified manifest. The filename printed after it is not part of the digest.
The changed archive you inspected earlier also has a genuine signed manifest, but its current bytes no longer match that manifest. Confirm this by verifying its manifest, then comparing the two digests:
/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
The signature passes but the digests differ. Reject this parcel. You now have three separate decisions: trusted signer, requested product/version, and matching archive bytes. A failure in any one means the update is not ready to accept.
Accept the Requested Parcel without Changing the Live Guide
In this step, you will save the verified requested parcel for handover. Start in Workspace, in /home/labex/project/waymark.
accepted/ already exists. cp copies files; the last argument is the destination directory. Copy the manifest, signature bundle and archive you verified:
cp candidates/parcel-104/manifest.json candidates/parcel-104/manifest.sigstore.json candidates/parcel-104/guide.tar.gz accepted/
Copying gives you a separate set of files. Verify that set, rather than assuming a previous verification applies to a later copy:
/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
Expect a valid signature, event-guide, 2.1, and matching archive digests. The prepared read-only self-check uses those actual files, the independent key/request, and the expected guide contents:
python3 /opt/labex-waymark/verify.py selected
Expect:
The accepted parcel is the independently signed, requested release with matching archive bytes.
If it fails, check which of the three decisions failed, then repeat the copy from the correct original parcel and verify the copy again. Keep the independent trust files unchanged. The check neither selects a parcel for you nor deploys it.
Switch to Event Guide and refresh the page. It should still show edition 2.0, and Old Mill Walk should still meet at 11:00. Open Visitor notice and confirm the original practical advice remains. This unit accepts a delivery for handover; publishing the update is a separate operation taught next.
Summary
You accepted a real signed delivery by combining an independently trusted publisher key, the organizer's product/version request, and the digest of the actual archive. You also saw why an adjacent checksum, a valid signature on an old release, or a signed manifest beside changed bytes is insufficient alone.
The current guide remains available. In the next guided lab, you will make these decisions part of a reusable receiver and ensure only the verified archive bytes reach the running guide.
