Isolated builds and build caches

[joshuagl]

Part of the Isolated build requirement is that:

Build caches, if used, MUST be purely content-addressable to prevent tampering.

At SLSA level 4, where hermetic is also a requirement, this would be scoped to only include caches which are provided by the build service (as any external dependencies must be pre-fetched and networking disabled).

However, this requirement can be interpreted in such a way that it makes SLSA level 3 extremely difficult to obtain for open source projects on GitHub (ref #185) because many "caches" of artifacts (i.e. dependencies in ecosystem package managers) are file addressed.

I think this item of the isolated requirement is focused solely on outputs of the build process which are cached between build steps (i.e. actions/cache), but wanted to seek clarity from others. Any thoughts/opinions?

[MarkLodato]

I'm actually not sure of the purpose of the current wording. @dlorenc could you perhaps explain a bit more of the rationale?

In my mind, the following already covers this issue:

It MUST NOT be possible for one build to persist or influence the build environment of a subsequent build.

Is that the only concern, i.e. that one build instance "poisons" the cache so that a subsequent build uses a bad dependency? If so, how does content-addressibility help? Or is it a different concern?

If actions/cache does not satisfy this property, I'm hesitant to weaken it to allow that to meet level 3. I suspect that most releases would be fine disabling the cache because they're infrequently. It's really just continuous integration that needs a cache because it runs frequently, but those don't need to be SLSA-ified. What do you think?

[dlorenc]

I think I was worried about a specific issue with the GitHub actions cache, where someone had pointed out a few cross-build cache-poisoning attacks.

I'd have to dig it up to see the exact attack.