editorial: draft: Address MarkLodato's comments on RC2 (#1316)

Addressing @MarkLodato's [comments on
RC2](#1298 (comment)).

>
https://deploy-preview-1298--slsa.netlify.app/spec/v1.1-rc2/terminology
> * [x] nit: The paragraph defines "distribution platform" but the table
still says "package registry".

Instead of _replacing_ "Package Registry" with "Distribution Platform" I
simply added "Distribution Platform" since a Package Registry is a
specialization (at least as described) and seems worth calling out (also
because it would mess us up elsewhere when we talk about Package
Registries).

>
https://deploy-preview-1298--slsa.netlify.app/spec/v1.1-rc2/threats-overview
> * [ ] nit: "Dependency becomes unavailable" seems out of place. Maybe
remove?

I chose to leave the "Dependency becomes unavailable" bit because it
maps to the expanded "Availability
Threats"(https://deploy-preview-1298--slsa.netlify.app/spec/v1.1-rc2/threats#availability-threats)
and seems worth referencing since we have an example.

We don't currently have examples of Verification Threats but I think
that's OK. If we think it's especially important we can keep it.

> https://deploy-preview-1298--slsa.netlify.app/spec/v1.1-rc2/threats
> * [x] nit: "Single actor controls multiple accounts" - the "Solution"
piece is a separate paragraph here, whereas it is in the same paragraph
as "Example:" elsewhere.
> * [x] nit: "Use a robot account to submit change" - the "Solution" of
"Require review for such changes." is incomplete. If you just require a
single person to review, it doesn't help because that same reviewer has
control over hte robot. You need either two humans to review OR have
some guarantee that the robot cannot be controlled by a reviewer.
> * [x] nit: "Rule exceptions provide vector for abuse" - missing period
at end
> * [x] nit: link to "/spec/v1.1/verifying-artifacts" should just be
"verifying-artifacts"

---------

Signed-off-by: Tom Hennen <[email protected]>

Author: TomHennen

docs/spec/draft/terminology.md

@@ -157,12 +157,13 @@ It is the primary identifier to which consumers attach expectations.
 
 | Term | Description
 | ---- | -----------
+| Distribution platform | An entity responsible for mapping package names to immutable package artifacts.
 | Package | An identifiable unit of software intended for distribution, ambiguously meaning either an "artifact" or a "package name". Only use this term when the ambiguity is acceptable or desirable.
 | Package artifact | A file or other immutable object that is intended for distribution.
 | Package ecosystem | A set of rules and conventions governing how packages are distributed, including how clients resolve a package name into one or more specific artifacts.
 | Package manager client | Client-side tooling to interact with a package ecosystem.
 | Package name | <p>The primary identifier for a mutable collection of artifacts that all represent different versions of the same software. This is the primary identifier that consumers use to obtain the software.<p>A package name is specific to an ecosystem + registry, has a maintainer, is more general than a specific hash or version, and has a "correct" source location. A package ecosystem may group package names into some sort of hierarchy, such as the Group ID in Maven, though SLSA does not have a special term for this.
-| Package registry | An entity responsible for mapping package names to artifacts within a packaging ecosystem. Most ecosystems support multiple registries, usually a single global registry and multiple private registries.
+| Package registry | A specific type of "distribution platform" used within a packaging ecosystem. Most ecosystems support multiple registries, usually a single global registry and multiple private registries.
 | Publish [a package] | Make an artifact available for use by registering it with the package registry. In technical terms, this means associating an artifact to a package name. This does not necessarily mean making the artifact fully public; an artifact may be published for only a subset of users, such as internal testing or a closed beta.
 
 <details><summary>Ambiguous terms to avoid</summary>

docs/spec/draft/threats.md

@@ -110,30 +110,30 @@ A best practice is to require approval of any changes via a change management to
 *Mitigation:* The producer must ensure that no actor is able to control or influence multiple accounts with review privileges.
 
 *Example:* Adversary creates a pull request using a secondary account and approves it using their primary account.
-
-Solution: The producer must track all actors who have both explicit review permissions and the independent ability to control a privileged bot.
-A common vector for this attack is to influence a robot account with the permission to review or contribute code.
-Control of the robot account and an actor's own personal account is enough to exploit this vulnerability.
-A common solution to this flow is to deny bot accounts from contributing or reviewing code, or to require more human reviews in those cases.
+Solution: The producer must track all actors who have both explicit review permissions and the independent ability to control
+a privileged bot. A common vector for this attack is to influence a robot account with the permission to review or contribute
+code. Control of the robot account and an actor's own personal account is enough to exploit this vulnerability. A common
+solution to this flow is to deny bot accounts from contributing or reviewing code, or to require more human reviews in those
+cases.
 
 </details>
 <details><summary>Use a robot account to submit change</summary>
 
 *Threat:* Exploit a robot account that has the ability to submit changes without
 two-person review.
 
-*Mitigation:* All changes require two-person review, even changes authored by
+*Mitigation:* All changes require review by two people, even changes authored by
 robots.
 
 *Example:* A file within the source repository is automatically generated by a
 robot, which is allowed to submit without review.
 Adversary compromises the robot and submits a malicious change.
-Solution: Require review for such changes.
+Solution: Require two-person review for such changes, ignoring the robot.
 
 </details>
 <details><summary>Abuse of rule exceptions</summary>
 
-*Threat:* Rule exceptions provide vector for abuse
+*Threat:* Rule exceptions provide vector for abuse.
 
 *Mitigation:* Remove rule exceptions.
 
@@ -770,7 +770,7 @@ packages. If a misconfigured victim attempts to install attacker's package with
 an internal name but from the public registry, then verification against
 expectations will fail.
 
-For more information see [Verifying artifacts](/spec/v1.1/verifying-artifacts)
+For more information see [Verifying artifacts](verifying-artifacts.md)
 and [Defender's Perspective: Dependency Confusion and Typosquatting Attacks](/blog/2024/08/dep-confusion-and-typosquatting).
 
 </details>