Every release, as it lands.

v0.1.1-rc.2 is the first signed release. v0.1.0 remains an unsigned test release. Check a download before you use it: put it beside the release's SHA256SUMS and run sha256sum -c --ignore-missing SHA256SUMS. On an unsigned release, that proves the bytes match. It does not prove who built them.

1. 3 October 2026: the first signed release

   v0.1.1-rc.2 is out, as a pre-release on Debian 13. It was built by the release build server from the signed tag v0.1.1-rc.2, then its SHA256SUMS was signed offline with the release key. It also ships build-provenance.json and SOURCES.md. Read how to verify it.

2. 3 October 2026: the portal is live

   The portal at build.blunix.io is open. The API at api.blunix.io answers. The build hosts on blnx.io serve the latest document for each label. Pinned version hosts are not on yet. Sign-in is After Dark Systems SSO. A release build server now builds official images from signed tags. The release signing key is published below. v0.1.1-rc.2 is the first signed release.

• The key. Blunix Release Signing, [email protected]. OpenPGP, ed25519. It expires on 1 October 2028. Download it from blunix.io/keys/blunix-releases.asc. The same file is keys/blunix-releases.asc in the source repository, so you can check one against the other.
• The fingerprint. 62F7 36BE A2AB 2E1F A16D 5138 BCB3 426C 090A DF92. Compare all of it. A short key ID is not enough.
• Step 1. Import the key: curl -fsSLO https://blunix.io/keys/blunix-releases.asc, then gpg --import blunix-releases.asc.
• Step 2. Check the signature: gpg --verify SHA256SUMS.asc SHA256SUMS. It must say the signature is good and name the fingerprint above. Anything else, stop.
• Step 3. Check the files: sha256sum -c --ignore-missing SHA256SUMS. Every file you downloaded must say OK.

v0.1.0 is an unsigned test release, so it has no SHA256SUMS.asc. For it, only step 3 applies. v0.1.1-rc.2 and later carry SHA256SUMS.asc.

• Signed tags only. The build server builds git tags of afterdarksys/blunix that are signed by the pinned release key. An unsigned or lightweight tag is refused.
• Pull only. It checks GitHub every 10 minutes. Nothing on the internet can connect to it, apart from restricted admin access.
• No keys on the build server. It holds no signing key. Its only credential can write to one staging bucket. Builds there expire after 30 days.
• Signed offline. The maintainer pulls a build from staging, checks it, signs SHA256SUMS with the release key, and publishes the GitHub release.

1. The log is the source

   A publisher appends a row through the API. An ordinary account key cannot. The public page is a rendering of those rows. An old row stays where it was written.

2. The manifest is generated

   systemd-sysupdate reads a manifest at the update URL. That file is produced from the current rows for the channel. Nobody edits it by hand.

3. Mirrors are caches

   A row can name more than one https mirror, and GitHub release assets are one of them. The machine checks the digest. A mismatch is refused, and the running image stays. The build is on the platform page.

4. The other slot boots

   The new image installs beside the one that is running, and the previous slot still boots. That is how the host lands on its feet.

5. A withdrawn version leaves the manifest

   Withdrawing appends a row. The old row remains, so you can see that it shipped and that it was pulled. A new boot does not select it.

• Next install. A new publish replaces what the next install from that label will decrypt. The build hosts are live.
• Already installed. Taking a new document on a running machine is the job of the service client, which is designed, not built.

The account that registers a label is on the account page. The routes are on the API page.