Backends and the per-provider module pattern¶

signing defines the signing mechanics and the Backend contract; the actual keys live behind backends. A Backend produces a crypto.Signer for a held key:

type Backend interface {
    Name() string
    NewSigner(ctx context.Context, keyID string) (crypto.Signer, error)
}

The library ships one backend — local (PEM on disk) — as a light default and reference. Every other backend lives in its own module and is activated by a blank import.

Available backends¶

Planned (same pattern): GCP KMS, Azure Key Vault, HashiCorp Vault. To build one, see Implement a custom backend.

Why a module per provider¶

Go's module-graph pruning propagates a module's whole go.mod require list to any consumer that imports a package from it. If every backend lived here (or in one multi-cloud module), every consumer would inherit every cloud SDK. Separate per-provider modules quarantine each SDK, so a consumer pulls only what it uses:

Using a backend¶

Blank-import to register, then resolve by name:

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

backend, _ := signing.Get("aws-kms")
signer, _ := backend.NewSigner(ctx, keyARNorAlias)

To add your own, see Implement a custom backend; signing-aws-kms is the reference implementation.