Spack Buildcache GPG Signing: Trust Configuration Uncertainty for Low-Traffic Sites

Direct answers

1. Version: I cannot confirm which Spack release introduced the current spack buildcache keys trust subcommands. The research flags this as version-sensitive; confirm with spack --version and spack buildcache keys --help before scripting.
2. Mixing signed and unsigned entries: Spack does not inherently refuse a mixed cache. Verification is per-entry and depends on whether the client trusts the signing key and whether policy requires signatures. Unsigned entries remain unverified. --cache-only still fails on any exact-hash mismatch (compiler, flags, target, externals) even when signatures are valid, so mixing does not break --cache-only by itself, but it leaves unsigned binaries without integrity guarantees.
3. Minimal rotation for two people: Use one offline, passphrase-protected key pair on a dedicated publish host. Distribute the public key to clients and mark it trusted. Sign every published binary; do not publish unsigned entries if trust is enforced. To rotate, add the new public key to client trust stores, sign new caches with the new private key, and retire the old key only after old-signed entries are no longer consumed. Rotation is not retroactive: a compromised private key invalidates all previously signed caches.

Confirmed facts vs. assumptions

--cache-only forces installation from the binary cache and fails on a miss; --use-cache falls back to source. In both cases the concretizer resolves the full dependency DAG, and a cache hit requires an exact spec hash covering compiler, flags, target, and externals. GPG signing is optional in Spack; unsigned publication is simpler but provides no integrity or authenticity guarantee.

Uncertain items: exact spack buildcache keys subcommand names, whether unsigned entries are rejected by default when trust is enabled, and the exact trust flag names. These must be verified against the installed release.

Steps for this case

1. Collect spack --version from the publish host and a client node. This detail changes the recommendation because command names are release-dependent.
2. Run spack buildcache keys --help and spack buildcache --help on the target Spack version to confirm trust subcommands and flags.
3. On the dedicated publish host, create one passphrase-protected key pair using the confirmed spack buildcache keys subcommand.
4. Export the public key, distribute it to clients, and add it to the client-side trust store using the version-confirmed command.
5. Configure the publish pipeline to sign every cache entry and disable unsigned publication if signature enforcement is required.
6. Test with spack install --cache-only SPEC against a known-cached spec, and compare spack spec --hash SPEC to the cached binary path to confirm exact-hash matching is the gate.

Verification

• spack --version
• spack buildcache keys --help
• spack buildcache --help
• spack spec --hash SPEC
• spack install --cache-only SPEC in a non-production test environment

Missing diagnostic detail: the output of spack --version. Provide it before adopting specific spack buildcache keys syntax in automation.