Nix does this simply and stupidly --- if you can observ it, it's part of the cache key.

This is wonderful because it's totally sound. All efficiency methods (basically, hiding things, as the other comment says) is left to the build plan itself.

Switching to Nix for batch jobs is switching from DOS to an OS with actual process isolation. A complete paradigm shift.

It does still require trust, though. You can lie about the contents since the hash only covers the build inputs, so someone could break the sandboxing.

Of course, since builds are reproducible you can catch this if you build it yourself and compare the actual content-hashes.

I would say the trust issues with build remotes and substitutors are fairly independent of the caching policy?

The caching model is about when the drv changes ((drv, output) is the cache key, basically), the trust model is one one can download something to avoiding build to fill in the value for the new cache key.

Note also that with the new floating content-addressed derivations, the trust stuff is much easier to think about.

The most "proper" way to do this is splitting the result into interface + implementation. For example if you are dynamically linking to a library instead of being given access to the entire library you are given a simplified "signature" which has the minimal amount of info required to linking. This interface would change when you add or remove a function, but not when a function body changes.

The example was given for linking but this can be done for many steps of the build process.