PHP Boy Scout — Signing your releases

Sign your own binaries with go-tool-base

Sat, 13 Jun 2026 00:00:00 +0000

If your CLI tool can update itself, it has a decision to make that nobody is watching: when it pulls down a new version, should it trust what just landed? A checksum tells it the bytes match a manifest. It does not tell it who wrote the manifest. Close that gap and your users get updates they can actually trust; leave it open and a compromised release host can hand them anything it likes. This series is the end-to-end “how”, using the signing tooling built into go-tool-base.

By the end you’ll have a CLI that ships releases signed by a key you control, verifies its own updates against that key, and does the whole thing with no gpg wrangling and no long-lived secrets sitting in CI. We did the why and the how it works in two deep-dives already, a signature the platform can’t forge and a signing key that never leaves KMS. This is the use-it counterpart.

What you’re protecting against

Nobody’s coming to clean your supply chain, so it’s worth being clear about the threat before you spend an afternoon on the fix. A checksum file sits next to the binary on the same release page. Whoever can swap the binary can swap the checksum in the same breath, and the hash still matches. A signature is different: it’s made by a private key the release platform never holds, and verified against a public key your tool fetches from somewhere the platform can’t reach. To forge a release that passes, an attacker would have to steal a key that, done right, was never anywhere they could get at it.

That “done right” is the whole series.

Two paths through it

You don’t need a cloud account to start. The series runs in two stages:

Learn it locally. Part 1 signs and verifies on your laptop with a plain key on disk. No AWS, no CI, no cost. It’s the fastest way to see every moving part for real.
Do it for production. Parts 2 onward move the private key into AWS KMS, where it’s generated and never leaves, and wire your release pipeline to sign through it over short-lived OIDC credentials.

Each part stands on its own and ends with something that works. They build in order, but you can stop after Part 1 with a genuinely useful skill and come back for the cloud parts when you need them.

Before you start

You’ll want a CLI built on go-tool-base to sign. If you haven’t got one, the Building a CLI with go-tool-base series gets you there in an afternoon; this one picks up where releases come in. You’ll also need the gtb CLI installed (the installation docs have the one-liner), and for the cloud parts, an AWS account and a GitLab or GitHub project to release from.

The parts

Sign and verify on your laptop: gtb keys generate, gtb sign, and gpg --verify, the whole loop with a local key.
A signing key in AWS KMS: stand up an asymmetric KMS key with the terraform-aws-signing-kms module.
Keyless CI signing with OIDC: federate GitLab and GitHub into the signer role, no stored credentials.
Mint and publish your public key: gtb keys mint from KMS, then gtb keys wkd to publish it off-platform.
Embed the key and require verification: bake the trust anchor into your binary and turn enforcement on safely.
Sign every release with GoReleaser: wire signing into a real tagged-release pipeline.
Rotation and break-glass: the part everyone skips, and how to do it without locking anyone out.

Start with Part 1. By the time you reach the end, the chain runs from a key born in a vault to a binary on a stranger’s machine checking, on its own, that the update it just fetched is really yours.

Nobody's coming to clean your supply chain

Fri, 29 May 2026 00:00:00 +0000

Pick a week in May 2026 and there’s a supply-chain attack in it. On the 11th someone owned TanStack’s CI and pushed 84 poisoned package versions in six minutes. On the 14th, three malicious versions of node-ipc, a library with ten million weekly downloads, shipped an identical credential-stealer. Days later it was @antv, cascading down into a charting library a million projects depend on. Each one runs its payload the moment you install it, then quietly tries to publish itself from your machine.

You’ve heard this story so many times the outrage has worn smooth. So let me point at the one detail that should still make you sit up: the TanStack packages carried valid signing provenance. Real attestation, pointing at the real pipeline. The seal was genuine. The contents were poison.

A signature proves the sender, not the contents

I’ve spent a fair while building integrity and signing into my own tools, so this one stings a little. Signing is a trust mechanism, and a good one. It’s how I prove a binary you downloaded was built and published by me and nobody else, and in a world with this many ways to be impersonated, that matters more than ever.

But TanStack shows the limit in neon. If the pipeline doing the signing is itself compromised, the signature is still perfectly valid. It just now certifies a lie. Provenance answers “did this come from where it claims?” It does not answer “is what’s inside safe?”, and we have spent a few years quietly letting people treat those as the same question.

They aren’t. A signature is a promise about the sender. The thing we actually need is a promise about the contents: that whoever signed has done the diligence, the testing, the vetting, to vouch for what’s in the tin. A signature without that behind it isn’t a safety certificate. It’s a tamper-proof seal on a poisoned jar.

It was never just npm

It’s tempting to file all this under “npm being npm”. Resist it, because it’s a category error. The thing that makes these attacks work, a stranger’s code running on your machine as a side effect of installing or building, is not an npm bug. It’s a near-universal design choice.

Ecosystem	Untrusted code on install/build?	Mechanism
npm (JS)	Yes, at install (dependencies too)	`pre`/`postinstall` scripts
PyPI (Python)	sdist yes, wheel no	`setup.py`; wheels forbid hooks
RubyGems	Yes, at install	native-extension build (`extconf.rb`)
cargo (Rust)	Yes, at build	`build.rs` and proc-macros
Composer (PHP)	Dependencies: no	only the root project’s scripts run, by design
Maven/Gradle (JVM)	Yes, at build	build scripts and plugins
NuGet (.NET)	Modern: no	`install.ps1`, legacy format only
Go (modules)	No	no install or build hooks

(Lifecycle hooks across ecosystems are catalogued at ecosyste.ms if you want the receipts.)

Read that and the lesson isn’t “npm is uniquely bad”, it’s “this was a choice, and several ecosystems chose differently”. Go runs no install or build hooks at all. PHP’s Composer flatly refuses to run a dependency’s scripts, only your own project’s. Python’s wheel format forbids install hooks. The hook was never inevitable.

And yes, that includes my own back yard. cargo’s build.rs is the same gun fired at build time instead of install time, and the TrapDoor campaign used exactly that to rifle through keystores on crates.io this year. Rust isn’t safe here. It’s a smaller, better-policed target, which is a different thing, and I’d rather say so than pretend one of my favourite languages is above it.

No registry can hand you a clean package

Here’s the uncomfortable core. Not one of these registries can guarantee the package you pull is clean. They can sign it, scan it, attest its origin and mandate 2FA on maintainers, and they should do all of that. But none of it is a guarantee, because the failure modes are endless and attackers keep finding new ones. A maintainer account gets phished. A CI token leaks. A trusted contributor turns. A dependency four levels down quietly changes hands.

So the onus lands, and will keep landing for a good while yet, on the consuming engineer. That isn’t a comfortable answer or a clever one. It’s the true one.

And it’s a genuinely rotten spot to stand in, because the advice contradicts itself. Patch slowly and you’re scolded for running known-vulnerable dependencies. Patch the instant a release drops and you’ve skipped the bedding-in that might have caught a poisoned one. There’s no setting on that dial that’s safe, only trade-offs you have to actually think about. Add CI that leaks credentials it never needed, and a dependency tree thousands of strangers deep, and you can see why there’s no single villain to blame and no single switch to flip.

The boring discipline that actually helps

What’s left isn’t heroic, it’s hygiene, and it’s the boring, necessary stuff I keep banging on about. Pin your CI actions to commit SHAs so a moved tag can’t swap code under you. Commit your lockfiles. Run the auditors, cargo-audit, pip-audit, govulncheck, npm audit, or Google’s cross-ecosystem OSV-Scanner, on every build. Gate the dependency tree and give every exception an expiry date so “we’ll deal with it later” can’t quietly become “never”. Keep the tree small: every crate you don’t add is a stranger you don’t have to trust.

None of that is a solution. All of it is diligence, and diligence is the only thing that was ever going to stand behind the signature. When I sign a release, the cryptography is the easy part. The promise underneath it, that I pinned, locked, audited, vetted and tested before I put my name on it, is the part worth anything. That’s the contract. The signature is just how I countersign it.

The encouraging note is that the structural defences exist and they work. Go’s checksum database and its refusal to run hooks. Composer declining to trust a dependency’s scripts. Python’s wheels. cargo-vet and cargo-deny giving you somewhere to record human judgement at scale. More ecosystems should steal these shamelessly, because a registry that makes the safe path the default does the working engineer a far bigger favour than one that leaves it all to discipline.

The same shape, a third time

If this feels familiar, it should. I wrote recently about a bug bounty that collapsed because the cost of slop was deferred, and about a junior pipeline being cut because the bill lands years later. Supply-chain security is the same shape a third time. The convenience is now, the catastrophe is later, and the only thing standing in the gap is an engineer paying attention, doing the dull work, refusing to be rushed into trusting something they haven’t checked.

There is no clean package waiting to be found, no registry about to solve this for us, no signature that means “safe” all on its own. There’s the diligence you do before you put your name to something, and the judgement to know when an install is asking you to trust more than you should. For a good while yet, that is the whole job. Boring, unfashionable, and the only thing that works.

Sign your own binaries with go-tool-base, part 1: sign and verify on your laptop

Mon, 15 Jun 2026 00:00:00 +0000

The quickest way to understand release signing is to do it once, by hand, with nothing but a key on disk. No cloud account, no CI, no cost. This first part of the signing series walks the whole loop on your laptop: make a key, sign a file, and verify the signature, including with plain gpg so you can see it isn’t locked to anything of ours. Everything you learn here maps one-to-one onto the AWS KMS workflow in the later parts; only where the key lives changes.

You’ll need the gtb CLI (installation docs). Make a scratch directory to work in, because we’re going to create a few files.

Make a signing key

gtb keys generate creates a keypair entirely inside the process and writes both halves to disk:

gtb keys generate \
 --algorithm rsa \
 --name "Acme Releases" \
 --email "release@acme.dev" \
 --created "2026-06-01T00:00:00Z" \
 --output signing.asc

INFO Generated OpenPGP keypair algorithm=rsa public_output=signing.asc private_output=signing.pem creation_time=2026-06-01T00:00:00Z fingerprint=...
WARN Move the private-half file to offline storage now. private_output=signing.pem

Two files come out: signing.asc (the public half) and signing.pem (the private half, a PKCS#1 PEM). The private half is the thing you guard. There’s no on-disk passphrase in this version of gtb, so keep it under filesystem encryption (LUKS, FileVault, or wrap it with age) rather than leaving it lying about.

One flag is doing quiet but important work: --created. An OpenPGP key’s fingerprint is derived partly from its creation time, so if you let it default to “now”, every run produces a different fingerprint. Pin it to a fixed instant and the key is reproducible, which matters the moment you start embedding it in a binary. Get in the habit now.

Mint the public key you’ll actually publish

You could hand signing.asc around as-is, but we’re going to produce the public key a slightly different way, with gtb keys mint:

gtb keys mint \
 --backend local \
 --key-id signing.pem \
 --name "Acme Releases" \
 --email "release@acme.dev" \
 --created "2026-06-01T00:00:00Z" \
 --output release.asc

INFO Minted OpenPGP key backend=local key_id=signing.pem output=release.asc creation_time=2026-06-01T00:00:00Z fingerprint=...

mint wraps a signing backend in OpenPGP framing and writes out the armored public key. Here the backend is local (a PEM file on disk), but in production it’ll be aws-kms pointing at a key you can’t hold. Minting the public key from the backend is the one habit worth forming early: it’s the only way to get the public half of a KMS key, so doing it the same way locally means the rest of the series is identical bar one flag. release.asc is the key you publish and embed from here on. (Because we pinned the same --created, its fingerprint matches the generated one exactly.)

Sign something

A real release signs its checksums.txt, so make a stand-in and sign it:

printf 'abc123 acme_linux_amd64\ndef456 acme_darwin_arm64\n' > checksums.txt

gtb sign \
 --backend local \
 --key-id signing.pem \
 --public-key release.asc \
 checksums.txt

INFO Signed file backend=local key_id=signing.pem public_key=release.asc input=checksums.txt output=checksums.txt.sig ...

That writes checksums.txt.sig, a detached, ASCII-armored OpenPGP signature. Note gtb sign takes --public-key: it cross-checks that the backend key matches the public key you claim to be signing as, and refuses if they diverge, so you can’t accidentally sign with the wrong key.

Verify it, two ways

First, the way your tool will do it on every self-update: against the public key. That path is the subject of a signature the platform can’t forge and we wire it into a real binary in part 5. For now, prove the signature is sound with something every machine already has, gpg:

gpg --import release.asc
gpg --verify checksums.txt.sig checksums.txt

gpg: Signature made ...
gpg: using RSA key ...
gpg: Good signature from "Acme Releases <release@acme.dev>"

Good signature is the whole point. The signature gtb sign produced is an ordinary OpenPGP detached signature, so anyone can verify it with the standard tool, no go-tool-base required. (gpg will warn the key isn’t certified in its web of trust; that’s expected and unrelated to whether the signature is valid.)

Now change a byte of checksums.txt and run the verify again. gpg reports BAD signature. That failure is the entire reason any of this exists: a tampered manifest no longer matches the signature, and a tool that requires a valid signature will refuse the update.

Where this leaves you

You’ve signed a file with a key you made and verified it independently. That’s the complete trust loop in miniature, and the shape never changes: a private key signs, a public key verifies, and the two are produced and checked the same way whether the private half is a .pem on your laptop or an HSM-held key in AWS.

The local key was the easy bit, and also the weakest: it’s a file, and files get copied. Part 2 moves the private key somewhere it can’t be copied at all, AWS KMS, and the only command that changes is the --backend flag.

Sign your own binaries with go-tool-base, part 2: a signing key in AWS KMS

Wed, 17 Jun 2026 00:00:00 +0000

Part 1 left you with a working signing loop and one glaring weakness: the private key was a .pem on your laptop, and files get copied. This part fixes that. You’ll generate the production signing key inside AWS KMS, where it’s created and never comes out, and stand up a role that can sign with it. The key itself is the only thing we build here; wiring CI in over OIDC is Part 3.

The big idea is the same one the deep-dive spends its whole length on, so I’ll keep it short: you never hold the private key and you never sign with it. You ask KMS to sign on your behalf with kms:Sign, and the private half stays inside the HSM for its entire life. There is no export, no download, no “just this once” copy onto a runner. An attacker who owns your CI still can’t walk away with the key, because the key was never on the runner to begin with.

What you’ll need first

This part is OpenTofu (or Terraform, the module is fine with either). You’ll need:

An AWS account you can apply infrastructure into.
An IAM OIDC identity provider already registered in that account. KMS doesn’t need it, but the signer role we create trusts it, so it has to exist. If you haven’t got one, the sibling module terraform-aws-bootstrap provisions it (it’s the same family as the terraform-aws-security-baseline module). Its oidc_provider_arn output is exactly what we feed in below.

You don’t need a CLI, a pipeline or a public key yet. This is just the vault and the key that lives in it.

The module

The key, its alias, the signer role and the full key policy come from one public module, terraform-aws-signing-kms. Here’s the whole consumer block:

data "aws_iam_openid_connect_provider" "gitlab" {
 url = "https://gitlab.com"
}

module "signing_kms" {
 source = "gitlab.com/phpboyscout/signing-kms/aws"
 version = "0.1.2"

 name = "acme-release-signing-v1"
 description = "Acme release binary signing"

 oidc_provider_arn = data.aws_iam_openid_connect_provider.gitlab.arn
 ci_subject_filters = ["project_path:acme/acme-cli:ref_type:tag:ref:v*"]

 key_administrator_arns = [ /* operator role + account root */ ]
 automation_role_arn = data.aws_iam_role.automation.arn
}

# Carry these forward: Part 3 wires the signer role into CI, Part 4 mints
# the public key from the alias.
output "signer_role_arn" {
 value = module.signing_kms.signer_role_arn
}

output "signing_key_alias" {
 value = module.signing_kms.key_alias_name
}

A few of those values are doing more than they look, so let’s walk them.

name is acme-release-signing-v1, with the v1 on the end deliberately. The name derives the role (<name>-signer) and the alias (alias/<name>), and both of those want to outlive the key. When you rotate to a new key in Part 7 you’ll mint a -v2 and repoint things, so bake the version in now rather than wishing you had.

ci_subject_filters is in GitLab’s OIDC sub format here, and it’s the line that says which pipeline is allowed to assume the signer role: tag pipelines for any v* ref on acme/acme-cli, and nothing else (no branch builds, no merge requests). It’s the heart of Part 3, so I’ll leave the full explanation there. For now, know it’s not optional: an empty list would trust every token from the issuer, and the module refuses to let you do that.

key_administrator_arns and automation_role_arn are the two roles that manage the key, and the distinction between them matters. More on that in a moment.

tofu init
tofu apply

What you just built

A single asymmetric KMS key, plus the IAM scaffolding around it. The key is created with key_usage = SIGN_VERIFY and the spec RSA_4096, which is the module’s default and the one you want.

The obvious question, if you’ve signed things before, is why RSA-4096 and not Ed25519, which is smaller and faster. Two reasons, and neither is preference. The first is that AWS KMS simply doesn’t offer Ed25519 for asymmetric signing, so it’s off the table the moment you decide the key lives in KMS. The second is that OpenPGP, the format your signatures end up in, ties its packet encoding to the signing algorithm: the algorithm isn’t a detail you can swap underneath, it’s written into the bytes. RSA-4096 is the spec that satisfies both constraints, so it’s the secure default and you shouldn’t need to touch it.

Two more things to note about the key itself:

enable_key_rotation is off, and that’s intentional. AWS’s automatic yearly rotation only works on symmetric keys; an asymmetric SIGN_VERIFY key can’t be auto-rotated, because a new key would mean a new public half and every embedded trust anchor breaking at once. Rotation for signing keys is a deliberate, staged operation (mint a new key, publish it, repoint the alias), which is its own part later in the series.
The deletion window defaults to 30 days, the longest AWS allows. For a key this important, the longest possible “oops, undo” window is the safe choice.

The module also creates a stable alias, alias/acme-release-signing-v1. Always reference the key through its alias, never the raw key ID. The alias is what survives rotation: when v2 arrives, the alias gets repointed and everything calling through it keeps working.

Four principals, one key policy

This is the part worth slowing down for. A KMS key is governed by its key policy, and this module writes one policy that names four classes of principal, each with deliberately different reach:

The account root keeps kms:*. That’s AWS’s recommended break-glass: if every other path is locked out, the account owner can still recover.
The key administrators (key_administrator_arns, typically your operator role plus root) can administer the key, schedule its deletion, that sort of thing. They are not signers, and they can’t sign.
The automation role (automation_role_arn, the role your infra apply pipeline assumes) can manage the key as a Terraform resource, read it, tag it, even change its policy. What it deliberately cannot do is kms:Sign. Think about why: the role that applies your infrastructure runs on every change, so if owning that role let an attacker mint signatures, you’d have handed the whole point of the exercise back. Managing the key and using the key are two different powers, and only the signer gets the second one.
The signer role can call kms:Sign, kms:GetPublicKey and kms:DescribeKey, on this one key, and that’s the entire list. It can’t read other keys, can’t administer this one, can’t delete anything.

Here’s the detail that catches people out: the signer role has no attached IAM policy at all. Its permissions live entirely in the key policy. That’s not an oversight, it’s the design. One document, the key policy, is the single source of truth for who can do what to this key, so there’s no second place to check and no way for an attached role policy to drift out of sync with the key policy and quietly grant something nobody intended. If you want to know who can sign, you read one file.

The signer role is assumable via OIDC (those ci_subject_filters again), which is what lets a CI job step into it without any stored credential. That federation is Part 3’s whole job.

The outputs you’ll carry forward

The module hands back everything the later parts consume. The ones you’ll actually use:

key_id and key_arn, the bare ID and full ARN of the key.
key_alias_name and key_alias_arn, the stable alias. key_alias_name is the one you’ll pass to gtb as the KMS key reference, because it survives rotation.
signer_role_arn and signer_role_name, the role CI assumes to sign. signer_role_arn becomes an environment variable in your pipeline next part.

Keep these to hand. Part 3 needs signer_role_arn; Part 4 needs key_alias_name to mint the public key out of KMS.

What this costs

Worth a quick word, because this is the one part of the series that puts a line on an AWS bill. An asymmetric KMS key runs about a dollar a month, plus a tiny per-signature charge on the kms:Sign calls. For release signing, where you sign a handful of checksums files a month, the per-signature cost rounds to nothing. A dollar a month for a key that can’t be stolen off a laptop is the cheapest security control in this entire series.

Where this leaves you

The key exists, it lives somewhere it can never leave, and there’s a role that can sign with it (and a separate role that pointedly can’t). What there isn’t yet is any way for your release pipeline to become that role without a long-lived credential sitting in CI.

That’s the gap Part 3 closes: federating GitLab and GitHub into the signer role over OIDC, so a tagged release can assume it for the length of one job and nothing is stored anywhere. The ci_subject_filters line we glossed over here is where it starts.

Sign your own binaries with go-tool-base, part 3: keyless CI signing with OIDC

Fri, 19 Jun 2026 00:00:00 +0000

Part 2 left you with a KMS key your release pipeline can sign through and a role (<name>-signer) that’s allowed to call kms:Sign and nothing else. There’s one obvious question left hanging: how does a CI job become that role without an AWS access key stashed in a CI variable? Because a long-lived key sitting in your settings is exactly the kind of credential that ends up in a breach write-up. This part wires CI in with no stored credentials at all, on GitLab and GitHub.

The mechanism is OIDC federation, and the one-sentence version is: your CI platform already proves who it is to AWS, so let it. When a pipeline runs, GitLab or GitHub can hand the job a short-lived signed token (a JWT) that says “this is a tag pipeline on acme/acme-cli”. AWS trusts that token the same way a bouncer trusts a passport: it checks who issued it and what it says, and if the claims match a role’s trust policy, it swaps the token for temporary AWS credentials that live only for the job’s run. No key is stored anywhere; the credentials are minted on the spot and evaporate when the runner stops. The deep-dive on keyless CI covers the why and the threat model; here we just do the wiring.

Two things have to line up for this to work: the IAM OIDC identity provider (the thing in your AWS account that says “I trust tokens from this issuer”), and the signer role’s trust policy (which says “and only from these pipelines”). The terraform-aws-signing-kms module owns the second. The first comes from a sibling module.

Where the identity provider comes from

You don’t register the OIDC provider in the signing module. That’s deliberate: the same provider is shared across every role in the account that federates from CI, so it lives one level up, in terraform-aws-bootstrap. It takes a ci_provider input (github by default, or gitlab), registers the right IAM OIDC identity provider for that forge, and emits its ARN. You feed that ARN into the signing module. If you ran the bootstrap in Part 2 you already have it; if not, stand it up first and grab the oidc_provider_arn output.

That ARN is the only thing the two modules need to agree on. Everything else about which pipelines may sign lives in the signing module’s trust policy, which is what the rest of this part configures.

The GitLab path

Look the provider up by URL so you never hardcode the ARN, then pass it in along with the subject filter that scopes who can assume the role:

data "aws_iam_openid_connect_provider" "gitlab" {
 url = "https://gitlab.com"
}

module "signing_kms" {
 source = "gitlab.com/phpboyscout/signing-kms/aws"
 version = "0.1.2"

 name = "acme-release-signing-v1"
 oidc_provider_arn = data.aws_iam_openid_connect_provider.gitlab.arn

 # oidc_issuer_host defaults to "gitlab.com"
 # oidc_audience defaults to "sts.amazonaws.com"

 ci_subject_filters = [
 "project_path:acme/acme-cli:ref_type:tag:ref:v*",
 ]

 key_administrator_arns = [/* ... from Part 2 ... */]
 automation_role_arn = data.aws_iam_role.automation.arn
}

The interesting line is ci_subject_filters. GitLab stamps each CI token’s sub claim with the project path, the ref type and the ref. The pattern above reads as “tag pipelines on acme/acme-cli, for any ref starting v”. A branch pipeline or a merge-request pipeline carries ref_type:branch instead, so it simply doesn’t match, and the role refuses to be assumed. Your signer can only be driven from a release tag, which is the whole point: a dependency author opening an MR can’t trick CI into minting a signature.

On the pipeline side, the release job declares an id_tokens block so GitLab issues a token with the right audience, writes it to a file, and the AWS SDK picks it up:

goreleaser:
 rules:
 - if: '$CI_COMMIT_TAG =~ /^v\d+\.\d+\.\d+$/'
 id_tokens:
 AWS_WEB_IDENTITY_TOKEN:
 aud: sts.amazonaws.com
 variables:
 AWS_REGION: eu-west-2
 AWS_ROLE_ARN: ${SIGNER_ROLE_ARN}
 AWS_WEB_IDENTITY_TOKEN_FILE: /tmp/aws-token
 before_script:
 - echo "$AWS_WEB_IDENTITY_TOKEN" > /tmp/aws-token
 script:
 - aws sts get-caller-identity
 - goreleaser release --clean

AWS_ROLE_ARN plus AWS_WEB_IDENTITY_TOKEN_FILE is the convention the SDK recognises: it sees the two together and calls assume-role-with-web-identity for you, so by the time goreleaser runs it’s already the signer role. The actual signing job is Part 6; the aws sts get-caller-identity line is just a sanity check that federation worked. It should print the signer role’s ARN.

The GitHub path

Same shape, different issuer and a different sub format. GitHub’s sub support landed in module v0.1.2: earlier versions validated ci_subject_filters against GitLab’s format only and would reject a GitHub subject outright, so pin the version.

data "aws_iam_openid_connect_provider" "github" {
 url = "https://token.actions.githubusercontent.com"
}

module "signing_kms" {
 source = "gitlab.com/phpboyscout/signing-kms/aws"
 version = "0.1.2"

 name = "acme-release-signing-v1"
 oidc_provider_arn = data.aws_iam_openid_connect_provider.github.arn
 oidc_issuer_host = "token.actions.githubusercontent.com"

 # oidc_audience still defaults to "sts.amazonaws.com"

 ci_subject_filters = [
 "repo:acme/acme-cli:ref:refs/tags/v*",
 ]

 key_administrator_arns = [/* ... */]
 automation_role_arn = data.aws_iam_role.automation.arn
}

Two differences from GitLab. The oidc_issuer_host has to change, because it’s the prefix on the trust-policy condition keys (token.actions.githubusercontent.com:sub rather than gitlab.com:sub). And the subject format is GitHub’s own: repo:<owner>/<repo>:ref:refs/tags/v* scopes the same way the GitLab pattern did, to tag refs only. The audience stays sts.amazonaws.com, because that’s the default aws-actions/configure-aws-credentials requests, so there’s nothing to override.

The workflow side is the official AWS action. It needs id-token: write permission to ask GitHub for the token in the first place, and contents: write so GoReleaser can create the release:

permissions:
 id-token: write
 contents: write
jobs:
 release:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - uses: aws-actions/configure-aws-credentials@v4
 with:
 role-to-assume: ${{ secrets.SIGNER_ROLE_ARN }}
 aws-region: eu-west-2
 audience: sts.amazonaws.com
 - run: aws sts get-caller-identity
 - run: goreleaser release --clean

If you forget id-token: write, GitHub never issues a token and the action fails before it reaches AWS. It’s the most common GitHub-side trip-up.

The gotcha that wastes an afternoon: token audience

Here’s the one worth burning into memory, because the error message points you at the wrong thing. An IAM OIDC provider carries a client_id_list, and it rejects any token whose aud claim isn’t on that list before AWS even looks at the role’s trust policy. So if your CI token’s audience and the provider’s client ID don’t match, you get:

InvalidIdentityToken: Incorrect token audience

That reads like a role-trust problem, and you’ll go round in circles editing ci_subject_filters, but the trust policy was never consulted. The fix is to keep the audience aligned to sts.amazonaws.com everywhere: it’s the module’s oidc_audience default, it’s what terraform-aws-bootstrap puts on the provider’s client_id_list, it’s the aud in the GitLab id_tokens block, and it’s the default aws-actions/configure-aws-credentials requests. Leave all four alone and they agree by default. The moment you override one, override all of them, or you’ll meet that error.

Where this leaves you

There’s now no AWS access key anywhere in either forge. The pipeline proves it’s a release tag on your project, AWS hands it the signer role for the length of the run, and the credentials are gone the moment the runner stops. The signing module’s trust policy is the gate; the bootstrap module’s OIDC provider is the lock it hangs on. Both are verifiable in the public modules: terraform-aws-signing-kms for the role and terraform-aws-bootstrap for the provider.

The role can sign, but you still can’t verify anything yet, because nobody has the public half of that KMS key. Part 4 fixes that: gtb keys mint pulls the public key straight out of KMS, and gtb keys wkd publishes it somewhere the release platform can’t touch.

Sign your own binaries with go-tool-base, part 4: mint and publish your public key

Sat, 20 Jun 2026 00:00:00 +0000

By the end of Part 3 your release pipeline can sign through a KMS key it never holds, over credentials that expire in minutes. The private half is locked away exactly where you want it. There’s a snag, though: a signature is no use to anyone who can’t get hold of the matching public key, and a KMS key won’t hand you one. KMS deals in raw signing operations, not OpenPGP entities. So this part does two things: it produces the published public key from the KMS key without ever touching the private bytes, then puts that key somewhere your release platform can’t reach.

That last bit is the part people skip, and it’s the part that does the real work. The whole scheme in a signature the platform can’t forge rests on the verifying key living somewhere an attacker can’t poison in the same breath as the release. We’ll come back to why that matters once the key is in hand.

Mint the public key from KMS

gtb keys mint builds an OpenPGP public key out of a signing backend. In Part 1 the backend was a .pem on disk; now it’s aws-kms, and only that flag changes:

gtb keys mint \
 --backend aws-kms \
 --kms-region eu-west-2 \
 --key-id alias/acme-release-signing-v1 \
 --name "Acme Releases" \
 --email release@acme.dev \
 --created "2026-06-02T00:00:00Z" \
 --output signing-key-v1.asc

INFO Minted OpenPGP key backend=aws-kms key_id=alias/acme-release-signing-v1 output=signing-key-v1.asc creation_time=2026-06-02T00:00:00Z fingerprint=...

Here’s the neat part, and it’s worth pausing on. An OpenPGP key isn’t just a lump of public-key material; the key carries a self-signature, a signature it makes over itself to bind the name and email to the key. So minting a public key normally needs the private key to do that signing. mint doesn’t. It wraps the backend in a crypto.Signer, and every signing operation, the self-signature included, becomes a kms:Sign call. KMS does the maths inside the HSM and hands back a signature; no private byte is ever exported, not even to stamp the key’s own identity onto itself. The mechanism is the subject of a signing key that never leaves KMS if you want to see how the signer is wired up.

Two things to get right. First, the AWS credentials: minting needs both kms:GetPublicKey and kms:Sign on the key, because it reads the public material and then signs the self-signature with it. The signer role you stood up in Parts 2 and 3 can do both; running this locally, your own credentials need the same. Second, and this is the same lesson Part 1 hammered on, pin --created. An OpenPGP fingerprint is derived partly from the creation time, so a different timestamp gives you a different fingerprint and, in effect, a different key as far as your tooling is concerned. Use the moment the KMS key was created and never let it drift: the key you embed in Part 5 and the key you publish here have to be byte-identical, and --created is what guarantees it.

Mint the rotation authority while you’re here

You won’t use it until Part 7, but the rotation-authority key is far easier to create now, alongside everything else, than to bolt on in a panic when you need it. It’s a break-glass key: an offline key whose only job is to vouch for a new signing key if the KMS one ever has to be replaced. The spare front-door key you tape to the back of a drawer, not the one on your keyring.

Because it’s break-glass, it isn’t a KMS key. You generate it on a trusted offline machine and the private half goes straight into cold storage:

gtb keys generate \
 --algorithm ed25519 \
 --name "Acme Rotation Authority" \
 --email release@acme.dev \
 --created "2026-06-02T00:00:00Z" \
 --output rotation-authority.asc

INFO Generated OpenPGP keypair algorithm=ed25519 public_output=rotation-authority.asc private_output=rotation-authority.priv.asc creation_time=2026-06-02T00:00:00Z fingerprint=...
WARN Move the private-half file to offline storage now. private_output=rotation-authority.priv.asc

For Ed25519 you get an armored public .asc and an armored secret-key block (.priv.asc, the same wire format gpg --export-secret-keys produces). Do what the warning says, and do it before you forget: move rotation-authority.priv.asc to offline storage immediately. An encrypted USB stick and a paper backup is not paranoid for a key you might not touch for two years and will desperately need when you do.

Notice it carries the same release@acme.dev user ID as the signing key, not a separate rotation@ address. That’s deliberate, and it’s the one place people trip: WKD groups keys by the email in their UID, so the matching address is what puts the rotation authority in the same bucket as the signing key, and into the same embedded trust set. Give it a different email and it quietly drops out of the published bucket, your embedded and WKD key sets stop matching, and the cross-check from Part 5 starts failing every update. Same release identity, two keys. The public half travels with the signing key from here on, published and embedded together.

Build the WKD tree

Now publish them. The way clients find a public key from an email address is the Web Key Directory: a fixed set of files under .well-known/openpgpkey/ on a web server, where each key lives at a path derived by hashing the local-part of its email. gtb keys wkd builds that tree for you, in pure Go, with no gpg or gpg-wks-client anywhere in sight:

gtb keys wkd \
 --domain acme.dev \
 --email release@acme.dev \
 --output ./wkd-staging \
 signing-key-v1.asc rotation-authority.asc

INFO WKD bucket email=release@acme.dev hash=... keys=2
INFO wrote path=wkd-staging/.well-known/openpgpkey/acme.dev/policy
INFO wrote path=wkd-staging/.well-known/openpgpkey/acme.dev/submission-address
INFO wrote path=wkd-staging/.well-known/openpgpkey/acme.dev/hu/...
INFO WKD tree complete output=wkd-staging method=advanced emails=1 files=3

Both keys carry release@acme.dev in their UID here, so they land in the same hu/ bucket, concatenated. (If you’d rather split them, give each a different email and pass --email twice.) The tree under ./wkd-staging holds a policy file (required by the spec, and empty), a submission-address file, and one hu/<z-base-32-hash> file per email with the keys inside.

One decision matters for where this gets served. The default --method is advanced, which serves the tree from a dedicated openpgpkey.acme.dev subdomain, which is why the path above has acme.dev nested inside it. Pass --method direct instead and the tree is served from acme.dev itself. Advanced is the modern default and what you want unless you’ve a reason otherwise; it does mean you’ll need DNS and TLS for openpgpkey.acme.dev.

Publish it somewhere the platform can’t reach

This is the bit that’s tempting to fudge, and the bit you mustn’t. Do not drop the WKD tree onto the same host, or under the same account, as your code and your releases.

Walk the attack through. Your binary will carry an embedded copy of the public key (Part 5). On every self-update it fetches the published key over WKD and checks the two agree before trusting a download. That cross-check is the entire defence. If an attacker who compromised your release platform could also rewrite the WKD tree, they’d swap both keys for one of their own, sign a malicious release with it, and the client would wave it straight through. The cross-check would be comparing a forged key against another copy of the same forged key. Worthless. The defence only holds if the published key and the embedded key come from infrastructure an attacker would have to breach separately. That argument is laid out in full in a signature the platform can’t forge; this is where you actually pay for it.

In practice that means a different host with its own credentials. A static host like Cloudflare Pages in Direct Upload mode does the job: you build the tree locally and push it with the Wrangler CLI under a token scoped to Pages edit and nothing else, no Git integration wired to your code repo. The token that can rewrite your keys has no power over your releases, and vice versa. For the advanced method you’ll also point DNS for openpgpkey.acme.dev at that host and let it terminate TLS. Whatever you pick, the test is simple: could one stolen credential change both the key in the binary’s update path and the key on the server? If yes, you’ve built a very elaborate way of trusting nobody.

Where this leaves you

You’ve turned a key locked inside KMS into a published, fetchable OpenPGP key without the private half ever surfacing, minted the offline rotation authority you’ll be glad of later, and put both somewhere your release platform can’t quietly rewrite. The verifying side of the loop now exists out in the world, ready to be checked against.

What’s missing is the checking. Part 5 bakes the public key into the binary as its trust anchor and turns enforcement on, so the tool refuses any update whose signature doesn’t hold, the moment that update lands.

Sign your own binaries with go-tool-base, part 5: embed the key and require verification

Sun, 21 Jun 2026 00:00:00 +0000

By now you’ve got a public key your tool can publish off-platform: minted from a KMS-held private key in Part 4 and served over WKD. That’s half the trust loop. The other half lives inside the binary itself: the tool has to hold a copy of the key it expects so that when an update lands, it can check the signature against something an attacker who owns the release page can’t quietly swap. This part bakes that trust anchor in, wires the self-updater to use it, and turns enforcement on without locking out the people who already have your tool installed.

That last clause is the one that bites, so we’ll come to it slowly. First, turning signing on.

Enable signing with one command

Your root command is generated by gtb, so you don’t wire signing in by hand-editing it. You turn the feature on and let the generator do the wiring:

gtb enable signing --email release@acme.dev

That one command does three things, all in generated, regenerable code you never touch:

scaffolds an internal/trustkeys package that //go:embeds your release keys and hands them to the self-updater;
wires Signing: props.SigningConfig{EmbeddedKeys: trustkeys.Keys()} into your generated root command;
writes a signing.go holding the enforcement defaults, generated from a signing block it adds to your .gtb/manifest.yaml. You change posture by re-running the command, never by editing the file.

Signing is off until you run this, on purpose: it needs a key and a published WKD endpoint, so a freshly generated tool doesn’t carry it uninvited. (If you’re curious what the embed package looks like, it’s a small //go:embed all:keys over an internal/trustkeys/keys/ directory with a Keys() [][]byte accessor. The all: prefix is load-bearing: a plain //go:embed keys won’t compile over a directory that holds only a dotfile, so the scaffold keeps a .gitkeep there. You don’t write any of it.)

Drop your key in

The scaffold gives you an empty internal/trustkeys/keys/. Put the public key you minted in Part 4 into it, alongside the break-glass key:

cp signing-key-v1.asc internal/trustkeys/keys/
cp rotation-authority.asc internal/trustkeys/keys/

The -v1 in the filename isn’t decoration: you’ll rotate one day and embed signing-key-v2.asc alongside it for a release or two (Part 7). The rotation-authority key rides along the same way. Rebuild, and trustkeys.Keys() now returns them. With no .asc present it returns nothing and verification stays dormant, so enabling signing before you have a key breaks nothing.

The WKD cross-check, via `--email`

The --email you passed is doing real work. The embedded key alone is a static anchor (how the verification works): it only ever says “this was the key on the day I was built.” Pairing it with the live WKD copy you published in Part 4 gives a second, independent source the release platform can’t reach. The default key source is both, an embedded-plus-WKD CompositeResolver, and the email is what lets the updater derive the WKD URL. Leave --email off and both quietly degrades to embedded-only.

For a locked-down tool that should refuse to update when it can’t reach WKD, rather than fall back to the embedded key, enable the strict cross-check:

gtb enable signing --email release@acme.dev --require-external-crosscheck

Most tools want the softer default, where WKD strengthens verification when it’s reachable and the embedded key still works when it isn’t.

Confirm the cross-check is actually firing

It’s easy to get this wrong by leaving the email out, and when you do, nothing complains: the updater quietly verifies against the embedded key alone and carries on. The way to know which anchors were actually consulted is to read the log. Every update prints a line naming the resolver it used:

INFO signature verified resolver=composite[embedded,wkd:openpgpkey.acme.dev]

That resolver= field is the whole tell:

composite[embedded,wkd:...] is what you want: both the embedded key and the WKD-served key were fetched, their fingerprints agreed, and the signature checked against the result. The cross-check is live.
embedded means only the baked-in key was used and WKD was never consulted. That’s the silent-degrade trap: key_source is "both", but with no external email there was no WKD URL to derive, so it fell back to a single anchor. If you see this after passing --email, the value didn’t take.
wkd:... on its own is the reverse: WKD was consulted but nothing was embedded.

There’s a matching update signature verification configured resolver=... line at the very start of an update, before any network call, if you’d rather see the choice before the fetch. Two failure shapes are worth recognising too. WARN composite resolver failed (RequireAll=false, continuing) means the WKD fetch fell over (a 404, a flaky network) and the update carried on against the embedded key alone, the soft default you can harden with --require-external-crosscheck. ERROR ErrKeyResolverMismatch is the one you want to see fire in anger: the embedded and WKD keys disagreed, which is exactly the tamper alarm the whole scheme exists to raise (the same mismatch the verification deep-dive walks through).

Require it, in the right order

Here’s the part everyone trips over. Enabling signing does not yet require it: require_signature stays off, and that’s deliberate. Turning it on too early breaks self-update for everyone who already has your tool.

Think about what an existing install holds. A user on an old version has a binary built before you enabled signing. It has no trust anchor. If the first thing it ever sees is a signed, signature-required release, it has nothing to check the signature against, and the update is refused. You’ve locked out exactly the people you were protecting.

The fix is to ship the key ahead of the requirement, so the anchor is already on the user’s machine by the time the first mandatory signature arrives. gtb follows the rollout in its own docs/development/phase2-signing-prep.md, across three releases:

Ship the key before you require the signature, or you lock out every install that predates it. In order:

Release N+1. Enable signing (above) and ship it, with require_signature off. Existing installs pull this update on checksum alone and pick up the embedded key as a side effect.

Release N+2. Ship your first signed release (Part 6 wires GoReleaser). Still not required: the signature is verified when present but not enforced, so nothing breaks.

Release N+3. Now, and only now, turn enforcement on.

When you reach N+3, it’s one command, not a code edit:

gtb enable signing --require-signature

That flips require_signature in the manifest and regenerates signing.go, so the change is tracked and reproducible. Skipping the middle release, requiring a signature before you’ve shipped one, is the exact mistake the ordering exists to prevent; gtb’s own rollout cites v0.12.2 as its first signed release for precisely this reason.

The checksum floor from Phase 1 sits underneath all this and is already on; signature verification adds to it, it doesn’t replace it. And even with signatures required, an end user genuinely stuck on a legacy release can escape with the update.require_signature config key or your tool’s <PREFIX>_UPDATE_REQUIRE_SIGNATURE=false. It’s an escape hatch, not the front door, but it means a requirement you turn on can’t permanently strand anyone.

Where this leaves you

Your binary now carries the key it expects, checks every update against that key and its live WKD twin, and refuses anything that doesn’t match, all without a gpg install on the user’s side and without stranding the installs that came before the key. The trust loop you built by hand in Part 1 now runs on its own, inside a stranger’s copy of your tool.

The one thing still missing is the signature itself on each release. Right now nothing is actually producing checksums.txt.sig. Part 6 wires the KMS signing from Parts 2 and 3 into a real GoReleaser pipeline, so every tagged release comes out signed without you touching a key.

Sign your own binaries with go-tool-base, part 6: sign every release with GoReleaser

Mon, 22 Jun 2026 00:00:00 +0000

By now you’ve got all the pieces lying on the bench. A KMS key that signs but never hands over its private half (Part 2). A CI role you can assume over OIDC with no stored credentials (Part 3). A public key you’ve minted and published (Part 4), and embedded in the binary (Part 5). What you don’t have yet is the bit that makes it routine: a release that signs itself, every time, without you remembering to do anything. That’s this part. We wire signing into the tagged-release pipeline so that pushing a v* tag is the whole ceremony.

This is the part of the signing series where the chain stops being a set of commands you run by hand and becomes something the pipeline does for you. We’re using GoReleaser, which already builds your binaries, writes a checksums file and cuts the release. It needs one extra trick: sign the checksums on the way out, through the KMS key, using credentials that only exist for the length of the job. And you don’t hand-write that trick into your release config. gtb does.

You’ll need a working GoReleaser setup releasing a go-tool-base CLI, plus the KMS key, the signer role and the embedded public key from the earlier parts.

One command wires the signing in

In Part 5 you ran gtb enable signing to turn on the verifying side: embed the key, check every update against it. Now you give that same command the key the release pipeline should sign with, and it wires the producing side too:

gtb enable signing --key-id alias/acme-release-signing-v1

That records the KMS key in your .gtb/manifest.yaml and regenerates .goreleaser.yaml with a signs: block that calls gtb sign. The WKD email and everything else you set in Part 5 stay exactly as they were; you’re adding the key, not starting over. Because the block is generated, you don’t hand-edit the release config any more than you hand-edit the embed wiring. Change the key later (a new region, a rotated alias) and you re-run the command, not the YAML.

The generated block looks like this:

signs:
 - id: checksums
 cmd: gtb
 args:
 - "--ci"
 - "sign"
 - "--backend"
 - "aws-kms"
 - "--kms-region"
 - "eu-west-2"
 - "--key-id"
 - "alias/acme-release-signing-v1"
 - "--public-key"
 - "internal/trustkeys/keys/signing-key-v1.asc"
 - "--output"
 - "${signature}"
 - "${artifact}"
 artifacts: checksum
 signature: "${artifact}.sig"
 output: true

The region defaults to eu-west-2 and the public key to the internal/trustkeys/keys/signing-key-v1.asc you embedded in Part 5; pass --kms-region or --public-key if yours differ. The backend defaults to aws-kms, which is the one that matters in CI.

Why only the checksums

artifacts: checksum is the line doing the load-bearing work. It tells GoReleaser to run the signing command once, over the checksums manifest only, not over every binary and archive in the release.

Here’s why that’s enough. GoReleaser builds your binaries, then writes a checksums.txt listing the SHA-256 of each one. Every artefact in the release is named in that file by its hash. So if you sign the manifest, you’ve transitively vouched for everything it lists: change a single byte of any binary and its hash no longer matches the line in checksums.txt, and the moment you alter checksums.txt to cover for that, the signature over it breaks. One signature, the entire release covered, through the hash chain. The per-binary build stays completely untouched, which keeps reproducible builds reproducible. signature: "${artifact}.sig" names the output checksums.txt.sig, the detached, ASCII-armored OpenPGP signature your tool looks for on every self-update.

No shim, just `gtb`

If you go reading go-tool-base’s own release config, you’ll find its signs: block points at a scripts/sign-release.sh shim rather than calling gtb directly. Yours doesn’t, and the difference is worth understanding.

go-tool-base is signing the very binary it’s in the middle of building, so it can’t use an installed gtb to do it. Its shim runs go run ./cmd/gtb to build a throwaway signer from source. It also reads the key id, public key and region from environment variables, because the one config has to serve every build. Your tool has neither problem. It calls the gtb you already installed, and the generator already knows your key id, region and public-key path because you just told it. So there’s nothing for a shim to abstract: the whole invocation goes straight into args:, where you can read it.

The one thing you do still need is gtb on the release runner’s PATH. Install it in a before_script, or bake it into your CI image, the same way you would any other release tool.

Where the credentials come from

gtb sign asks KMS to sign. KMS will only oblige if the caller has credentials, and the whole point of keyless CI is that there are no stored credentials to leak. So they’re minted on the fly.

On GitLab, the release job declares an id_tokens: block. GitLab injects a short-lived OIDC token (a JWT) into the job, the before_script writes it to a file, and the AWS SDK’s default credential chain picks it up from there. No aws CLI call, no assume-role-with-web-identity you write yourself: set AWS_ROLE_ARN and AWS_WEB_IDENTITY_TOKEN_FILE and the SDK does the web-identity exchange the first time gtb sign touches KMS:

goreleaser:
 id_tokens:
 AWS_WEB_IDENTITY_TOKEN:
 aud: sts.amazonaws.com
 variables:
 AWS_REGION: eu-west-2
 AWS_ROLE_ARN: arn:aws:iam::…:role/acme-release-signing-v1-signer
 AWS_WEB_IDENTITY_TOKEN_FILE: /tmp/oidc-token
 before_script:
 - echo "$AWS_WEB_IDENTITY_TOKEN" > "$AWS_WEB_IDENTITY_TOKEN_FILE"

The key id and region live in the generated signs: block now, not here, so CI only supplies the AWS credentials. AWS_REGION still earns its place: the --kms-region flag points the KMS client at the key, while the SDK uses AWS_REGION for the STS exchange that mints the credentials in the first place. The aud has to match the audience the signer role’s trust policy expects (Part 3 set this up; for the OIDC provider go-tool-base uses, that’s sts.amazonaws.com). On GitHub the moving parts are the same, you just let aws-actions/configure-aws-credentials do the token-to-credentials dance instead of writing the file yourself.

Those credentials are scoped tight. The signer role’s trust policy pins it to this project’s tag pipelines, so even if the role ARN leaked, nothing but a release tag on your repo can assume it.

Don’t sign when there’s nothing to sign with

A local goreleaser release --snapshot, or a CI run that isn’t a release, has no OIDC token and no business reaching for KMS. GoReleaser is told to skip the whole signing step in that case: the release job runs with --skip=sign unless the web-identity token is present. So a non-release build never so much as looks at KMS, which is exactly what you want when you’re iterating on your laptop. The signing only fires on the real thing.

Cut a release

With all of that in place, releasing is one push:

git tag v1.4.0
git push origin v1.4.0

The tag pipeline fires. GoReleaser builds the binaries, writes checksums.txt, calls gtb sign, gtb asks KMS to sign over OIDC, and checksums.txt.sig lands next to the manifest. Both get attached to the release. Nobody typed a signing command and no private key was anywhere near the runner.

A two-person gate, if you want one

There’s a window worth thinking about: a compromised CI runner during a release could, in principle, ride the OIDC credentials to get one malicious thing signed. You can shut that window with an approval gate in front of the signing job. On GitLab, a protected environment with a required approval (or a manual job) makes the release wait for a second pair of eyes; on GitHub, “required reviewers” on the release environment does the same. It’s optional, and it adds friction to every release, so weigh it against how exposed your runners are. For a lot of projects the OIDC scoping alone is enough; for anything where a forged release would be a genuine incident, the gate is cheap insurance.

Where this leaves you

Every release you cut from here on carries a signature made by a key you control and verifiable by anyone, and you got there by pushing a tag. That closes the loop the series has been building toward: the production side now actually produces signed releases.

Which means you can finally pull the trigger on the bit Part 5 left primed. We embedded the public key and left enforcement off, because turning it on before you ship signatures would brick every update. Now that signatures are shipping, Part 7 deals with the part everyone skips and nobody can afford to: rotating the key, and getting yourself out of trouble if one ever goes bad, without locking your users out.

Sign your own binaries with go-tool-base, part 7: rotation and break-glass

Tue, 23 Jun 2026 00:00:00 +0000

Most signing guides stop the moment the first release goes out the door, which is a shame, because the question that keeps you up at night comes later: what do you do when the key has to change? Keys get rotated on a schedule, keys get compromised, and one day you’ll want to move off RSA onto something newer. This last part of the signing series covers the bit everyone skips, swapping a signing key out from under a fleet of installed tools without locking a single one of them out, and the break-glass key for the day the primary is gone.

By Part 6 you’ve a pipeline signing every tagged release through a KMS key, a public key published over WKD, and that same key baked into the binary as its trust anchor. It all works. The catch nobody mentions is that you’ve now got a key embedded in software sitting on other people’s machines, and that key is the one thing in the whole chain you can’t quietly change. So let’s plan for changing it properly.

Why there’s no auto-rotate button

If you’ve used KMS for encryption, you’ll know it can rotate keys for you on a yearly tick. Asymmetric SIGN_VERIFY keys don’t get that, and the terraform-aws-signing-kms module sets enable_key_rotation = false on purpose. That’s not an oversight to work around; it falls straight out of how the key is built. The private half of a signing key never leaves the HSM and has no export path at all, so there’s no mechanism by which AWS could hand your verifiers a rotated public half and keep the old one verifiable. KMS auto-rotation works for symmetric keys precisely because you never see the key material; the instant you need a public key your clients pin against, rotation stops being something a cloud provider can do behind your back.

So rotation here is a runbook you maintain, not a checkbox you tick. That sounds like the worse deal until you weigh it: you’ve got a key with no exfiltration path, in exchange for rotating it by hand on the rare occasions you must. For a release-signing key that’s exactly the right trade. You don’t want this key rotating itself; you want to be standing right there when it happens.

Rotate by minting a new key, never by changing the old one

Here’s the rule that makes everything else fall into place. You do not edit the existing key. The module’s key_spec and name are immutable by design, and that immutability is a feature: the v1 key is a fixed point that stays verifiable while you stand up its replacement next to it.

So you mint a second key. A second module instance, named acme-release-signing-v2, with its own alias alias/acme-release-signing-v2:

module "signing_kms_v2" {
 source = "gitlab.com/phpboyscout/signing-kms/aws"
 version = "0.1.2"

 name = "acme-release-signing-v2"
 oidc_provider_arn = data.aws_iam_openid_connect_provider.gitlab.arn

 ci_subject_filters = [
 "project_path:acme/acme-cli:ref_type:tag:ref:v*",
 ]

 key_administrator_arns = [/* ... */]
 automation_role_arn = data.aws_iam_role.automation.arn
}

Apply that and the v1 key carries on signing, undisturbed. Now mint its public half exactly the way you minted v1 back in Part 4, only the alias changes:

gtb keys mint \
 --backend aws-kms \
 --kms-region eu-west-2 \
 --key-id alias/acme-release-signing-v2 \
 --name "Acme Releases" \
 --email release@acme.dev \
 --created "2026-06-08T00:00:00Z" \
 --output signing-key-v2.asc

You’ve now got two real signing keys, both live, neither one a threat to the other. The whole rotation is the careful business of moving traffic from one to the other while every installed client keeps verifying.

The dual-publish, dual-sign window

This is the part that does the work, and it leans on one fact about how the verifier treats your keys. The trust anchor isn’t a single key, it’s a set: v1, v2, and the rotation authority all sit in internal/trustkeys/keys/ and all get embedded together. A release verifies if any key in that set validates its signature. That’s what makes a handover window possible, because during it a client might hold v1, or v2, or both, and verify happily whichever it has.

So you run an overlap. Three moves, in order.

First, publish both public keys over WKD. Same email bucket, same command you already know from Part 4, just with v2 added to the file list:

gtb keys wkd \
 --domain acme.dev \
 --email release@acme.dev \
 --output ./wkd-staging \
 signing-key-v1.asc signing-key-v2.asc rotation-authority.asc

Both signing keys share release@acme.dev in their UID, so they land in one hu/ bucket together, and the rotation authority rides along as it always has. Deploy that staging tree the way you deployed it before. Now the WKD endpoint serves the new trust anchor, so a client that fetches keys on its next update picks v2 up automatically.

Second, embed v2 alongside v1 and ship a release. Drop signing-key-v2.asc into internal/trustkeys/keys/ next to v1, cut a release, and that build now ships knowing about both keys. Installed clients pick the new trust anchor up as they update through the window. This is the slow bit, and it should be: you want the new key spread far and wide before you stop signing with the old one.

Third, sign with v2, wait, then retire v1. Point the pipeline’s GTB_SIGNING_KEY_ID at alias/acme-release-signing-v2 so new releases are signed by the new key. A client that’s already updated verifies against the embedded v2; one that’s lagging still has v1 in its set and, because you’re still publishing v1 over WKD, can still fetch and trust it. Nobody’s locked out.

Leave that overlap running long enough that you’re confident the slow movers have updated, weeks, not hours, depending on how often your users actually run the thing. Only then do you retire v1: drop its module instance, pull signing-key-v1.asc from the embed directory and the WKD file set, and ship a release that knows only about v2. The rotation is done, and at no point did an installed tool see a signature it couldn’t check.

The break-glass key, for when there’s no handover

Everything above assumes the old key can hand over to the new one: it’s still there, still able to sign, and you’re rotating on your own terms. The nightmare is the other case. The KMS key is gone, access revoked, or you’ve reason to think it’s compromised and you daren’t sign anything with it again. There’s no handover, because the thing that would do the handing is exactly what you’ve lost.

That’s what the rotation-authority key is for, and it’s why Part 4 had you mint it the moment everything else was calm. It’s an offline ed25519 key, generated once on a trusted machine, and the go-tool-base how-to, generate the rotation-authority key, walks the storage in detail. The short version: the private half never lives on a networked box. You print a paper backup with paperkey, write it to an encrypted USB stick, and the two go in a safe; the local copy gets shredded. The how-to even has you type the paper backup back in once before you walk away, because discovering your printer ate a stripe of pixels is a problem you want now, not eighteen months from now when the building’s on fire.

The public half, though, has been in your trust set the whole time, embedded in the binary and served over WKD right alongside the signing keys. That’s the trick. Because every installed client already trusts the rotation authority, it can vouch for a brand-new signing key outside the normal sign-with-the-old-key path. You bring the private half out of the safe, use it to authorise the new key, ship that, and installed tools adopt the replacement on their next update, all without the dead primary key ever having to sign a thing.

It is, deliberately, a key you hope never to touch. But a break-glass key you forgot to cut is just a pane of glass.

The whole chain, end to end

That’s the series. Step back and the shape is one clean line: a signing key is born inside KMS and never leaves it (Part 2); its public half is minted out of the HSM without the private bytes ever surfacing (Part 4); that public key is published off-platform over WKD, somewhere your release host can’t quietly rewrite (Part 4), and embedded into the binary as a required trust anchor (Part 5); every tagged release is signed through the key over short-lived OIDC credentials with no stored secrets (Parts 3 and 6); a stranger’s copy of your tool verifies its own updates against that anchor before trusting a byte (the cross-check); and when the day comes, the whole thing is rotatable without locking anyone out. A key that can’t be stolen, can’t be forged, and can still be replaced.

If you’ve followed all seven parts, you’ve built that. If you’ve dipped in for one piece, the pillar ties the lot together and points at the deep-dives behind the why. Either way, your users are getting updates they can actually trust, which was the whole point. Go and leave your supply chain better than you found it.

A signature the platform can't forge

Tue, 09 Jun 2026 00:00:00 +0000

A self-updating tool has a chicken-and-egg problem baked into it. The thing doing the updating is the thing being updated, so when it reaches out and pulls down a newer version of itself, it’s the one that has to decide whether to trust what just landed. No human in the loop, nobody to ask. I’ve been closing that gap in go-tool-base’s self-updater in two phases. The first gave it a checksum: download the new binary, hash it, compare it against the release’s checksums.txt. That catches the accidents, the truncated download, the flipped bit on a dodgy mirror. And I said at the time, plainly, that it does nothing about a determined attacker who owns the release platform… the checksums file sits right next to the binary, so whoever can swap one can swap both. I left that as an IOU. This second phase is me paying it.

The thing a checksum can’t do

A checksum is a promise that the bytes you got match the manifest. It says nothing about who wrote the manifest. So if GitLab, or my account, or a leaked CI token gets compromised, the attacker rewrites the binary and the checksums.txt in the same breath, and the hash matches perfectly, because they’re the one who computed it. It’s the same wall I keep walking into whenever I think about supply-chain trust: a checksum is only ever as good as whatever’s standing behind it, and the thing standing behind a checksum is the very platform that just handed you the file. Same hands, both times.

To get past that, you need a signature whose root of trust lives somewhere the platform can’t reach.

The crypto is the easy part

Here’s the bit that caught me slightly off guard while I was building this: the cryptography is the easy part. Verifying a detached OpenPGP signature is a library call, and go-tool-base’s TrustSet wraps it up in one method:

func (t *TrustSet) VerifyManifestSignature(manifest, signature []byte) error {
	// ...
	signer, err := openpgp.CheckArmoredDetachedSignature(
		t.entities, bytes.NewReader(manifest), bytes.NewReader(signature), nil)
	if err != nil {
		return errors.Wrap(ErrSignatureInvalid, err.Error())
	}
	if signer == nil {
		return errors.Wrap(ErrSignatureInvalid, "no signer in trust set matched")
	}
	return nil
}

Hand it the manifest, the detached signature, and a set of trusted public keys (the entities), and it tells you whether any one of them signed it. That’s the whole of the cryptography, and it’s genuinely not where the hard work lives.

The hard work is that set of trusted public keys. Where do they come from? Because if the answer is “we ship them right next to the binary”, well… you’re straight back to the checksum problem. Whoever can swap the binary can swap the key too, sign with their own, and the check waves it through none the wiser.

Pulling the two questions apart

So the design splits along exactly that seam. The verification half is fixed, and deliberately boring (the method above). The trust anchor, the actual keys, comes from a swappable KeyResolver:

// The interface separates "where the trust anchor comes from" from "how a
// signature is verified against it", so SelfUpdater can be wired with
// whichever resolver chain a tool needs without changing verification logic.
type KeyResolver interface {
	Name() string
	Resolve(ctx context.Context) (*TrustSet, error)
}

That little seam is really the whole game. Everything interesting about standing up to a compromised platform comes down to which resolver you hand the updater, and the verification code never has to know the difference.

Three answers to “where does the key live”

The first option is to embed it. Bake the public key straight into the binary at build time (NewEmbeddedResolver), so it rides along inside a release you already trusted enough to run. Tidy and self-contained. The catch is that a future malicious release could embed a different key, so on its own, embedding really just trusts whoever cut the most recent binary.

The second is WKD, the Web Key Directory. Fetch the key over HTTPS from a well-known path on a domain you control (NewWKDResolver), nothing to do with where the release itself is hosted. Now the key isn’t in the binary at all, so poisoning a release doesn’t touch it. You haven’t made the problem disappear, mind… you’ve moved the trust onto your domain’s host and its DNS. A different blast radius, but a blast radius all the same.

The third option is to do both, and make them agree. Run embedded and WKD, and insist they agree:

func (c *CompositeResolver) Resolve(ctx context.Context) (*TrustSet, error) {
	// ... run each child resolver concurrently ...
	if err := checkAgreement(successes); err != nil {
		return nil, err // ErrKeyResolverMismatch
	}
	return successes[0].ts, nil
}

Think of it as the two-key rule on a safe deposit box, or two witnesses who’ve never met telling you the same story. One source on its own you might quietly doubt. But if the key baked into the binary and the key sitting on my domain hand back the same fingerprint, that agreement is worth a great deal more than either of them alone. And if they ever come back different, that’s not a maybe, that’s an alarm: ErrKeyResolverMismatch. Poison one source and the mismatch is the thing that gives the game away.

That composite is the real answer, and it’s why the interface exists at all. There’s nothing a single attacker can get their hands on that holds the whole thing up by itself. The key is baked into a release you trusted, and fetched from a domain well off the release platform, and the two have to match before a single byte of the update is allowed through.

The separation is the whole point

It’s easy to nod along at “two sources” and miss the part that actually does the work. The agreement between the embedded key and the WKD key is only worth something if an attacker can’t reach both of them from the same place. If the key I bake into the binary and the key I serve over WKD both came out of the same release pipeline, whoever owns that pipeline swaps the pair of them, the fingerprints still match, and the cross-check happily waves the forgery through. Same hands, both times. Again.

So they don’t share a pipeline, and that’s the entire design, not an accident of how things ended up. The binary, and the key embedded in it, are built and signed in GitLab CI, which federates into AWS KMS to do the signing itself. The WKD key lives somewhere else completely: a Cloudflare Pages site serving openpgpkey.phpboyscout.uk, deployed by hand at rotation time with the Wrangler CLI and a token allowed to do nothing but edit that one Pages project. No Git integration, no webhook, nothing that lets a push to the repo or a run of the release pipeline so much as touch it. The Cloudflare account is even administered under a different email and a different second factor from the GitLab and AWS ones, so the three anchors really are independent rather than just feeling that way.

Which is what makes them fail independently, and that independence is the only thing that makes the agreement worth checking. To forge a release that survives the cross-check, an attacker doesn’t have to beat one system, they have to beat two unrelated ones, on different platforms, behind different credentials, in the same window, without either of them noticing.

There’s a quieter benefit in the cadence, too. Releases go out constantly and automatically; the WKD key changes rarely, and only ever by hand. So the busy, automated path, the one an attacker is most likely to prise open, is exactly the one with no power to rewrite the key everyone checks against.

Requiring it, without breaking everyone

Now, a check nobody ever switches on is just theatre. But switch it on before the keys are actually out there in people’s installs, and you’ve handed everyone a self-inflicted outage instead. So the default is deliberately timid. The framework ships DefaultRequireSignature = false: a tool built on go-tool-base doesn’t suddenly start rejecting its own updates the day its author bumps the framework version.

The tool author flips it to true in main(), but only after they’ve shipped a release that embeds the key, so every install out there already holds the trust anchor before the first release that insists on one. Ship the key, then turn the lock: the same leave-yourself-a-way-back discipline as any migration you’d like to still have a job after. And the end user still gets an override (update.require_signature, or an env var) for the day it all goes sideways and they need out.

What it actually buys

The first phase stopped accidents. This one stops the platform. And not because the cryptography is clever, OpenPGP checks the signature in a single call, but because the trust anchor is arranged so that nothing the attacker can actually reach holds the whole thing up on its own. A signature only ever proves the sender, never the contents. All of this is really about making “the sender” something a compromised release host can’t quietly fake its way into being.

Which leaves one last thread dangling. The verifying key gets fetched from somewhere, fine… but the signing key, the private half that actually produces these signatures, has to live somewhere the platform can’t reach either, or none of the rest holds up. That’s the capstone, and where this series ends: where that key lives, and why it never leaves the box it’s born in.

A signing key that never leaves KMS

Thu, 11 Jun 2026 00:00:00 +0000

The last post in this series walked through how a tool verifies a release signature the platform can’t forge. That post had a loose end dangling off the back of it, and I knew it the whole time I was writing. Because a signature has to be produced by a private key… and a private signing key is the single worst thing in this entire story to lose. Steal it, and you sign malware that sails through every check I spent two posts building, signature and all. So where does that key live? The answer I landed on is the one this whole post is about: inside AWS KMS, and it never comes out.

The only key you can’t steal

Think about where a signing key normally ends up. A file on a build server. A secret in CI. A key on the release engineer’s laptop, “just for the release, I’ll delete it after”. Every one of those is a copy, and every copy is one more thing somebody can read, exfiltrate, or quietly clone while your back is turned. You can wrap them in passphrases and vaults and rotation policies all you like, and you’re still standing guard over a thing that exists in a place you don’t fully control.

The way out is almost annoyingly simple to state: the only key nobody can steal is the one that was never anywhere to be stolen from. So don’t hold the key at all. Let something else hold it, somewhere it has no export path, and ask that thing to sign for you.

That thing is AWS KMS. This is the infrastructure side of the question I opened the signing series with, finally answered with real Terraform.

A key that’s born in the box and stays there

The signing key is an asymmetric KMS key, and the module that provisions it is small enough to read in one sitting:

resource "aws_kms_key" "this" {
 description = var.description
 key_usage = "SIGN_VERIFY"
 customer_master_key_spec = var.key_spec # default RSA_4096

 # Asymmetric SIGN_VERIFY keys do not support KMS-managed rotation;
 # rotation is handled by minting a new key (alias = `<name>-v2`) and
 # publishing the v2 public key alongside the v1 key (dual-sign window).
 enable_key_rotation = false

 policy = data.aws_iam_policy_document.key_policy.json
}

The private half of that key is generated inside KMS and there is no API that hands it back to you. You don’t sign with it the way you’d sign with a file. You call kms:Sign: the bytes you want signed go up, a signature comes back down, and the key itself never moves. An attacker who completely owns my CI, my account, my laptop, can ask KMS to sign things for as long as their access lasts… but they can’t walk off with the key and keep signing forever. The blast radius is “while I’m compromised”, not “until I rotate a key I didn’t know had leaked three years ago”.

Why RSA-4096 and not the Ed25519 I’d normally reach for? Because KMS asymmetric signing doesn’t offer Ed25519, and OpenPGP’s packet format is tied to the algorithm that signed it, so the choice of key spec ripples all the way out to the signature on the wire. RSA-4096 is the strong option KMS does offer, so RSA-4096 is what the workflow is built around. A constraint of the box shaped the cryptography, not the other way round, and I’d rather say so than pretend I picked RSA on purpose.

Minting an OpenPGP key from a key you can’t hold

Here’s the part I find genuinely neat. OpenPGP wants a private key to self-sign its own public key when you generate it. And I don’t have a private key in any form I can hand to a library… it’s sitting in KMS, behind a door with no handle on my side. So how do you produce a valid OpenPGP public key at all?

go-tool-base leans on a small Go interface, crypto.Signer: anything that can return its public key and sign a digest. A KMS-backed signer satisfies it by turning each Sign call into a kms:Sign request. Then pkg/openpgpkey builds the OpenPGP entity around that signer:

func Entity(signer crypto.Signer, name, email string, creationTime time.Time) (*openpgp.Entity, error) {
	rsaPub, ok := signer.Public().(*rsa.PublicKey)
	// ...
	pubPkt := packet.NewRSAPublicKey(creationTime, rsaPub)
	// Construct the private-key packet directly (rather than
	// packet.NewSignerPrivateKey, which panics on opaque signers):
	// the crypto.Signer drives the actual signing, so a KMS-backed
	// signer works here.
	privPkt := &packet.PrivateKey{PublicKey: *pubPkt, PrivateKey: signer}
	// ...
}

Look at that PrivateKey packet. The field where OpenPGP expects the secret key material holds the crypto.Signer instead, which is to say, a remote handle to KMS. When the entity self-signs its public key, that self-signature is computed by KMS. gtb keys mint runs exactly this and writes out an ASCII-armored OpenPGP public key, and at no point did a single byte of private key material exist on the machine that minted it. The OpenPGP “private key” is a phone line to a vault, not a key.

That public key is what gets published off-platform over WKD and baked into the binary, the two trust anchors that post cross-checks.

Access without a human and without a standing key

A key that never leaves KMS is only as good as the rules about who may call kms:Sign. The signer role is deliberately narrow: it can call kms:Sign and kms:GetPublicKey on this one key and nothing else, and it is assumable only over OIDC from specific CI subjects, the same keyless federation the rest of the estate runs on. No human holds it. No long-lived access key sits in a CI variable waiting to leak. A release job federates in for its few minutes, signs, and the credentials evaporate with the runner.

So the chain of “who can sign a release” has no standing secret in it anywhere. Not a key file, not an access key, not a console user. Just a short-lived token, scoped to two API calls, on a key that can’t be exported.

The real cost: rotation is manual

This isn’t free, and the bit it taxes you on is rotation. KMS won’t auto-rotate an asymmetric SIGN_VERIFY key, which is why the module sets enable_key_rotation = false rather than leaving a default on. Rotating means minting a new key (a -v2 alias), publishing its public key alongside the old one, and running a dual-sign window long enough that clients have picked up the new anchor before you retire the old. It’s manual, it’s a runbook, and pretending otherwise would be the kind of thing this series exists to argue against. The trade I made was: a key with no exfiltration path, in exchange for rotation I have to do by hand. For a release-signing key, that’s the right side of the trade.

Why this is a command and not a script I hid

The origin of all this is a good deal less tidy than the result. I was working through the key-generation runbook, creating the offline rotation key with a gpg command I’d copied straight off my own page… and it just hung. No error, no prompt, just a cursor blinking while gpg waited on something it never bothered to mention.

My first instinct was the lazy one: drop the minting script into a scripts folder in my infra repo and never speak of it again. Then it nagged. That repo’s private, so the recipe would live somewhere nobody else could ever reach, and I’d already half-promised myself a tutorial walking people through this exact setup. So it shouldn’t sit in infra at all. It should be a gtb command, with a pluggable backend so anyone can swap my KMS for whatever provider they happen to run.

The deeper objection is the one that actually shaped it, though. I didn’t want to be shelling out to gpg by hand in the first place. gtb is a tool I hand to other people, and every time it drops to the shell for some gpg incantation, that’s an environment I’m asking the next person to reproduce, a dependency to install, a fiddly step to get subtly wrong, all before they can sign a single thing. The aim was to keep as much of this inside the box as I could: mint the key, build the WKD tree, produce the signature, all in pure Go, with no gpg on the path and no gpg-wks-client either.

So gtb keys mint pulls the public half out of your KMS key and frames it as OpenPGP, the trick from earlier; gtb keys wkd builds the tree ready to upload; and gtb sign produces the detached signature through that same remote round-trip. What comes out is an entirely ordinary OpenPGP signature gpg --verify is happy with, so you’re not locked into anything of mine. And none of it is just for me: build your tool on go-tool-base and the same handful of commands stands you up with this exact model, pointed at your own KMS. No cloud KMS to hand? There’s a local backend, a plain key on disk, to wire the whole thing together on your laptop first. These are commands for you, the person shipping the tool. Your users never run mytool keys mint… they just get updates that quietly check themselves, which was the whole idea two posts ago.

That setup deserves a walkthrough of its own, and it’ll get one. For now, the ergonomics were the point, not a nicety bolted on afterwards. The safest setup in the world is no use to anyone if it takes a PhD to stand up.

Where this leaves the whole story

Step back and the full loop is finally closed. The private key is born in KMS and never leaves it. Its public key is minted from it, with KMS computing its own self-signature. That public key is published off-platform and embedded in the binary. Releases are signed by KMS, reached only through short-lived OIDC federation. And the client verifies against the embedded and WKD keys cross-checked against each other. At no single point in that chain is there a thing an attacker can grab that lets them forge a release, and the most dangerous thing of all, the private key, has no theft path because it has no export path.

That’s the thread running through the whole signing series, from the very first checksum to here: the strongest control isn’t a better lock on the key. It’s arranging things so the key was never somewhere you could lose it. Nobody is coming to clean your supply chain, so the least you can do is leave it nothing worth stealing.

The gpg command that hung (so I built signing into the tool)

Wed, 29 Jul 2026 00:00:00 +0000

This one starts at the day job, not the side projects. My employer ships Go products and wants to move quickly on them, which is reasonable, but nobody wants to hand-maintain a fresh pile of the same boilerplate every time a new service spins up. I’d had go-tool-base running as a product of my own for a while by then, solving exactly that, so I put my hand up: use this, and the boilerplate stops being your problem.

There was a condition, and it was the right one. To go anywhere near our codebase it had to clear the security bar, and ours is not a low bar. So I set about hardening the thing properly, layer by layer, until it could pass the regulations the business actually has to answer to rather than the ones a side project can wave away. One of those layers, unavoidably, is signing your releases. If you’re shipping binaries into an enterprise, “trust me, I built it” is not a supply-chain story anyone signs off on.

Which is how I came to be generating a signing key by hand with gpg. Or trying to.

The incantation is the sort of thing you copy from your own notes from the last time, feed it the right flags, and walk away from while it does its business. So I did. And it just… hung. No key. I went round the houses. --list-secret-keys came back empty while --list-keys cheerfully showed the public half. GNUPGHOME had the public part and not the secret one, which is a contradiction in terms if you think about it for more than a second. I was, in short, fighting gpg’s environment rather than doing the actual work, and getting nowhere.

I’ll spare you the precise sequence of me being wrong, because the sequence isn’t the point. The point arrived somewhere in the middle of it, and it changed the whole approach.

If I’m fighting gpg here, on my own machine, with my own notes, then every single team that adopts this framework is going to fight gpg too.

That’s the thing about distributing a tool, especially into a place where ten teams will pick it up rather than one. The boilerplate they didn’t want to maintain… that wasn’t just the HTTP wiring and the config plumbing. It was this. The fiddly, environment-dependent, fails-in-a-different-way-on-every-machine business of producing a signing key. Push that onto every team and you haven’t given them a framework, you’ve given them a homework assignment with a security deadline.

So it moved inside the box. Key generation and minting became commands in the binary itself: gtb keys generate to produce a fresh keypair, gtb keys mint to turn it into the signing key the release process wants, no shell-out to gpg anywhere in the path. The gpg backend I’d started with got dropped entirely rather than papered over. The tool now does the awkward part the same way on every machine, because it’s the same code doing it every time, not a conversation with whatever gpg thinks GNUPGHOME means today.

The actual cryptography underneath is still real OpenPGP, and the question of how you mint a key whose private half never leaves a hardware module is its own story. This isn’t really about the crypto. It’s about where you put the sharp edges.

When you build a tool for yourself, you can live with the dangerous bits. You learn where they are, you work around them, and they become invisible. When you hand that tool to an enterprise full of people who’ve never met it, everything you left out in the open is a support ticket, a stalled rollout, or worse, a team deciding signing is too much hassle and skipping it. Keeping the sharp edges inside the box isn’t polish. For this, it was the difference between a security control people use and one they route around.

The best thing I shipped that week wasn’t a cleverer algorithm. It was a key that couldn’t fail to generate. Unexciting, I’ll grant you. But an unexciting key you actually have beats a clever one you’re still fighting at 11pm.

The framework doesn't know where your signing key lives

Tue, 04 Aug 2026 00:00:00 +0000

A consumer of go-tool-base asked me where their signing key was supposed to live, and the answer was: that’s deliberately not my call. There’s a deliberate hole in go-tool-base’s signing, and it’s the most important part of the design. The framework will sign your releases, mint you an OpenPGP key, produce a detached signature a consumer can verify. What it will not do is have an opinion about where your private key actually lives. It genuinely doesn’t know, and that’s on purpose.

Here’s why that hole has to be there. Of all the decisions wrapped up in “sign your releases,” the one that varies most wildly between one shop and the next is where the signing key is kept. One team has standardised on AWS KMS and everything has to go through it. The next is a Google shop and it’s GCP KMS or nothing. A third runs Vault. A fourth, the security-conscious solo dev, wants the private half sitting on a YubiKey in a drawer and never anywhere else. These aren’t preferences you can talk someone out of, they’re usually a compliance boundary or an existing investment, and they’re load-bearing.

So if the framework hard-codes one of them, say it bakes in AWS KMS, then every shop that isn’t an AWS shop has to fork it to sign anything. And forking a framework to change one provider integration is the worst of all worlds: you inherit the maintenance, you fall off the upgrade path, and you’ve taken a clean dependency and turned it into a patched copy you now own. The place your users diverge most is the exact place a framework must not be opinionated.

The way out is an interface Go hands you for free: crypto.Signer. If you don’t write Go daily, the idea is simple and worth a sentence. crypto.Signer is the standard library’s name for “a thing that can sign,” and the trick is what it deliberately leaves out. It exposes a public key and a single Sign method, and it says nothing whatsoever about where the private key is or how the signing happens. The same interface covers a key sitting in memory and a key in a hardware module the program can never read, because from the caller’s side both look identical: you hand over a digest, you get back a signature, and you are never given the private key. It’s the same abstraction the standard library’s own TLS stack uses to serve HTTPS from an HSM-held key.

That’s what the whole design hangs on. The actual signing code, the part in pkg/openpgpkey that mints OpenPGP signatures, asks for a crypto.Signer and uses it. It has no idea, and no way to find out, whether the signer it’s holding talks to a local key, fires an API call at KMS, or lights up a YubiKey. It just signs. The dangerous, provider-specific bit and the boring, universal bit have been cleanly separated, and the only thing passing between them is “here’s something that can sign.”

Which leaves the question of how the right signer gets chosen, and that’s a small registry. A backend implements one method, NewSigner(ctx, keyID) (crypto.Signer, error), hands back a signer for whatever provider it speaks, and registers itself at startup, the usual Go pattern where a package’s init() calls Register and you pull the backend in with a blank import. gtb ships with two compiled in, a local one and an AWS KMS one. If your shop is the GCP or the Vault or the YubiKey case, you write a backend that satisfies that one interface, blank-import it, and you’re signing through it, without editing a line of framework code. You add a provider, you don’t fork a framework.

A couple of details fall out of doing it this way that I like more than I expected to. Backends don’t own credential resolution, the caller configures how you authenticate to the provider and the backend just turns a key ID into a signer, so the credential story stays where it belongs and the backend stays tiny. And because backends are compiled in rather than discovered at runtime, a binary built with none of them fails loudly and specifically, telling you it “was built without any signing backends compiled in” rather than mysteriously refusing to sign. You only carry the providers you actually asked for.

This sits underneath the more concrete signing stories, the one about a signature the platform that hosts you can’t forge and the one about why key generation moved into the tool in the first place. Those are about what signing buys you and why it has to be painless. This is the quieter architectural decision sitting beneath both: pick the one part of the problem that’s genuinely different at every org, refuse to decide it for them, and put a single clean interface where the decision would have gone. The framework signs everything the same way. It just never asks where the key sleeps at night.

Bought, not stolen

Tue, 23 Jun 2026 00:00:00 +0000

The malware that spent months wearing Microsoft’s trust didn’t steal a thing. No cracked certificate authority, no private key lifted off some breached vendor. There was, in effect, a shop: you uploaded your malware to a website, paid somewhere between five and nine thousand dollars, and got it back signed with a real, valid certificate. The same kind that vouches for the software you actually want on your machine.

The crew running that shop is one Microsoft’s Digital Crimes Unit tracks as Fox Tempest, and the certificates weren’t forged. They were minted through Microsoft’s own code-signing service, which Fox Tempest abused under a pile of fake identities and impersonated companies, then resold to anyone with the money. The malware they dressed up was the usual rogues’ gallery, the Oyster backdoor, the Lumma and Vidar infostealers, often got up as spoofed Teams or AnyDesk installers. In May, Microsoft pulled the operation apart: more than a thousand fraudulent certificates revoked, the infrastructure seized, a lawsuit filed against Fox Tempest and the ransomware crew behind Rhysida that had been paying for the service. For the better part of a year, a valid Microsoft signature was a product you could check out of a basket.

The reflex is to file this under “another supply-chain breach”. It isn’t one. Nothing was breached. The system did exactly what it was built to do, for a paying customer who’d lied about who they were. That’s the part worth sitting with.

We have been here before

None of this is new. I went back and read a Trend Micro write-up on code-signing abuse from 2018, and it could have gone out last week. Stuxnet carried valid signatures from stolen Realtek and JMicron certificates. After Sony Pictures was ransacked in 2014, the attackers signed their Destover malware with Sony’s own keys. The names rotate and the methods rotate, the story doesn’t: there is a trust mark, there is money in wearing it, so somebody works out how to wear it.

I’ve started thinking of them as honest villains. Not honest with their victims, obviously. Honest in their incentives: a rational operator who finds a loophole and works it for everything it’s worth, because there’s profit on the other side of it. You can be as furious at Fox Tempest as you like, and I am, prosecution is exactly right, but the honest villain is never the surprise. The honest villain is a constant. Build a gate worth getting through and one will turn up to test it… every single time! That isn’t cynicism. It might be the most dependable law we’ve got.

A seal was never a promise

Here’s the thing we keep forgetting about a signature, and it goes back a very long way.

For most of human history, trust was blood. You trusted the people you were bound to, by birth and by the pacts of kinship and marriage that held a tribe together. It worked, for tens of thousands of years, because the circle was small enough that everyone you needed to trust was someone you knew, or someone known to someone you knew. The bond and the accountability were the same thing. Betray the tribe and the tribe knew precisely whose door to come to.

Then we outgrew the tribe. We started trading with strangers, across distances and across lifetimes, with people we would never meet and could never vouch for by blood. And blood stopped being enough. So we built stand-ins for it. The wax seal pressed into a letter. The signature at the foot of a contract. The notary, the stamp, the certificate. Each one a small portable proxy for the bond of kinship we’d walked away from.

But look at what a seal actually did. A seal on a letter never told you the letter was true. It told you whose seal it was, which is to say it told you who to hold responsible if the letter turned out to be a lie. It was never a guarantee of honesty. It was a marker of accountability. It pointed at a person.

A code signature is the newest seal in that very old line, and it does the same single job. It does not tell you the software is safe. It was never built to. It tells you who signed it, which is to say who to come to when it isn’t. That’s the whole of it. The padlock in the browser, the green tick on the installer, the verified signature on a binary, none of them ever meant “this is good”. They meant “here is a name attached to this”.

The part you cannot sell

Which brings me to the uncomfortable bit, the one that points back at me as much as at Redmond.

If a signature is a name accepting responsibility, then the power to sign and the blame for what you sign are the same object. You don’t get one without the other. You cannot hold out the seal and quietly keep back the accountability behind it, because the accountability is the only thing the seal was ever made of.

That is exactly what came apart here. Microsoft holds enormous power as a signing authority, the power to make code look trustworthy to millions of machines. With that power comes the plain duty to check who you’re handing it to. They took the first part and skimped on the second. They sold the seal and skipped the diligence the seal is supposed to stand for, and the honest villain simply walked through the gap between the two.

And I have to hold myself to that very same rule, or I’ve no business naming it. I sign my own releases. Every go-tool-base release carries an OpenPGP signature over its checksums, made by a key that never leaves AWS KMS, with the public key published off-platform so the release host can’t quietly swap it. I do it so the people who use my tools, and they’re a varied bunch, can trust that what they’re running genuinely came from me.

But trusting me was never really the question. Here’s the one that keeps me up: what happens the day I’m the weak point? If a contributor slips something rotten into my code, or one of my own AI agents writes something it shouldn’t, and my automation dutifully signs it, then the signature does its job perfectly and the whole house of cards comes down. My users can trust me all they like. The seal will still say “Matt”, and it will be telling the truth, and that is precisely the problem.

So the accountability can’t be delegated, and I don’t try to. Nothing reaches my releasable branches without my own eyes on it first. No merge request, no commit, not from a contributor and not from one of my agents. The vigilance is mine, singularly, and that’s deliberate, because the blame is mine too, singularly, and they’re the same coin. It’s an easier thing to say as a one-man outfit than it’ll be if that ever changes. But the principle doesn’t get cheaper at scale. It just gets harder to honour, which is a very different thing from optional.

What standing behind it looks like

If you want to see the duty done properly, look at how OpenAI handled the Axios incident earlier this year. A poisoned dependency had got at the material used to sign their macOS app. They had every reason to believe their certificates were fine. They revoked them anyway, and rebuilt, because the cost of being wrong was their users’ machines and their own name on the door. That’s what holding the power looks like. You act on the possibility of compromise, not the proof of it, because by the time you’ve got proof it’s already on somebody’s laptop.

It’s also why I’ve come to treat trust as layers rather than a single tick in a box. The release signature is one layer. Notarisation is another: every macOS binary go-tool-base ships is notarised by Apple as well, and has been for a good while. There will be more, and the Rust side of my tooling has its own signing coming very soon. None of them is the answer on its own. Each one is just another check, another name standing behind the thing. And the part I care about most, as someone who builds tools other people build on, is handing that same machinery to them, so they can stand behind their own releases for their own customers instead of trusting that someone, somewhere up the chain, did the diligence.

Vigilance, still

I’d love to tell you there’s a clean technical fix on the way, a trust system the honest villain can’t game… There isn’t. We’ve tried plenty, and some have aged better than others. (I’m looking at you, blockchain, the confident answer to a question almost nobody was asking!) Whatever we build next, the same loop runs: the mechanism gets more elaborate, so the attacks on it get more insidious, so the mechanism gets more elaborate again. We have spent the whole of human history moving trust further and further from the blood bond that used to ground it, and every step we take away from a person who will answer for it, the honest villain takes right alongside us.

Maybe there’s a version of the future where this stops… some distant place where nobody needs to cheat because nobody wants for anything, and greed has quietly retired. I’m not holding my breath. Until then the job is the plodding one it has always been: stay vigilant, act before you’re certain, and keep trust as close as you can to a person who’ll stand behind it. Because that is the only thing a seal ever was. Not a promise that the thing is good. A name, and someone willing to answer to it.

Release trust without the framework

Sun, 05 Jul 2026 00:00:00 +0000

A few days ago I shipped afmpeg and ffmpeg-wasi, a way to run FFmpeg as a WebAssembly module straight from Go with nothing installed on the host. afmpeg fetches that wasm module at runtime and then… runs it. A lovely trick, right up until you ask the obvious question: how does afmpeg know the wasm it just pulled off the internet is the one I built, and not something swapped in on the way down?

It has to check a signature. And I already had the machinery to do exactly that… it was just bolted to the inside of go-tool-base.

So I pulled it out. Two new modules, both public: signing and signing-aws-kms.

The part I lifted out

signing is the OpenPGP/WKD signing-and-verification model the rest of my tools already lean on. It’s the same code behind gtb update when it checks its own releases, lifted out into a standalone module you can drop into any project. Verify a signed release, or sign your own, and you do it without dragging the whole go-tool-base framework (and its dependency tree, which is not small) in behind it.

That last bit is the whole reason it’s a separate module and not just a package. Go has a rule here that trips people up: when your code imports a package, you inherit that package’s entire module dependency list… the full go.mod, not just the corner you actually touched. So lifting one tidy little package out of go-tool-base into a sub-package would still have handed every consumer viper, OpenTelemetry, the whole charm stack, the lot. Only a separate module, with its own minimal go.mod, keeps that weight off your build. The core here leans on ProtonMail’s go-crypto and cockroachdb/errors, and nothing else.

The backend you inject

Signing needs a key, and keys live in awkward places: a PEM file on disk, a YubiKey, AWS KMS, GCP, Azure, a Vault. The remote ones drag in heavy SDKs. The AWS KMS client alone pulls in 57 modules, and I really didn’t fancy that sitting in the core where everyone pays for it whether they ever touch KMS or not.

So signing doesn’t implement those backends at all. It defines an interface (a thing that hands back a crypto.Signer) and lets you inject whichever backend you actually use. A light local backend (a PEM key on disk) ships in the box, as a sensible default and a worked example of the shape. The heavy ones are separate modules you opt into, one at a time.

signing-aws-kms is the first of them. It wraps a KMS-held key as a signer, so the private half never leaves AWS and every signature is a round-trip to the cloud. Blank-import it and it registers itself. GCP, Azure and Vault will follow the same pattern, and because each is its own module, your binary only ever carries the one you reached for. And if none of them fit? The interface is right there for you to write your own.

The proof, already running

This isn’t a library out looking for a user. ffmpeg-wasi signs its release assets in CI right now, with a KMS key driven through the go-tool-base CLI, and afmpeg verifies that signature against an embedded key before it hands a single byte to the runtime.

No valid signature, no run.

The thing that needed the trust and the thing that provides it are two separate projects, talking to each other through a signature.

The verifying key isn’t only baked into afmpeg, either. It’s published to WKD on my own domain, so the anchor you check against lives somewhere my git host has no say over. A signature is only ever worth as much as the key you check it against, and pinning that to my own domain rather than the platform that hosts my code is a deliberate bit of the posture, not an accident of wherever a file happened to be convenient to drop.

Where it leaves things

Two more modules out in the world, both public, both documented over at signing.phpboyscout.uk. The selfish win is that afmpeg got to trust its own downloads without me reinventing a single thing to do it. The broader one is that the signing model I keep banging on about is no longer something you have to swallow my entire framework to use. Take the part you want, and leave the rest on the shelf.

One key, or two?

Wed, 05 Aug 2026 00:00:00 +0000

The Rust toolkit needed to sign its own release binaries, and I had this pencilled in as an afternoon. Precompiled cargo-bin crate assets are conventionally signed with Ed25519, everything I own is signed with an RSA key that never leaves AWS KMS, and so the question was just… does Rust get its own key, or can it use the one I already have?

It was not an afternoon.

Because two keys means two places a private key lives, two rotation procedures, and two things to remember. One of which is definitely going to be the one I forget.

Why Ed25519 in the first place

Worth saying, because it never made it into the original ticket and it’s the thing that makes the rest of this make sense. Ed25519 is what the Rust ecosystem’s tooling is built around, and conventions are rather the point when the person doing the verifying isn’t you.

You can bend RSA into that shape, mind. It’s a faff, it isn’t considered best practice, and you end up standing outside every assumption the tooling makes… which is a lovely way to build something nobody can check without ringing you up first.

Three walls, stacked

They turned up one behind the other, the way these things do, and each one looked final on its own.

The backend simply refused. Our KMS signing backend parses the public key and hard-rejects anything that isn’t RSA. Which is fine, until you look at why: sitting right next to that check were two comments explaining that KMS doesn’t expose Ed25519 at all.

And that was true. Once. I picked it up somewhere years back, from a source I couldn’t name for you now, and I wrote it into our own documentation as settled fact. Then I did the thing everybody does with their own documentation, which is believe it. Meanwhile AWS got on with being a competent cloud provider and shipped Ed25519 support at the tail end of 2025, and I never went back to look. Why would you? You wrote it down.

So the guard in my code was defending against a limitation that had stopped existing, and the tidy explanation sitting next to it was the exact reason nobody ever poked at it. My own note, in my own repo, in my own words, wrong for months.

RTFM, kids! Then read it again next year, because the M keeps changing and your notes don’t.

The proof turns up the moment you mint a key and try to use it:

ERRO constructing signer: KMS key is ed25519.PublicKey:
 KMS key is not RSA; only RSA SIGN_VERIFY keys are supported

The containers disagreed. Our signing stack for Go was built around OpenPGP, and emits it armoured. The Rust side wants a raw 64-byte signature or a minisign file, and hasn’t got an OpenPGP parser anywhere in it. Same maths, completely different envelope, and no amount of goodwill gets one to read the other.

And then the size cap. KMS will sign a message of at most 4096 bytes. Release artefacts are megabytes. There’s a prehashed Ed25519 mode that looks for all the world like the way round it, and isn’t: it’s a different algorithm, not a size escape, and the two can’t be swapped for each other.

Stack all that up and the conclusion rather writes itself. KMS can’t sign the artefact, so the Rust key has to be a software key, sat somewhere less protected than the HSM everything else lives in.

That was the design. Written up, cited, and about ten minutes from agreed.

The bit I was stubborn about

Two things stopped it, and neither was clever. First, I asked for the receipt on the one claim holding the whole thing up: the 4 KB cap. Show me that in the docs. Second, and this is the one that mattered, I refused to treat everything around the problem as fixed. Was signing the binary really the only mechanism open to us? We own the updater. We can change how it works… nobody handed that down on a stone tablet.

That second question is what cracked it, because answering it meant somebody had to write down what minisign actually does, rather than what it’s for. And there it was, sat in one sentence:

The file is first hashed with BLAKE2b-512, then Ed25519 signs that 64-byte digest.

Sixty-four bytes.

Nobody signs the file. Nobody has ever signed the file! The thing that goes to the signer is a digest, and a digest is three orders of magnitude inside the limit that had spent two days doing a very convincing impression of a brick wall.

And here’s the bit that still bothers me: every fact in the way was true. The 4 KB cap is real. The prehashed variant really is a different algorithm. The artefacts really are megabytes. The error was in the join, applying a constraint to the file when the file was never the thing crossing the boundary. That’s a lot harder to spot than something invented, because every citation you chase comes back clean and you end up more convinced, not less. I’ll write that one up on its own, it deserves more room than I can give it here.

So: one key, or two? One. Go binaries, wasm modules, ONNX models and Rust crates all sign against the same root, and there’s one rotation to remember instead of two.

So, sigillum

Which left a tool to build, because none of the above helps a Rust pipeline if the only way to run it is to install a Go CLI framework first.

sigillum is a single binary that signs things and manages the keys it signs with.

sigillum sign <file> # detached, ASCII-armoured OpenPGP signature
sigillum sign --format minisign # ...or minisign, for the Rust side
sigillum keys generate # a fresh Ed25519 or RSA keypair
sigillum keys mint # an OpenPGP public key from an existing signer
sigillum keys wkd # a Web Key Directory tree from your public keys

The private key never leaves the KMS, the HSM or the local PEM file, and the backend registry underneath is the same one the framework has always used.

The commands didn’t move. They got a second front door.

This is the bit I’d have got wrong reading it from the outside, so let me be precise about it.

gtb sign and gtb keys still exist. Not deprecated, not relocated, not reimplemented. If you use them, nothing has changed and you can stop reading this section.

What moved is where the command definitions live. They came out of the framework and into go/signing-cli, a small module sat between go/signing (where all the real logic has always lived) and anything fancying a command surface on top of it. It exports constructors, NewCmdSign, NewCmdKeys and friends, each taking a logger and handing you back a plain cobra command.

go-tool-base then mounts them, in its own root:

setup.Wrap("", signingcli.NewCmdKeys(p.GetLogger())),
setup.Wrap("", signingcli.NewCmdSign(p.GetLogger())),

And sigillum mounts the same constructors, at the top level, as its whole reason for existing.

So these aren’t two implementations held in step by discipline and hope. They’re the same commands, compiled into two binaries, versioned as a module. Fix a flag once and both get it.

Why its own module, rather than a package tucked inside the framework? The dependency graph, basically. In gtb those were internal commands because gtb is both a library and a CLI, so it could comfortably carry the pair. sigillum is a pure CLI with shareable commands and all the real logic stays down in go/signing. Sticking the definitions in the middle is what heads off the cyclical reference nightmare every other arrangement walks straight into.

Commands feel like glue. Like the bit of your binary that isn’t really code, just wiring. Pull them out and version them and it turns out they’re a library like anything else… and once they are, the second tool costs you almost nothing.

The name

The working title was signctl. Descriptive, forgettable, and about the four hundredth thing in this space named after what it does.

Signing tools are not exactly an empty field! Between cosign, minisign, signify, notary, gpg and everything orbiting sigstore, there’s no arrangement of “sign” and a suffix left that isn’t either taken or one letter off something taken. You start reaching for the second syllable and every door’s got a name on it already.

Sigillum is Latin for a seal. It sits with the other things round here that got a name rather than a label (keryx the herald, krites the judge), and a wax seal was already the visual language every signing post on this blog had been leaning on anyway, so mostly I was catching up with my own cover art.

There is, I found out afterwards, already a sigillum on crates.io. Different ecosystem, different problem, and I’m relaxed about it. Naming is mostly the art of finding something that isn’t too taken.

sigillum is at v0.2.2, with docs at sigillum.phpboyscout.uk. It’s a rubber stamp. After a fortnight of arguing about elliptic curves, that is precisely what I wanted it to be.

PHP Boy Scout — Signing your releases

Sign your own binaries with go-tool-base

What you’re protecting against

Two paths through it

Before you start

The parts

Nobody's coming to clean your supply chain

A signature proves the sender, not the contents

It was never just npm

No registry can hand you a clean package

The boring discipline that actually helps

The same shape, a third time

Sign your own binaries with go-tool-base, part 1: sign and verify on your laptop

Make a signing key

Mint the public key you’ll actually publish

Sign something

Verify it, two ways

Where this leaves you

Sign your own binaries with go-tool-base, part 2: a signing key in AWS KMS

What you’ll need first

The module

What you just built

Four principals, one key policy

The outputs you’ll carry forward

What this costs

Where this leaves you

Sign your own binaries with go-tool-base, part 3: keyless CI signing with OIDC

Where the identity provider comes from

The GitLab path

The GitHub path

The gotcha that wastes an afternoon: token audience

Where this leaves you

Sign your own binaries with go-tool-base, part 4: mint and publish your public key

Mint the public key from KMS

Mint the rotation authority while you’re here

Build the WKD tree

Publish it somewhere the platform can’t reach

Where this leaves you

Sign your own binaries with go-tool-base, part 5: embed the key and require verification

Enable signing with one command

Drop your key in

The WKD cross-check, via --email

Confirm the cross-check is actually firing

Require it, in the right order

Where this leaves you

Sign your own binaries with go-tool-base, part 6: sign every release with GoReleaser

One command wires the signing in

Why only the checksums

No shim, just gtb

Where the credentials come from

Don’t sign when there’s nothing to sign with

Cut a release

A two-person gate, if you want one

Where this leaves you

Sign your own binaries with go-tool-base, part 7: rotation and break-glass

Why there’s no auto-rotate button

Rotate by minting a new key, never by changing the old one

The dual-publish, dual-sign window

The break-glass key, for when there’s no handover

The whole chain, end to end

A signature the platform can't forge

The thing a checksum can’t do

The crypto is the easy part

Pulling the two questions apart

Three answers to “where does the key live”

The separation is the whole point

Requiring it, without breaking everyone

What it actually buys

A signing key that never leaves KMS

The only key you can’t steal

A key that’s born in the box and stays there

Minting an OpenPGP key from a key you can’t hold

Access without a human and without a standing key

The real cost: rotation is manual

Why this is a command and not a script I hid

Where this leaves the whole story

The gpg command that hung (so I built signing into the tool)

The framework doesn't know where your signing key lives

Bought, not stolen

We have been here before

The WKD cross-check, via `--email`

No shim, just `gtb`