Nix store signatures cover substitution trust, not every build input
Nix stores build outputs as paths with hashes and metadata. When a machine downloads a path from a binary cache, the store can require a signature from a trusted key. That control is important because a cache can serve prebuilt binaries that are later executed. It is not a blanket proof that every input, builder, or source expression is trustworthy.
The Nix configuration documentation says require-sigs defaults to true. A non-content-addressed path added to the store must have a signature by a key in trusted-public-keys, or by a private key listed in secret-key-files. Setting require-sigs to false trusts all such paths without signature checking. Content-addressed paths have different trust semantics, and some store types can treat unsigned paths differently.
The trusted key list is the policy. A key that signs a malicious path is trusted just as much as a key that signs a legitimate one. Key distribution, rotation, and revocation belong in the same review as substituter URLs. nix store verify can check that paths have trusted signatures, and its options can require a minimum number of signatures. Verification of a local path does not retroactively prove that the build expression or every source input was safe.
Several scenarios deserve testing:
- A signed path from an untrusted cache is rejected.
- An unsigned non-content-addressed path is rejected when
require-sigsis true. - A path signed by a trusted key is accepted.
- A path with a revoked or removed key no longer satisfies policy.
- A content-addressed path follows the documented trust path and is not confused with a signed non-content-addressed path.
- The trusted substituter list does not silently include an unexpected cache.
The build host has different risk. A signing key that remains on a build server can sign outputs produced from compromised source or a malicious builder. The store signature attests that a key holder supplied the path, not that the source review was complete. Provenance, reproducible builds, and source review are complementary controls. A cache signature can still carry a bad build if the signer's pipeline is compromised.
Operators should record the effective substituters, trusted-public-keys, require-sigs, and nix store verify policy. Test with a disposable path rather than changing production trust. Rotate keys with an overlap window, and verify that old keys stop acting as trust anchors when the configured list changes.
Nix signatures make binary substitution auditable and enforceable. They should be described as a trust boundary around cache content, with the build system and key custody treated as separate parts of the supply chain.
Top comments (0)