How to handle submodules in the source track?

[TomHennen]

          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 #1094 (comment)

[zachariahcox]

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]

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?