Official signatures

Why signatures

Catalog adversaries are executable code. The CLI allows host execution (full user privileges) only when it can cryptographically verify that Adversary Labs endorsed the exact artifact bytes you are about to run.

Trust is not granted by:

• registry hostname alone;
• namespace or catalog path strings (for example go/security or adversarylabs/...);
• successful login; or
• the fact that a package was previously pulled to disk.

Trust is granted when either a valid official signature verifies for the immutable content digest using a public key baked into the CLI, or a hosted private package has a valid team key delegation and namespace signature.

See also the execution trust model.

What users need to know

Typical flow:

brew install doomerlabs/tap/doomer   # release binary embeds official-prod
doomer login
doomer pull go/security                # fetches content + signature referrer
doomer run go/security --path .      # verifies signature → host allowed

If you run a package without a valid artifact signature:

Untrusted adversary "…"
Digest: sha256:…

No valid artifact signature is available for this package. Host execution will
run unrestricted code with your user privileges (filesystem, network, etc.).

Run anyway? [y/N]

Non-interactive environments fail unless you pass --allow-unsafe-host-execution or use a capable sandbox executor.

Model

The platform service holds ADVERSARY_NAMESPACE_SIGNING_ROOT_SEED (32 random bytes encoded as 64 hex characters). It derives domain-separated Ed25519 keys for the delegation root and each stable team ID. This secret must be provisioned before releasing a CLI that enables automatic private signing and must never be placed in a publisher or runner environment.

Dev vs production keys

A released CLI cannot verify packages signed only with the dev key, because that public key is not present in the binary. Build tags keep keys out of the wrong artifact (an environment variable alone would still ship both).

# Everyday development (dev key only)
go build -o adversary .

# Release-shaped binary (prod key only) — matches Homebrew builds
go build -tags release -o adversary .

Envelope

Media type: application/vnd.adversarylabs.official-signature.v1+json

{
  "specVersion": 1,
  "subjectDigest": "sha256:…",
  "keyID": "official-prod",
  "signedAt": "2026-08-01T12:00:00Z",
  "signature": "<base64 ed25519 signature>"
}

Signed message (exact bytes):

adversarylabs-official-sig-v1
<subjectDigest>
<keyID>
<signedAt>

Verify path in the CLI

1. doomer pull resolves the digest, installs content, fetches the signature referrer, verifies with this binary’s keyring, and stores the envelope under official-signatures/ in the local repository.
2. doomer run sets official-signed trust when verification succeeds for that digest, then allows HostExecutor.

Offline runs use the stored signature; re-pull if the package was installed before signatures were published.

Catalog release signing

Official free-catalog packages are signed in Depot release workflows after a successful push:

1. Bump manifest and push the OCI artifact.
2. Install the CLI (go install github.com/doomerlabs/doomer@main).
3. Log in with the service account.
4. Run doomer sign <remote-ref> --digest <subject> --key-id official-prod with the production signing material from CI secrets.

End users only need a current release CLI.

Signing for maintainers (dev and CI)

Signing material is supplied with --seed or ADVERSARY_OFFICIAL_SIGNING_SEED.

# Local dev catalog (Doppler injects the dev seed via package Makefile)
make sign-dev REF=localhost:8787/go/security:0.0.12

# Or invoke the CLI directly
doomer sign localhost:8787/go/security:0.0.12 \
  --seed "$ADVERSARY_OFFICIAL_SIGNING_SEED" \
  --key-id official-dev

# Production (CI only)
doomer sign registry.doomer.ai/go/security:0.0.12 \
  --digest sha256:… \
  --key-id official-prod

Secrets layout (operators)

Same secret name in every environment; values differ by environment:

Notation, Cosign, and TUF

• Notation / Cosign: optional later for CI interop; end users still only need this CLI.
• TUF: later for key rotation without shipping a new binary for every key id.

Migration notes

• Catalog packages that predate official signing must be re-released and re-pulled before host trust applies without overrides.
• Local source projects (explicit path) remain trusted by path selection and do not require signatures.
• Private packages in a team namespace on registry.doomer.ai become trusted after their platform-issued namespace signature verifies. External registry copies, including GHCR, remain untrusted by default.