Lab Objective

Practice the security checks behind delivering a task artifact safely:

  • limit a link to one intended artifact
  • verify integrity with SHA-256 before delivery
  • reject forged, expired, or revoked links
  • distinguish an attempted delivery from a confirmed one
  • prove a restart does not produce duplicate messages

Lab Environment

  • System: local macOS workstation
  • Component: feature-gated supervisor artifact-delivery service
  • Controls: token hash storage, seven-day link expiry, revocation, byte hashing, size limit, durable delivery ledger
  • Tools: Python test suite, shasum, cmp, loopback HTTP fixture
  • Safety boundary: fixtures only; no production listener or live delivery channel was enabled

Scenario

A completed task produces a report. The recipient needs that report, but should not receive access to a directory, backup set, logs, or future artifacts. The delivery channel can also fail halfway through: the sender may crash after attempting a send but before recording confirmation.

Step 1 - Record the Artifact as Evidence

Calculate the expected digest before a link is created.

shasum -a 256 report.pdf
stat -f "%z bytes" report.pdf

The real service stored the artifact’s size and SHA-256 digest, then recorded only a hash of the delivery token. The token itself was never retained as a database value.

Step 2 - Request the Narrow Link

Use a placeholder token in documentation and tests; never paste real access tokens into a handoff or blog post.

curl -i "http://127.0.0.1:8080/artifact/<single-artifact-token>"

The valid path should return only the linked file. A path to logs, backups, or an arbitrary filename should not exist.

Step 3 - Verify the Received Bytes

Save the served file and compare both digest and content.

shasum -a 256 report.pdf downloaded-report.pdf
cmp -s report.pdf downloaded-report.pdf && echo "byte-identical"

The delivery service also re-hashed the file immediately before serving it. If the registered file changed, the request failed closed.

Step 4 - Test Rejection Cases

Exercise the cases that should be denied:

curl -i "http://127.0.0.1:8080/artifact/forged-token"
# advance fixture time beyond the link expiry, then repeat
# revoke the link in the fixture, then repeat

The completed test run rejected forged, expired, and revoked links. Expiry revoked access without deleting the source artifact, preserving it for audit and retention rules.

Step 5 - Test Recovery Without Duplicate Delivery

Simulate a crash after the send attempt, then restart the delivery worker against the same durable ledger. The recovery path must inspect the destination state before retrying.

The completed two-process test confirmed byte-identical retrieval in a fresh process and zero duplicate file messages after repeated and crash-recovered delivery attempts.

Security Takeaways

  1. Authorization should be object-scoped. A link to one report is safer than broad storage access.
  2. Integrity must be checked at use time. Hashing only during upload does not detect later tampering.
  3. Expiry and retention are different. Revoking access must not automatically destroy evidence.
  4. Delivery needs confirmation. “Sent” is not the same as “received once.”
  5. Recover from durable evidence. A retry without inspection can turn a crash into duplicate disclosure.

Where This Applies Beyond This Lab

The same controls apply to incident-report delivery, customer exports, signed build artifacts, secure download portals, and cloud-storage sharing. The details vary, but the questions stay the same: who can access what, for how long, has it changed, and can recovery repeat the action safely?