Nix store signatures cover substitution trust, not every build input

Nix store signatures are effective in establishing trust for substitution, but they do not guarantee trust for every aspect of the build process. When a machine retrieves a path from a binary cache, the store requires a signature from a trusted key to ensure the path's integrity. This control is crucial because a cache can distribute prebuilt binaries that are subsequently executed.

However, it is essential to understand that this signature check does not provide absolute assurance that every input, builder, or source expression is trustworthy.

The Nix configuration documentation indicates that the default setting for require-sigs is true. For non-content-addressed paths added to the store, a signature must be provided by a key present in the trusted-public-keys list or by a private key listed in secret-key-files. If require-sigs is set to false, all such paths are trusted without undergoing signature verification. Content-addressed paths, on the other hand, have distinct trust characteristics, and some store types may treat unsigned paths differently.

The list of trusted keys constitutes the policy in this scenario. A key that signs a malicious path holds the same level of trust as a key that signs a legitimate path. Key distribution, rotation, and revocation procedures should be reviewed in conjunction with substituter URLs. The nix store verify command can verify that paths possess trusted signatures, and its options can mandate a minimum number of signatures for verification.

Verification of a local path does not retroactively confirm the safety of the build expression or every source input. To ensure the effectiveness of this security measure, several scenarios warrant testing. A signed path originating from an untrusted cache will be rejected. An unsigned non-content-addressed path will be rejected if require-sigs is set to true.

A path signed by a trusted key will be accepted. However, a path with a revoked or removed key will no longer comply with the policy. Content-addressed paths adhere to the documented trust path and should not be conflated with signed non-content-addressed paths.

The trusted substituter list is designed to prevent the inadvertent inclusion of unexpected caches. The risk associated with the build host is separate from the risk posed by the store. A signing key that remains on a build server can sign outputs generated from compromised source code or a malicious builder. While the store signature attests to the involvement of a key holder in supplying the path, it does not establish the completeness of the source review process.

Provenance, reproducible builds, and source review are complementary controls that work together to enhance system security.

It is important to note that a cached signature does not guarantee a secure build if the signer's pipeline is compromised. Operators should record the effective substituters, trusted-public-keys, require-sigs settings, and nix store verify policy. Testing should be conducted using a disposable path instead of modifying production trust configurations.

Regular key rotation with an overlap window is recommended, and operators should verify that old keys cease functioning as trust anchors when the configured list changes. Ultimately, Nix signatures help make binary substitution auditable and enforceable, treating them as a trust boundary around cache content. Simultaneously, the build system and key custody should be considered as separate components of the overall supply chain.