Make archive bytes reproducible from the same source manifest
Two builds from identical fixtures differ because archive order, timestamps, ownership, and path separators come from the host.
- Focused work estimate
- 1h 30m + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- Reproducible builds · Archive safety
Estimated field mix
- DevOps70%
- Security30%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A fictional command-line product publishes local package archives. Builds contain timestamps, checksums are copied without provenance, and cleanup can delete the only rollback artifact. Use generated source trees, ephemeral development signing keys, and local object storage; no public registry or production key is supplied.
Setup prerequisites
- Content hashing
- Archive formats
- Release metadata
Preceding work
No earlier ticket is required. Complete the project setup above.
Acceptance criteria
- Sort entries by canonical relative path
- Normalize declared timestamps, ownership, permissions, and separators
- Reject paths escaping or colliding after normalization
Implementation constraints
- Use generated files only and do not archive the repository working tree.
Verification to include
- Build twice in different temporary roots and compare byte digests.
- Add traversal and normalization-collision paths and confirm rejection.
Deliverables
- Deterministic archive writer and reproducibility tests
Rollout and recovery
Publish reproducibility metadata before replacing the current archive path.
Value of the work
For the engineer: Practice reproducible artifacts, provenance validation, signing-key isolation and retention safety.
For the team: Review a supply path that can trace, verify, retain, and revoke artifacts without relying on mutable names.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.