search

slsa-framework / slsa

Supply-chain Levels for Software Artifacts
https://slsa.dev
Other
1.54k stars 223 forks source link

How to handle submodules in the source track? #1134

Open TomHennen opened 3 weeks ago

TomHennen commented 3 weeks ago 
          Should we address submodules and other 'indirection' elsewhere in the spec or is it better to keep it aligned with the attestations themselves?

_Originally posted by @TomHennen in https://github.com/slsa-framework/slsa/pull/1094#discussion_r1672743142_

zachariahcox commented 3 weeks ago

Some thoughts on this topic.

Submodules are just files. In that sense, nothing special is needed.

However, if you direct a tool to act on the content of those files (EG: git clone --recurse-submodules), you will end up with other repos in your repo. In this sense, submodule objects are similar to dependency lock files.

Not all submodules are required (it might not be necessary to clone every submodule) and there are other ways to get the nested repo pattern needed by a project (EG: just clone them directly from a makefile).

Can one revision be slsa-level-3 if it references a submodule at slsa-level-1?

I think we say that slsa levels are not transitive like that, so the answer is "yes."

TomHennen commented 3 weeks ago

I'd agree, so long as we require that the builder include each submodule repo as a separate 'resolvedDependency' so that it's easy for package verifiers to know that all these other repos were used.

Would that be reasonable?