Binary Caches & Trust

Binary caches are treated as speed boosts. They aren’t. They are part of your trust model.

When you fetch an artifact from a cache, you wager that it was built honestly, matches its declaration, and hasn’t been tampered with. It is a supply chain decision.

If you don’t build everything yourself from declared inputs, you’re accepting a prebuilt artifact from a third party. This raises obvious questions:

• Who built it?
• What environment was it built in?
• Were there any hidden or impure inputs?
• Was the builder trustworthy?
• Does the artifact really match the derivation?
• How is integrity checked?
• Who controls the signing keys?

If you can’t answer these, you’re not just using a cache - you’re inheriting trust from a black box. It’s easy to think a cache hit is always good news. It just means you skipped some work, not that you gained confidence. Confidence comes from knowing:

• which caches you’re using
• which keys you trust
• who runs the cache
• what their build policies are
• whether you should build sensitive stuff yourself

The more critical the software, the less you can ignore these questions.

Nix verifies that a binary was signed by a trusted key. That is necessary, but it only proves someone vouched for it. It says nothing about the build itself.

A signed artifact can still be:

• built with impure or unknown inputs
• built on compromised builders
• built from a broken derivation
• built under policies you would never accept

A signature is not proof of integrity. It is an endorsement. Crypto checks are necessary, but they don’t replace an audit.

Not every package carries the same risk. A throwaway dev tool? Maybe you’re fine with a public cache. Production code, regulated systems, or sensitive data? Build them yourself or use a cache you control. Reasonable strategies:

• use public caches for low-risk stuff
• use your own cache for internal software
• build sensitive things locally or in trusted CI
• keep developer convenience separate from production safety

This isn’t paranoia - it’s just recognizing that where your software comes from matters. A cache shouldn’t just show up in your config because a guide said so. It should be a deliberate part of your policy. If you use a cache, be clear about:

• which caches are allowed
• which keys are trusted
• which packages can be substituted
• which must be built under stricter rules
• who reviews cache config changes

If you don’t have answers, you don’t have a trust model. You just have a shortcut to production.