content: V1.1 RC2

docs/current-activities.md

@@ -15,7 +15,7 @@ Learn how you can [get involved](/community#get-involved)!
 The SLSA specification follows the [Community Specification](https://github.com/CommunitySpecification/Community_Specification/blob/main/) lifecycle going
 through several [stages of maturation](/spec-stages). [Version 1.1 Release
 Candidate 1 (RC1)](/spec/v1.1-rc1/) was published without much fanfare in August 2024. Shortly
-after an astute reader pointed out that the new threat model page had
+afterwards, an astute reader pointed out that the new threat model page had
 several unfinished sections. [Version 1.1 RC2](/spec/v1.1-rc2/) addresses all of these and is now
 open for review. If no major issues are found V1.1 RC2 will then be published
 as Version 1.1, effectively replacing Version 1.0.

docs/spec/draft/threats-overview.md

@@ -51,7 +51,7 @@ Many recent high-profile attacks were consequences of supply chain integrity vul
 <td>Producer
 <td><a href="https://en.wikipedia.org/wiki/SpySheriff">SpySheriff</a>: Software producer purports to offer anti-spyware software, but that software is actually malicious.
 <td>SLSA does not directly address this threat but could make it easier to discover malicious behavior in open source software, by forcing it into the publicly available source code.
-For close source software SLSA does not provide any solutions for malicious producers.
+For closed source software SLSA does not provide any solutions for malicious producers.
 <tr>
 <td>B
 <td>Authoring & reviewing
@@ -71,7 +71,7 @@ For close source software SLSA does not provide any solutions for malicious prod
 <td>E
 <td>Build process
 <td><a href="https://www.crowdstrike.com/blog/sunspot-malware-technical-analysis/">SolarWinds</a>: Attacker compromised the build platform and installed an implant that injected malicious behavior during each build.
-<td>Higher SLSA levels require <a href="requirements#build-requirements">stronger security controls for the build platform</a>, making it more difficult to compromise and gain persistence.
+<td>Higher SLSA Build levels have <a href="requirements#build-platform">stronger security requirements for the build platform</a>, making it more difficult for an attacker to forge the SLSA provenance and gain persistence.
 <tr>
 <td>F
 <td>Artifact publication

docs/spec/v1.1-rc2/future-directions.md

@@ -32,12 +32,12 @@ following requirements, which **may or may not** be part of a future Build L4:
 
 </section>
 
-<section id="build-platform-operations-track">
+<section id="platform-operations-track">
 
-## Build Platform Operations track
+## Platform Operations track
 
-A Build Platform Operations track could provide assurances around the hardening
-of build platforms as they are operated.
+A Platform Operations track could provide assurances around the hardening of
+platforms (e.g. build or source platforms) as they are operated.
 
 The initial [draft version (v0.1)] of SLSA included a section on
 [common requirements](../v0.1/requirements.md#common-requirements) that formed

docs/spec/v1.1-rc2/index.md

@@ -8,8 +8,8 @@ security, established by industry consensus. It is organized into a series of
 levels that describe increasing security guarantees.
 
 This is **Version 1.1 Release Candidate 2 (RC2)** of the SLSA
-specification. It defines several SLSA levels and tracks, as well as
-recommended attestation formats, including provenance.
+specification, which defines several SLSA levels and recommended attestation
+formats, including provenance.
 
 {%- for section in site.data.nav.main %}
 {%- if section.url == page.url %}

docs/spec/v1.1-rc2/principles.md

@@ -114,3 +114,28 @@ 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 an actor. Choice of identification technology is left to the organization and technical
+stacks implementing the SLSA standards.
+
+When identities are strongly authenticated and used consistently they can often be leveraged
+for both of these purposes without requiring them to be mapped to legal identities.
+This reflects how identities are often used in open source where legal name means much less
+to projects than the history and behavior of a given handle over time does. Meanwhile some
+organizations may choose to levy additional requirements on identities. They are free to do
+so, but SLSA itself does not require it.
+
+**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.

docs/spec/v1.1-rc2/terminology.md

@@ -26,8 +26,6 @@ of terminology and models to describe what we're protecting.
 
 ## Software supply chain
 
-**TODO:** Update the text to match the new diagram.
-
 SLSA's framework addresses every step of the software supply chain - the
 sequence of steps resulting in the creation of an artifact. We represent a
 supply chain as a [directed acyclic graph] of sources, builds, dependencies, and
@@ -44,11 +42,12 @@ supply chains plus its own sources and builds.
 | Attestation | An authenticated statement (metadata) about a software artifact or collection of software artifacts. | A signed [SLSA Provenance] file.
 | Source | Artifact that was directly authored or reviewed by persons, without modification. It is the beginning of the supply chain; we do not trace the provenance back any further. | Git commit (source) hosted on GitHub (platform).
 | [Build] | Process that transforms a set of input artifacts into a set of output artifacts. The inputs may be sources, dependencies, or ephemeral build outputs. | .travis.yml (process) run by Travis CI (platform).
-| [Package] | Artifact that is "published" for use by others. In the model, it is always the output of a build process, though that build process can be a no-op. | Docker image (package) distributed on DockerHub (platform). A ZIP file containing source code is a package, not a source, because it is built from some other source, such as a git commit.
+| [Distribution] | The channel through which artifacts are "published" for use by others. | A registry like DockerHub or npm. Artifacts may also be distributed via physical media (e.g., a USB drive).
+| Package | Artifact that is distributed. In the model, it is always the output of a build process, though that build process can be a no-op. | Docker image (package) distributed on DockerHub (distribution). A ZIP file containing source code is a package, not a source, because it is built from some other source, such as a git commit.
 | Dependency | Artifact that is an input to a build process but that is not a source. In the model, it is always a package. | Alpine package (package) distributed on Alpine Linux (platform).
 
 [build]: #build-model
-[package]: #package-model
+[distribution]: #distribution-model
 [SLSA Provenance]: /provenance/v1
 
 ### Roles
@@ -127,7 +126,7 @@ of build types](/provenance/v1#index-of-build-types).
 
 </details>
 
-### Package model
+### Distribution model
 
 Software is distributed in identifiable units called <dfn>packages</dfn>
 according to the rules and conventions of a <dfn>package ecosystem</dfn>.
@@ -138,13 +137,14 @@ informal ecosystems include links to files on a website or distribution of
 first-party software within a company.
 
 Abstractly, a consumer locates software within an ecosystem by asking a
-<dfn>package registry</dfn> to resolve a mutable <dfn>package name</dfn> into an
-immutable <dfn>package artifact</dfn>.[^label] To <dfn>publish</dfn> a package
-artifact, the software producer asks the registry to update this mapping to
-resolve to the new artifact. The registry represents the entity or entities with
-the power to alter what artifacts are accepted by consumers for a given package
-name. For example, if consumers only accept packages signed by a particular
-public key, then it is access to that public key that serves as the registry.
+<dfn>distribution platform</dfn>, such as a package registry, to resolve a
+mutable <dfn>package name</dfn> into an immutable <dfn>package artifact</dfn>.
+[^label] To <dfn>publish</dfn> a package artifact, the software producer asks
+the registry to update this mapping to resolve to the new artifact. The registry
+represents the entity or entities with the power to alter what artifacts are
+accepted by consumers for a given package name. For example, if consumers only
+accept packages signed by a particular public key, then it is access to that
+public key that serves as the registry.
 
 The package name is the primary security boundary within a package ecosystem.
 Different package names represent materially different pieces of

docs/spec/v1.1-rc2/threats-overview.md

@@ -51,7 +51,7 @@ Many recent high-profile attacks were consequences of supply chain integrity vul
 <td>Producer
 <td><a href="https://en.wikipedia.org/wiki/SpySheriff">SpySheriff</a>: Software producer purports to offer anti-spyware software, but that software is actually malicious.
 <td>SLSA does not directly address this threat but could make it easier to discover malicious behavior in open source software, by forcing it into the publicly available source code.
-For close source software SLSA does not provide any solutions for malicious producers.
+For closed source software SLSA does not provide any solutions for malicious producers.
 <tr>
 <td>B
 <td>Authoring & reviewing
@@ -71,7 +71,7 @@ For close source software SLSA does not provide any solutions for malicious prod
 <td>E
 <td>Build process
 <td><a href="https://www.crowdstrike.com/blog/sunspot-malware-technical-analysis/">SolarWinds</a>: Attacker compromised the build platform and installed an implant that injected malicious behavior during each build.
-<td>Higher SLSA levels require <a href="requirements#build-requirements">stronger security controls for the build platform</a>, making it more difficult to compromise and gain persistence.
+<td>Higher SLSA Build levels have <a href="requirements#build-platform">stronger security requirements for the build platform</a>, making it more difficult for an attacker to forge the SLSA provenance and gain persistence.
 <tr>
 <td>F
 <td>Artifact publication