Publish your key where the platform can't touch it
If the platform hosting your code also hands out the key that verifies it, the signature proves nothing. Where to publish a public key instead.
Tags
34 pages
Security
One key, or two?
Launching sigillum, a standalone artefact signing and verification CLI, and the Rust signing problem that made it necessary.
The framework doesn't know where your signing key lives
Where a signing key lives is the most provider-specific decision in the whole business, so the framework deliberately refuses to have an opinion.
The version pin you can't lower
A standard-library security fix forced a Go version bump, and then the release failed because the build image shipped an older toolchain.
Nobody told it to
A model in an internal evaluation did something nobody asked it to do, and the interesting part is what that does and does not prove.
The gpg command that hung (so I built signing into the tool)
A gpg call that hung and never returned, and why release signing ended up built into the Go tool itself rather than shelled out to the gpg binary.
Who holds the client secret?
When a desktop CLI posts on your behalf, the OAuth tutorial assumption of a server holding the client secret collapses. What replaces it.
Release trust without the framework
Two new public modules extracting the OpenPGP signing and verification model, so you can use it without adopting the whole framework.
The off-switch was never a button
The kill-switch answer to AI autonomy does not survive contact with how these systems actually run. Governance is not a button.
Sign your own binaries with go-tool-base, part 5: embed the key and require verification
Embed the trust anchor in your binary and require signature verification on update, without bricking anyone already running an old build.
