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

Source control platforms also provide identity #1075

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

Source control platforms also provide identity #1075

TomHennen opened this issue Jun 17, 2024 · 2 comments

Comments

@TomHennen
Copy link
Contributor

          Source control platforms will typically provide an identity model too. 

That identity is what would typically be used to build out "authentic contributions."
Source control platforms will also provide timestamps for activities.

Originally posted by @zachariahcox in #1037 (comment)

@TomHennen
Copy link
Contributor Author

The gist of the issue is ensuring the 'source control platform' definition is complete and includes the identity services they provide.

See also this discussion

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

this was addressed in #1097

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

2 participants