Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify Robot Approval #1080

Closed
TomHennen opened this issue Jun 17, 2024 · 4 comments
Closed

Clarify Robot Approval #1080

TomHennen opened this issue Jun 17, 2024 · 4 comments

Comments

@TomHennen
Copy link
Contributor

          Should a robot approval count or must it always be human?

Originally posted by @zachariahcox in #1037 (comment)

@TomHennen
Copy link
Contributor Author

See also this discussion

@joshuagl
Copy link
Member

@zachariahcox
Copy link
Contributor

based on the work here #1097, I think the proposal is this:

SLSA Source track is about producing trustworthy attestations and should require only the absolute minimum policies required to do so.
To that end, SLSA will require strongly authenticated actors at higher levels but makes no further requirements.

It is up to future policy writers to decide if robot approvals are allowed or not for a specific context.

TomHennen added a commit that referenced this issue Aug 15, 2024
### Context

This was mostly ported from
[gdoc](https://docs.google.com/document/d/13Xt8mA_2b00McGX2vkyhu4GQdFAqtXPu7YXE8ZA6ISE/edit?resourcekey=0-EqfHF79tUWAKp4PzsE3z1A#bookmark=id.gg47kpxaq1to),
(requires
[slsa-discussion@googlegroups.com](mailto:slsa-discussion@googlegroups.com)
membership.)

The content is intentionally incomplete. 
The final draft document will need wholistic review before progressing
to the full proposal phase.

### Goals

The source track is about communicating trustworthy claims. 
These proposals for levels try to describe the absolute bare minimum
policies and controls required to make sense of the code in a repo.

This proposal moves most of the other "good idea" policies into a
different, non-leveled, section.
One of the goals of slsa is to help teams make improvements to their
process in a prioritized way.

Many of these good ideas should be called out and documented
_somewhere_, but they are not directly required for the repo to produce
trustworthy attestations, so we're proposing to document and discuss
them separately.

Update! As discussed [in
slack](https://openssf.slack.com/archives/C03NUSAPKC6/p1723156008871629?thread_ts=1723152271.940339&cid=C03NUSAPKC6),
products like the [ossf
scorecard](https://github.com/ossf/scorecard?tab=readme-ov-file#scorecard-checks)
might be better fits for describing policy details. The scorecard is
much more opinionated about things like branch protections already!

This pr addresses the topics raised in the following issues. 
We should re-valuate the status of these issues when this PR merges:
* #1076
* #1075 
* #1077
* #1095
* #1080

---------

Signed-off-by: Zachariah Cox <zachariahcox@github.com>
Signed-off-by: Tom Hennen <TomHennen@users.noreply.github.com>
Co-authored-by: Tom Hennen <TomHennen@users.noreply.github.com>
Co-authored-by: Aditya Sirish <8928778+adityasaky@users.noreply.github.com>
@zachariahcox
Copy link
Contributor

I believe this topic is covered by #196

The working theory is that SLSA source track is primarily concerned with the trustworthy generation of provenance attestations.
The implied meaning of the contents of those attestations (and whether or not combinations of rules qualify a revision for various grades) is opinionated and up to the issuer of the vSA.

Marking "closed" for now. Please reopen if you feel that this topic has not been addressed fully! Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Status: Done
Development

No branches or pull requests

3 participants