SLSA v1.0: Drop "scripted build" requirement?

Should we drop the scripted build requirement from v1.0? I'm having a hard time articulating what exactly the requirement is or why it is there. I suspect it may be doing more harm than good.

First, this is really only relevant at Build L1. The requirement is moot at Build L2+ because build services always require some sort of build script in practice. So effectively "dropping" this requirement would be moving it to L2.

At Build L1, what is the value? If a build is not scripted (how do you define that?) but the provenance lists sufficient instructions to rebuild, doesn't that meet the spirit of L1? I think we may have originally added it as an intermediate step to Build Service, but I'm not sure that really has value, and may actually just add confusion or throw-away work.

I ask because I am trying to explain what the benefits are at each level (#111) but I realized I can't explain this one. If we drop it, then Build L1 == Provenance, which is clean.

At L1 is there any requirement that the provenance lists sufficient instructions to rebuild?

I suppose it's not clear that L1 with the scripted build requirement the script needs to be referenced at all?

Apart from those specific questions since we'll be keeping the 'Build as Code" requirement at L3+ it generally seems fine to me.

At L1 is there any requirement that the provenance lists sufficient instructions to rebuild?

I suppose it's not clear that L1 with the scripted build requirement the script needs to be referenced at all?

No, that is too strong of a requirement, but I do think we should be more specific on what is required.

Discussed at today's specification meeting (2022-10-10).

It seems that the main value of this requirement is around repeatability and expectation: that everyone knows how the package is supposed to be built. It is not reasonable to tell users to run "gcc foo && gcc bar && ld ... && tar ...", but it is reasonable to say "make".

The script itself is not what we care about. Consider the case of a go program where you just run "go install" without an explicit build script, or a single-file C program where you run "gcc". Those don't have a "script" per se, but they would satisfy the spirit of this requirement.

Proposal: Replace this requirement with something about having an "expected" build command that can be automatically verified by comparing to the provenance. This could be explicit (e.g. in-toto layout) or implicit (e.g. trust on first use). Needs further refining.

At L1 is there any requirement that the provenance lists sufficient instructions to rebuild? I suppose it's not clear that L1 with the scripted build requirement the script needs to be referenced at all?

No, that is too strong of a requirement, but I do think we should be more specific on what is required.

Oops, I don't think I read your comment carefully. On second thought, that does sound like what we want, in addition to some notion of what those commands ought to be.

Three things are needed for bit-for-bit reproducible builds:

• The complete build instruction.
• The complete list of dependencies, down to the specific version.
• A deterministic build process (e.g. no timestamps or filesystem-dependent ordering).

It sounds like at L1 we want to require the first but not the second or third. Does that sound right?

I'm not sure, it probably depends on what you mean.

There are some builders that let users configure the build steps in a UI and store the config in a database somewhere. What would you want people to put in the provenance in that case?

This seems very related to the discussion happening over at #508 as well.

In the spirit of moving us towards v1.0, I am going to mark this as "decided". The last reference to scripted build was removed in #536. We can always reopen if there is disagreement or concern that something is still missing.

There are some builders that let users configure the build steps in a UI and store the config in a database somewhere. What would you want people to put in the provenance in that case?

With the provenance v1.0 proposal in #525, these would be "parameters". You could list either the values directly or their hashes. To verify, the consumer would need some way to know what was "expected", and effectively that is the real requirement that we were trying to get at.

The expectations piece is not yet written, so I'll add a note on #46 to remind us to address this.