Choose the question the receipt should answer
For a deployment check, the question may be whether the uploaded release matches the approved build. Store the receipt outside the release tree in a controlled CI artifact store, then verify the deployed or packaged specimen against it. If both the application and its plain receipt can be replaced together, a new matching inventory can conceal the change.
For a cross-team handoff, you may also need the receiver to know that a key holder authenticated the inventory. CloneGuard offers optional HMAC-SHA256 for that purpose. It is shared-key authentication, so every holder able to verify with the secret can also create a valid authenticated receipt.
Understand the inventory boundaries
The current manifest records regular-file paths, SHA-256 digests, sizes and executable bits. Verification detects added, missing and modified files relative to that record. Empty directories, ownership, access-control lists, extended attributes and independent creation times are outside its recorded inventory.
Preserve the exact final release after packaging and signing. Creating a receipt before a later native signing step can produce an expected mismatch because signing changes bytes. Likewise, copying Unix executable bits through a platform that does not preserve them can create a real inventory difference that needs explanation.
Test a failure before relying on the gate
Create a fixture receipt in a separate private path, verify the intact copy, then change a harmless test file and confirm verification fails. Repeat with a missing and an added file if those cases matter to deployment. Restore from the approved artifact instead of editing the receipt to make the test pass.
When authentication is required, pass the key explicitly to verification and keep unsigned receipts out of that path. CloneGuard rejects an unsigned manifest when a key is supplied, preventing a simple authentication downgrade. Retain the process exit status rather than interpreting a report file appearing as success.
Integrate with broader provenance when needed
A receipt is one component of a release record. Add source revision, build configuration, approval reference and native signature results in the surrounding CI system. If independent third parties must verify who published a release or when it existed, use the organization’s appropriate signing and timestamping process.
Do not use a newly created inventory as evidence that an idea or implementation existed before a competitor. The receipt establishes a relationship to the bytes presented to it, subject to the trust placed in its storage and authentication. That narrower statement is still valuable for reliable release operations.
Practical checklist
- Store receipts outside public release trees.
- Manifest after final packaging and signing.
- Test changed, added and missing files.
- Require a key when shared-key authentication is policy.
Sources and further reading
Primary references support the technical details. Procedures here are guidance; only explicitly recorded project results describe tests we ran.
Prepared with AI assistance. How this library is produced. Suggest a correction; keep private code and credentials out of public issues.