Provider signing

Early access. Registry is rolling out behind an organization flag.

The Terraform provider protocol makes signatures mandatory: before it installs a release, a client verifies a detached GPG signature over the release’s checksums. Longbridge holds the key and signs for you, so you never touch GPG — not on your machine, not in CI.

Modules aren’t signed; this page is about providers.

Managed signing

When you publish a provider, Longbridge derives the SHA256SUMS from your uploaded zips, signs it with your registry’s managed key, and advertises the public key alongside the release. The consumer’s terraform init / tofu init verifies it automatically — they configure nothing.

The key is a per-registry RSA-3072 GPG key, generated non-exportable inside a key-management service (KMS). There is one key per registry, and its advertised public half becomes that registry’s signing identity.

What the signature protects

Longbridge Registry is private: every pull is authenticated and attributable to an Org, and a published provider is consumed by that Org’s own workloads (or ones it explicitly shares with). So the signature’s job here is integrity and provenance inside a boundary the platform already mediates — “this is the artifact your authenticated publish pipeline produced, unmodified” — not defending the anonymous internet against a malicious publisher. Managed signing delivers exactly that.

A publisher-held key would add one further property — that the operator itself cannot forge a release — which a narrower set of teams needs. Bring-your-own-key is a planned follow-on for attestation-strict and migrating publishers; managed signing is the default.

Key lifecycle

• Minted on first publish. The key materializes the first time you publish a provider into a registry. A registry that holds only images or modules never mints one.
• Rotate — for hygiene. Rotation flips the registry’s current key: new releases bind the new key, and the old private material is destroyed in KMS immediately. Existing releases keep the signatures they already have, and each key’s public half stays advertised as long as a release still binds it — so rotation is cheap and safe to run routinely.
• Revoke — for a compromise. Revocation mints a fresh key and re-signs every release bound to the compromised one, then disables the old key in KMS. The zips and checksums are untouched — only the signatures and the advertised public key change. Consumers that already recorded hashes in .terraform.lock.hcl are unaffected; new consumers get a clean signature immediately.

Each release records the key it was signed with, so the registry always advertises the matching public key for every version. Rotate and revoke are admin-tier actions, audited under registry.*.

Where to next

• Publishing modules and providers — where the key is first minted.
• Consuming modules and providers — the automatic verification on the consumer’s side.