mirror of
https://github.com/wownero/wowlet.git
synced 2026-11-01 21:53:54 +01:00
42 lines
2.9 KiB
Markdown
42 lines
2.9 KiB
Markdown
# Wowlet release process
|
|
|
|
GitHub `wownero/wowlet` owns source and public releases. Private `Builds/wowlet`
|
|
is the build ingress on our hardware. Fleet owns dispatch and publication plans.
|
|
A source merge, a build, a code signature and a published release are separate outcomes.
|
|
|
|
1. Prepare and review a GitHub pull request with the version, wallet-library pin,
|
|
support documentation and release inputs. Publish a new library commit to its
|
|
canonical repository before pinning it. Keep source and dependency revisions exact.
|
|
2. `make check` runs the cheap source checks. Run the private Linux, Windows and
|
|
macOS workflows through reviewed Fleet admission with `expected_sha` equal to
|
|
the protected Builds commit. Preserve canonical source and Builds commit identities
|
|
separately. Do not run release builds on GitHub.
|
|
3. The build helpers verify embedded Wownero archives against `contrib/release/wownerod.json`.
|
|
That file records the reviewed checksum provenance. Do not describe an unsigned
|
|
checksum list as a PGP verification.
|
|
4. Collect artifacts by their run and artifact identities. Require a Linux AppImage,
|
|
macOS archive, signed Windows archive and unsigned Windows archive. Check archive
|
|
paths, bundled runtimes and packaging requirements. Never select an artifact by size.
|
|
5. Require Developer ID signing, accepted notarization and stapling for macOS.
|
|
Require valid, timestamped Such Software LLC Authenticode signing for Windows.
|
|
The EV token stays on its signing host; CI never receives its password or key.
|
|
6. Record any manual wallet checks actually performed. Manual testing and independent
|
|
reproducibility are separate evidence; successful builds do not prove either.
|
|
The unsigned Windows archive is provided for reproduction, without claiming an
|
|
independent reproduction occurred.
|
|
7. Create `hashes.txt` over the four final archives. Sign it on the owner's signing
|
|
machine with the existing release key `9F9930300530DF724761B7055A881347310EB79F`.
|
|
Verify the detached signature and all hashes before publication. Never transfer
|
|
the private key or put a passphrase in a command, environment or log.
|
|
8. Create an annotated `vX.Y.Z` tag from the exact reviewed canonical source, matching
|
|
`CMakeLists.txt`. Use Fleet's reviewed publication plan to upload the four archives,
|
|
`hashes.txt` and `hashes.txt.asc` to GitHub Releases. Refuse replacement of existing
|
|
tags or assets; recover partial publication from retained intent.
|
|
9. Download the public assets again and verify their hashes and PGP signature. Record
|
|
the tag, source commit, Builds commit, run identities, signing evidence and public
|
|
URL in the private journal. Release notes should say when security fixes are included.
|
|
|
|
Additional architectures and Guix builds remain separate lanes. Do not claim a
|
|
platform is released merely because its workflow exists. Announcements are an
|
|
owner action, separate from publishing the release files.
|