-
Notifications
You must be signed in to change notification settings - Fork 225
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
Comments
See also this discussion |
we've had various discussions about robots in the past, linking here to the ones preserved in GitHub: |
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. It is up to future policy writers to decide if robot approvals are allowed or not for a specific context. |
### 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>
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. Marking "closed" for now. Please reopen if you feel that this topic has not been addressed fully! Thanks! |
Originally posted by @zachariahcox in #1037 (comment)
The text was updated successfully, but these errors were encountered: