coulomb/railiance-clock
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Verify reproducible release artifacts and map acceptance evidence

Browse source 
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0e6f0-a6f6-7b93-9124-55ef584930e2
This commit is contained in:
tegwick 2026-09-28 10:22:52 +02:00
parent c976c9c277
commit c29bf39b5d
13 changed files with 577 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

62
docs/release-verification.md Normal file
View file

@ -0,0 +1,62 @@
# Local release verification
Run from this repository on Linux with Python 3.11+ and `uv`:
```sh
python3 tools/verify_release.py --output /tmp/rclk-release-UNIQUE
```
The output directory must not already exist. Temporary keys, virtual environments
and build trees are removed at exit. The output retains `verification.json` and
`runtime.cdx.json`; it does not publish or deploy a package. Package downloads may
require registry access. No production credentials or host clock changes are used.
The verifier performs:
1. Byte comparison of the three packaged JSON schemas against `specs/`.
2. A fresh build environment installed from hash-pinned
`tools/build-requirements.txt`, independently of runtime dependencies.
3. Two sdist/wheel builds from separate source roots with deliberately different
mtimes and fixed `SOURCE_DATE_EPOCH=315532800`. The sdist explicitly includes
source, project metadata and README; Hatchling also includes `.gitignore`.
All four are represented in the input manifest; generated evidence is excluded.
4. A build from the actual checkout, which must match both copied-source builds.
5. A fresh runtime environment installed from the hash-bearing locked runtime
requirements plus the built wheel, followed by `uv pip check`.
6. An isolated (`python -I`) smoke check outside the checkout: installed-package
import, schema presence, CLI startup, a signed HTTP exchange with a disposable
authority, wrong-key refusal, and sanitized CLI failure on unusable health.
7. Installed distribution/version comparison against `uv.lock` and a CycloneDX
runtime component inventory. Build dependencies are listed separately in the
receipt; neither development dependencies nor build tools enter the runtime.
Build constraints can be deliberately refreshed with:
```sh
uv pip compile tools/build-requirements.in --generate-hashes -o tools/build-requirements.txt
```
Review that diff and rerun verification after a refresh. Normal verification
uses the committed pins and does not resolve newer build versions. Runtime
installation similarly uses `uv export --locked` and verifies archive hashes.
## Retained evidence
The September 28 run is in
[evidence/2026-09-28-release/verification.json](evidence/2026-09-28-release/verification.json)
and its [runtime SBOM](evidence/2026-09-28-release/runtime.cdx.json).
The receipt records source-input hashes, lock/build-requirement hashes, verifier
hashes, Python/uv/build-tool versions, artifact digests and smoke checks. Its base
commit identifies the checkout before the verification changes were committed;
the input manifest identifies the exact built contents, including pending edits.
This demonstrates repeatability on the recorded Linux/Python toolchain. It does
not establish reproducibility on other platforms/interpreters, native UTC accuracy,
consumer admission, deployment, license clearance or absence of vulnerabilities.
The component inventory covers installed Python distributions, not system libraries
or native libraries embedded inside third-party wheels. Build timestamps are
normalized metadata and are never used as trusted time.
The [acceptance coverage map](acceptance-coverage.md) distinguishes local checks
from unproven native obligations. RCLK-WP-0003-T03 owns this package evidence;
existing 0002/0004/0005 records retain owner acceptance and deployment gates.