slsa-framework
Parameterless requirement for Level 4 prevents re-use of build scripts
For build systems which are capable of building many millions of individual packages and versions, it's not practical to require that every individual package version has its own unique build script especially if those scripts are the interface between a build service and the native build system for a package's ecosystem. For example, a build service might have a script which is generically capable of building Python wheels but needs to be aware of the specific build backend it needs to invoke for that module (e.g. flit, poetry, etc.). A script designed to build autotools-based C libraries may need to know the location or configuration of a dependency to feed that information to the configure script. Whilst it would be possible to create a script which wrapped the generic script along with the specific options required, that seems a little disingenuous as it's hiding details of the build and would seem to exist only as a solution to the 'Parameterless' requirement.
My understanding of the intent of the Parameterless requirement is that is is to prevent end users of the build system injecting their own parameters at build time. Instead of allowing this, would it instead be an option to allow only service-generated parameters?
For example, the ActiveState Platform maintains a database of packages which not only acts as a revision control system for the packages, but also includes a revision-controlled mechanism for composing command line flags for build scripts. This allows us to maintain a few build scripts per ecosystem and have them perform builds for many thousands of packages and versions, customized at build time via parameters generated by rules in the build orchestrator. These builds are then not strictly parameterless and we should report the parameters supplied to the build scripts in the appropriate attestations (at the very least for reproducibility), however there's no way for a user of the build system to influence those parameters so it meets the intent.
Should we merge this with #278?
Are you saying that effectively the only allowed parameters are booleans or enums, not arbitrary strings? (Follow-on question: what about integers? floats?)
If so, that sounds good to me. (If not, I'll need to first understand.)
