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

content: draft: Add 'principle' protecting anonymous contribution in SLSA #1249

Merged
merged 10 commits into from
Dec 11, 2024
25 changes: 24 additions & 1 deletion docs/spec/draft/principles.md
Original file line number Diff line number Diff line change
Expand Up @@ -107,10 +107,33 @@ In practice, though, these configurations are almost impossible to get right and
keep right. There are often over-provisioning, confused deputy problems, or
mistakes. Even if a platform is configured properly at one moment, it might not
stay that way, and humans almost always end up getting in the access control
lists.
lists.

Access control is still important, but SLSA goes further to provide defense in depth: it **requires proof in
the form of attestations that the package was built correctly**.

**Benefits**: The attestation removes intermediate platforms from the trust base and ensures that
individuals who are accidentally granted access do not have sufficient permission to tamper with the package.

## Support anonymous and pseudonymous contributions

SLSA supports anonymous and pseudonymous 'identities' within the software supply chain.
While organizations that implement SLSA may choose otherwise, SLSA itself does not require,
or encourage, participants to be mapped to their legal identities.

**Nothing in this specification should be taken to mean that SLSA requires participants to
to reveal their legal identity.**

**Reasoning**: SLSA uses identities for multiple purposes: as a trust anchor for attestations
(i.e. who or what is making this claim and do I trust it to do so) or for attributing actions
to the actor which took them within the context of the system they're taking them in (e.g. a
username, cryptographic signing key, etc...).

When identities are strongly authenticated and used consistently they can be used for both of
these purposes without requiring them to be mapped to legal identities. This reflects how
identities are often used in open source. A legal name means much less to projects than the
history and behavior of a given handle over time does.

**Benefits**: By _not_ requiring legal identities SLSA lowers the barriers to its adoption,
enabling all of its other benefits and maintaining support for anonymous and pseudonymous
contribution as has been practiced in the software industry for decades.
Loading