Open MarkLodato opened 2 years ago
martensryan
commented
2 years ago Capturing that it would be useful to clean up Trigger and Instruction usage (separating the unit that is executed in response to the event causing that execution to occur).
MarkLodato
commented
2 years ago See also: #129 (better define source). We probably want to clarify "build script" vs "primary source artifact" because in some cases it's different, e.g. GCB and Tekton allow the build script to be defined via the UI, not coming from the source repo. That thread has a lot more detail.
By the way, here's an alternate build diagram that I just rediscovered. We might want to incorporate bits of this into our new build model from #294.
konstruktoid
commented
2 years ago Regarding terminology, defining "build script" and "primary source artifact" and also splitting "build" and "source code" into two valid ... sources(?) would clarify some issue, at least for me.
I asked in #308 if e.g configuration management code[1] could be a valid level 1 since there is no build process per se and the documentation states that "the build process must be fully scripted/automated and generate provenance".
MarkLodato
commented
2 years ago Regarding the question from #308, we should clarify that no build is required. If the thing pulls directly from the version controlled source of truth (eg git) then all of the build requirements are trivially met. But if you pull files out of the get repo and package them into a zip file or similar, that is still a build.
MarkLodato
commented
2 years ago Continuing the discussion with @nasifimtiazohi from #94 on the idea to rename "trusted persons" to "maintainers":
Are there any cases where "maintainers" is worse than "trusted persons"? I can't think of any but it's worth asking.
Well, I am not sure about the exact definition of maintainer as well. If it is only about write access to a GitHub project, then a compromised maintainer can add a sock puppet account as another maintainer to bypass the review restrictions. But then again, a compromised maintainer with enough permissions probably can do a lot of other things as well.
On the other hand, a "trusted person" may indicate that trust is established based on some past activity for a certain developer account.
Suggestion: we move this term to the Terminology page and define a maintainer as a person, not an account. In the requirements we already have the "Different persons" requirement w.r.t. the sock puppet issue.
bobcatfish
commented
2 years ago GCB and Tekton allow the build script to be defined via the UI, not coming from the source repo.
Small detail re Tekton: the hurdle for Tekton is that in the initial implementation, the source of truth for task/build definitions was the Kubernetes cluster - but later support was added for storing these definitions in OCI registries and recently fetching them from version control (TEP-0060).
(The UI was never the source of truth for Tekton task definitions, just a way of viewing them.)
joshuagl
commented
2 years ago On "platform" vs "service": Microsoft calls Cloudbuild a "build service".
shaunmlowry
commented
2 years ago +1 on resolving for 1.0. I'd note that "Non-falsifiable" has long been used in security circles and has a well understood technical definition. Agree re: service/platform and as "trusted person" only appears to be used in the context of source provenance we can probably defer resolving that
joshuagl
commented
2 years ago
This thread tracks terminology and concept simplification for v0.2. Things under consideration:
We will do a version bump for this because these terms are used in many places. Changing these names in v0.1 will break existing links/references and generally make it harder people who knew the old version to understand the new version.
Please add more ideas to this thread.