slsa-framework
Clarifying common builder pitfalls regarding source material reporting
@msuozzo and I had a discussion on a potential builder pitfall when reporting source material in the build provenance.
With a "regular" git clone, the entire history of the repo is pulled. So if builders do that and kick off the build process, it has effectively supplied the build process every commit of the source repo. The build process could on-the-fly derive a different commit ID and build things from there, which become a source dependency that is "off-the-book" of the build provenance.
To fulfill the dependency completeness requirement (which was in SLSA v0.2, and I guess may come back in the future?), the builder probably should instead perform "shallow (tree-less?) clone", only fetch the data exactly visible at a specific commit. And if the build process desires a different commit, the builder will need to make a separate fetch, and report that as a new entry in the resolvedDependencies.
Although this seems to be a build implementation detail, we feel that it may be a common pitfall that many builders would probably stumble upon, and end up as deficiencies and vulnerabilities upon their claim to meet SLSA levels.
We think it may be beneficial for SLSA to provide some clarification on this, make the builder aware as they get onboard, instead of postmortem.
Discussed at community meeting on Aug 28, 2023. We came to the conclusion that at Build L3 whether a build platform does a deep or shallow clone is part of the buildType. We may address this issue as part of a Build L4 or a future dependency track.
Build platforms might not have a priori knowledge of this information. Instead, there may be a build process which enables users' flexibility. This is a similar argument that I was making in https://github.com/slsa-framework/slsa/issues/849. It should still be possible to attain certain levels even though the platform "supports" only building to lower levels as long as the system can also verify that the artifact has maintained a specific level based on its internal implementation.
