Sign the release assets, and keep the signing key in the repository

[moezdil]

Nothing on a release is signed. Someone who downloads siltide-linux-amd64 can compare it against checksums.txt, which is only as trustworthy as the page that served both.

A detached signature per asset, and a KEYS file at the repository root holding the current key and the retired ones so older releases stay verifiable, would let a download be verified against a key that came from this repository rather than a keyserver search, where anyone can upload a key under any name. The verify step then belongs in the install instructions, and a stable release should only go public once signing has succeeded.

[moezdil]

The workflow side of this is ready to take a key: releases now publish build-provenance attestations and SBOMs, and docs/INSTALL.md documents gh attestation verify. What is missing is the key itself, which is a decision rather than a change: a signing key has to be generated, kept somewhere it will still exist in two years, and its public half committed as KEYS. Once it is in the repository secrets the release job needs about ten lines to sign each asset and publish the .asc beside it.