Compile in signing backends¶

The sign, keys mint and keys minisign commands resolve their --backend value against the go/signing registry. This module registers no backend itself. The host binary decides which backends exist by blank-importing them in its main package, and this guide shows how.

Background on why activation works this way is in Backends are the consumer's responsibility.

Blank-import the backends you want¶

Each backend registers its name from init(), so importing the package for its side effect is all it takes:

package main

import (
    _ "gitlab.com/phpboyscout/go/signing-aws-kms" // registers "aws-kms"
    _ "gitlab.com/phpboyscout/go/signing/local"   // registers "local"
)

The local backend accepts either an RSA key or an Ed25519 key, and the key type decides which signature format is available: RSA drives sign --format openpgp and keys mint, Ed25519 drives sign --format minisign and keys minisign. Encrypted PEMs and ECDSA keys are refused. See What signing-cli does not do for why one key cannot do both.

With both imports present:

your-tool sign --backend local   --key-id ./release.pem --public-key release.asc checksums.txt
your-tool sign --backend aws-kms --key-id alias/release-signing-v1 --kms-region eu-west-2 \
    --public-key release.asc checksums.txt

Backend-specific flags such as --kms-region appear in --help automatically when a backend that declares them is compiled in. The commands type-assert each registered backend for an optional RegisterFlags(*pflag.FlagSet) and let it add its own flags. This happens on sign, keys mint and keys minisign; the three commands that never touch a backend (keys generate, keys wkd, keys publish) do not gain them.

Use two configurations of one backend¶

The same imports also make named instances available. Both backends above register a factory (aws-kms from signing-aws-kms v0.6.0), so a selector such as aws-kms:prod mints a separate instance that takes its settings inline instead of from the top-level flags:

your-tool sign --backend 'aws-kms:prod?kms-region=eu-west-1' \
    --key-id alias/release-signing-v1 --public-key release.asc checksums.txt

Combining a named instance with --kms-region is an error, not a fallback. The full grammar and its rules are in Selecting a backend.

Keep the imports in one file¶

go-tool-base isolates its backend imports in a single file so there is one place to change the binary's signing capabilities. Apart from a comment explaining itself, cli/cmd/gtb/signing.go in the go-tool-base repository is only this:

package main

import (
    _ "gitlab.com/phpboyscout/go/signing-aws-kms"
    _ "gitlab.com/phpboyscout/go/signing/local"
)

Copy that pattern in your own main package: a dedicated signing.go (or similar) that holds only the blank imports. It makes the "which backends does this build ship?" question answerable at a glance, and makes dropping one a one-line edit.

Dropping a backend (FIPS / regulated builds)¶

Because a backend's heavy dependencies (the AWS SDK, for aws-kms) enter the module graph only through its blank import, removing the import and rebuilding removes the SDK from the artefact; linker dead-code elimination does the rest. No code in signing-cli or in your command wiring changes; the aws-kms name simply stops appearing under --backend.

go-tool-base proves this with a dedicated cli/cmd/gtb-no-aws-smoke binary that omits the KMS import specifically to assert the AWS SDK is not pulled in transitively by signing-cli or the command wiring. If you maintain a constrained build, an equivalent smoke binary plus a dependency assertion is a worthwhile guard.

Adding your own backend¶

Any backend is a type implementing go/signing's Backend interface (Name() and NewSigner(ctx, keyID)), registered from init() via signing.Register. Put it in its own module, blank-import it here just like the built-ins, and it shows up under --backend. The full recipe lives in the go/signing docs: Implement a custom backend.

See also¶

• Attach the commands to a CLI, to wire the commands onto your root.
• Backends are the consumer's responsibility: the design rationale.
• Configuration and environment: the AWS environment variables the aws-kms backend resolves credentials from.