Clarification on scope of the requirement for parameterless builds

[shaunmlowry]

At ActiveState, we're producing a build system which is capable of building arbitrary sets of open source components. Even when considering just the Perl and Python ecosystems, there are tens of millions of individual components and versions thereof so providing a parameterless build script for every one isn't practical. When you also consider that users sometimes want variants of builds (static vs dynamic linking, debug vs optimised, threading, GPU acceleration etc. etc.) creating a matrix of build scripts for every component for every combination of variations is completely intractable. In ActiveState's case, we have a few dozens of unique build scripts which can be applied to many components to build them along with some constrained sets of parameters for individual component quirks and/or different build variants. It is, however, an anti-goal to allow end users direct access to the parameters for the build of any given component, so for example we'd want to allow our users to specify they want a debuggable build across their entire runtime, but we don't want them to be able to specifically set CFLAGS=-g to do that - the ActiveState platform and its constrained set of parameters to build scripts are designed to manage that expression of the user's intent.

Can we clarify the wording on the requirement for parameterless builds to at least give guidance on the scope at which we can consider builds to be parameterless and some detail on the spirit of the requirement?

[MarkLodato]

Agreed on the need to address this by updating the spec with more nuance.

FWIW, we have the same issue internally within Google. Our build system allows parameters for the same reasons, e.g. to support debug vs optimized builds. We need to figure out how to handle this. It's impractical for us to just say, "No more parameters."

As mentioned in yesterday's bi-weekly meeting, the motivation behind this requirement is to make it practice for the consumer to determine what parameters are acceptable. For example, is it OK for an artifact to be built with debug flags? Maybe, since that doesn't significantly change behavior. Is it OK for an artifact to be built with CFLAGS=-Dsomething=else? Maybe not, since that does change behavior. But it's not yet clear to me how to encode this into the spec.

A good first step would be to explain this motivation in the spec, and maybe link to this issue?

[david-a-wheeler]

Parameterless seems to overstated. See meeting discussion on 2022-03-17. Perhaps allow an "allow list of parameters", e.g., for secrets. I think the issue is that there needs to be a scoped list of parameters, not literally no parameters.

[david-a-wheeler]

E.g., an allowlist of parameters for the build system as a whole.

Note: Individual components may have more capabilities without invalidating this. E.g., a makefile used in a build, may have a huge number of parameters, but I think this should apply to the build system as a whole (e.g., the build system / script that invokes make, not the makefile in isolation).

[shaunmlowry]

I think this makes sense. FWIW at ActiveState, we think of a build producing a number of artifacts, each created by a number of steps with distinct builders. Users can specify that they want certain features of this whole build e.g. "debuggable" and we maintain a list of builder-specific parameters that react to those requests - for example if we're building a C library on linux with a builder that invokes autotools and GCC, the builder specific parameter set will react to the "debuggable" request by setting CLFAGS=-g. Building the same library on windows with visual studio will mean building with a different builder and a different builder-specific parameter set which could react to "debuggable" by setting the MSBuild config to ReleaseWithDebug. All of these reactions to "debuggable" are recorded in both our record of the builder's invocation (and hence can be added to the invocation section of the attestations) and also form part of the calculation for each artifact's id, so a debuggable artifact from this build is considered to be distinct from one which isn't. In this scenario, the only thing I'd consider to be a 'parameter' is the user's request that the overall build be debuggable, and that this is fine because it's recorded in the various artifacts' provenances and hence considered a distinct build which happens to share source code with other artifacts. We're maintaining a constrained list of the parameters which users can request (e.g. debug, threading-enabled, gpu-accelerated etc. etc.) which I feel falls under the definition of the scoped list @david-a-wheeler proposes

[bobcatfish]

Hi all! In the Tekton community we have some discussion on the parameterless question as well (some notes in this doc on SLSA + Tekton, shared with [email protected] and [email protected])) - a few things we've identified that are examples of potentially unavoidable parameters to a build:

• The version to tag a built artifact with (e.g. may be extracted from a git tag)
• Secret / auth details ( +1 to @david-a-wheeler 's commment https://github.com/slsa-framework/slsa/issues/278#issuecomment-1071063421)
• Runtime provider specific information (e.g. node affinity)

@shaunmlowry your debug examples are interesting - I'm wondering ultimately where the source of truth is for whether a particular user's artifacts are built as debug or not? I would imagine that if team A building image Foo wanted to always Foo with debug capabilities, you'd want that "parameter" to be committed to version control somewhere? If so, I think it would meet the parameterless requirements as I understand them. (Allowing a value like that - which would impact the behavior of resulting artifact - not be recorded in version control seems like it would be contrary to the spirit of being able to version and audit build configuration?)

[MikeTheSnowman]

Parameterless seems to overstated. See meeting discussion on 2022-03-17. Perhaps allow an "allow list of parameters", e.g., for secrets. I think the issue is that there needs to be a scoped list of parameters, not literally no parameters.

I totally agree here that the Parameterless requirement is overly broad. The big issue as you've already pointed out @david-a-wheeler is that for most CI/CD systems, the recommended way to provide things like secrets and credentials in a secure way to a pipeline is by using parameters because it's obviously not secure to hardcode things like API tokens and credentials into your build.