Skip to content
Bitcoin Roots

v31.1-roots.1 · Commit 8: [PATCH 08/17] chore(roots): integrate v31 identity and maintenance tooling

ci/release/README.md

Before: /dev/null · After: ci/release/README.md

File metadata
new file mode 100644
index 0000000000000000000000000000000000000000..de2734ed06b2b17512ed10fe46ecedada1e1089b

Download original patch · Release notes

Diff rows 1–128 of 128. Line numbers refer to the original before/after files.

+ Added− RemovedUnmarked lines are context.

Scroll the code area horizontally to read long lines. Before is on the left; after is on the right. Unified view fits narrow screens more easily.

ci/release/README.md ADDED
@@ -0,0 +1,128 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # Release assembly and optional notice tooling
2
+
3
+ `release.yml` runs the five-platform pipeline on a permanent Roots tag push;
4
+ optional manual dispatch rehearses an absent future tag with read-only
5
+ permissions. The normal release builds once on the tag push, signs/creates a
6
+ draft and independently verifies it before separate publication approval.
7
+ Manual rehearsal is not required, cannot run against an existing remote tag,
8
+ and does not establish binary reproducibility. Source corrections require
9
+ renewed review/CI and affected build evidence.
10
+ Both paths preserve existing project license files and stage canonical `COPYING`
11
+ before packaging. The user deferred expanded dependency copyright/REUSE
12
+ coverage to future releases; the default release does not require dependency
13
+ notice collection or its index schema. No complete coverage claim is made.
14
+ Only the tag path enters the `release` environment and requires a signed
15
+ manifest before creating a new draft. Public publication needs separate approval.
16
+ Unsafe or unassembled packages fail before upload or final preparation. No
17
+ prior binary is substituted for a fresh build.
18
+
19
+ ## Optional dependency notice tooling
20
+
21
+ The following interface remains available for future coverage work. It is not
22
+ a prerequisite for this release's CI pipeline or draft validation.
23
+
24
+ The supported assembly interface uses explicitly reviewed inputs:
25
+
26
+ 1. Prepare a descriptor for each platform from retained build logs, binary
27
+ version metadata, dependency recipes or package metadata. Preserve source
28
+ notice bytes and identify the exact version, primary origin, source hash and
29
+ evidence. The descriptor is a JSON object keyed by component. Each entry has
30
+ `version`, `source`, `source_sha256`, `provenance_type`, `evidence`, `files`,
31
+ and optionally `role`. Paths in `evidence` and `files` are absolute or relative
32
+ to the descriptor. `build-receipt` entries can instead supply `receipt`;
33
+ their source hash defaults to the receipt hash. Independent provenance can
34
+ use `pinned-source-archive` or `versioned-primary-notice` without an old runner
35
+ receipt. `source-version-stability` keeps `version` as `unknown` and records
36
+ `notice_stable_versions` only when authoritative notice bytes are identical
37
+ across the reviewed range. A source hash means the source archive hash for
38
+ archive provenance, or the primary notice-source record digest for notice
39
+ provenance; retained evidence identifies which and includes notice hashes.
40
+ 2. Collect the reviewed inputs into a new directory:
41
+
42
+ ```sh
43
+ python3 ci/release/notices.py collect linux-x86_64 descriptor.json notice-inputs
44
+ ```
45
+
46
+ The collector adds tracked component licenses and embedded font attribution,
47
+ retains provenance and builds a hashed index. Conservative source-availability
48
+ notices should be labeled with `role`; they do not establish actual linkage.
49
+ 3. Add notices to a new package without modifying existing members:
50
+
51
+ ```sh
52
+ python3 ci/release/repack.py intermediate.tar.gz assembled.tar.gz \
53
+ bitcoin-roots-30.3-roots.1 notice-inputs/index.json linux-x86_64
54
+ ```
55
+
56
+ The repacker adds canonical `COPYING` and `notices/` at the archive root,
57
+ outside signed applications. It preserves every existing member's bytes,
58
+ modes, timestamps and symlink contents. Existing destinations, including
59
+ dangling symlinks, are refused. An existing regular COPYING must match
60
+ canonical bytes and is preserved as an original member; COPYING is added
61
+ only when missing. Altered/nonregular COPYING or an existing notices tree
62
+ is refused. Use the package's original release filename
63
+ when placing the result in the final download directory.
64
+ 4. Validate all five assembled packages with their matching portable patch:
65
+
66
+ ```sh
67
+ ci/release/prepare-release.sh assembled-downloads release-assets \
68
+ contrib/release/bitcoin-roots-release-key.asc v31.1-roots.1 5
69
+ ```
70
+
71
+ This final gate derives each expected platform from its exact asset filename,
72
+ requires canonical `COPYING` and archive safety, and validates every package
73
+ before copying assets or creating `SHA512SUMS`. Dependency indexes are not
74
+ required by this gate. `notices.py validate ARCHIVE ROOT PLATFORM` and
75
+ `notices.py stage DIRECTORY INDEX PLATFORM` expose the same caller-pinned
76
+ validation for explicit assembly.
77
+
78
+ Retain the original build run/source identity when repacking. A packaging-only
79
+ source correction requires a reviewed source/portable-patch reconciliation;
80
+ it does not turn an old run into a build of the new commit. Signing, permanent
81
+ tagging and publication remain separate reviewed actions. These checks verify
82
+ notice contents and provenance, not general legal compliance.
83
+
84
+ ## Optional runner collection
85
+
86
+ `runner-notices.py` can feed the descriptor/collection format above for future
87
+ coverage work. It is not invoked by the current release workflow:
88
+
89
+ - Linux runs inside the build container after the new build, while installed
90
+ `depends` toolchains/recipes and verified source archives remain available.
91
+ The notice tree persists into the mounted build directory. Both architectures
92
+ independently capture selected packages and Qt's additional source archives.
93
+ - macOS captures matching installed Homebrew formula receipts and verified
94
+ source hashes for required dependencies and any extra Qt modules proven in
95
+ the built bundle. Qt's non-archive umbrella and unrelated CA/tool formulas
96
+ are excluded. Bundle hashes/`otool` records prove system SQLite linkage.
97
+ - Windows captures the actual `build/vcpkg_installed` status and static-triplet
98
+ copyrights. Boost split ports form one logical Boost notice with every exact
99
+ installed version/copyright; the pinned manifest baseline remains evidence.
100
+
101
+ ## Signed CI draft
102
+
103
+ The platform archive and canonical COPYING are validated before upload.
104
+ The tag-only final job downloads only its own run's five archives and patch,
105
+ runs `prepare-release.sh`, and requires signing through `sign-manifest.sh` with
106
+ `REQUIRE_RELEASE_SIGNATURE=1`. The real secret is passed only to that step;
107
+ never copy it to local tooling or build jobs. A missing/mismatched key fails.
108
+
109
+ `create-ci-draft.py` requires exactly eight regular nonempty assets. It reuses
110
+ the packet/source/archive/COPYING/patch replay guards, independently imports only the
111
+ checked-in public key and verifies `SHA512SUMS.asc` with the expected fingerprint.
112
+ It snapshots the checked bytes and curated notes, refreshes remote tag/canonical
113
+ identities and paginated release inventory, then calls only
114
+ `gh release create --draft --verify-tag`. Any existing draft/public release or
115
+ network ambiguity fails closed; no clobber/update/deletion/replacement exists.
116
+ The notes add the actual fresh build run/source and distinguish manifest, Git
117
+ and platform signatures. `contrib/release/release-notes.md` is the reviewed
118
+ curated template, including #24/#25 contributor credit.
119
+
120
+ The older `create-draft.py` remains a validation/unsigned-packet utility and
121
+ shares its fail-closed guards with the signed CI path. It is not the normal
122
+ release publication route. Never use it to bypass required CI signing.
123
+
124
+ Download all eight draft assets independently and check the manifest signature,
125
+ six asset checksums, archive safety/COPYING, immutable source/tag, patch replay and
126
+ notes before visibility-only publication under separate authority. Repeat the
127
+ consumer checks unauthenticated after publication. Interrupted creation needs
128
+ operator inspection of the partial draft; reruns cannot replace it.