content: V1.1 RC2 #1298
content: V1.1 RC2 #1298
Conversation
Add SLSA v1.1 Release Candidate 2 (RC2). Rename SLSA v1.1 to v1.1 RC1 (the way it should have been in the first place!) and label it as retired. Redirect v1.1 to v1.1-rc2. Update current activities. Signed-off-by: Arnaud Le Hors <[email protected]>
Signed-off-by: Arnaud Le Hors <[email protected]>
Signed-off-by: Arnaud Le Hors <[email protected]>
Signed-off-by: Arnaud Le Hors <[email protected]>
✅ Deploy Preview for slsa ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Signed-off-by: Arnaud Le Hors <[email protected]>
Signed-off-by: Arnaud Le Hors <[email protected]>
lehors
requested review from
marcelamelara,
adityasaky,
mlieberman85,
TomHennen,
arewm,
trishankatdatadog and
zachariahcox
Signed-off-by: Arnaud Le Hors <[email protected]>
| <th> | ||
| <th>Threats from | ||
| <th>Known example | ||
| <th>How SLSA could help |
There was a problem hiding this comment.
@marcelamelara brought this up in another thread, this column currently lists some things that SLSA does, and some things SLSA doesn't do but that users could do themselves.
E.g. for threat B it says "two-person review could have caught the unauthorized change". SLSA doesn't do that! Not yet at least. Similar for 'C'.
We could address this by:
- Ignore it, it's been fine so far.
- Rename the column: "SLSA and other solutions"
- For B and C replace the cell text with "SLSA does not address this threat."
@marcelamelara @lehors @zachariahcox thoughts?
There was a problem hiding this comment.
How about: 4. Replace the cell text with "SLSA does not address this threat but <what could be done instead>" ?
|
Thanks for doing this @lehors ! As noted in slack, there are some papercut items we'd like to address before shipping 1.1 rc2. I could also believe that it's easier to patch just the draft folder and then regenerate this diff, but I thought I'd ask! |
Signed-off-by: Arnaud Le Hors <[email protected]>
Signed-off-by: Arnaud Le Hors <[email protected]>
Signed-off-by: Arnaud Le Hors <[email protected]>
No, merging this PR will effectively publish RC2. Any further changes would then have to go into an RC3. Not desirable.
The better way is indeed to make changes against the draft and once they are merged I will pick those changes to update this PR accordingly. It's pretty straightforward to do. |
Signed-off-by: Arnaud Le Hors <[email protected]>
|
FWIW I've reviewed the rest of the changes and apart from the existing identified issues and outstanding PRs I think this looks great! |
…ram (#1313) This PR updates the terminology page to match the updated supply chain diagram that replaced "package" with "distribution", to address [a remaining TODO](#1298 (comment)) prior to v1.1-RC2 release. Very few changes have actually been made to the original text. Changes: * New definition for "distribution" * Replaced "package model" with "distribution model" and made minor textual updates to the section * Add-on: Moved build environment model to the BuildEnv track spec --------- Signed-off-by: Marcela Melara <[email protected]>
Signed-off-by: Arnaud Le Hors <[email protected]>
|
I think this just needs one more refresh before a final look and we start waiting the 72 hours. :) |
Signed-off-by: Arnaud Le Hors <[email protected]>
It was raised in the review of 1.1-RC2 that build L3 does not require provenance to be complete. Instead, it only requires the external parameters to be complete. With this requirement, it is still sufficient to mitigate an attack by SSH on the artifact as the verifier would be able to ensure that the external parameters meet expectations. ref: slsa-framework#1298 (comment) Signed-off-by: arewm <[email protected]>
It was raised in the review of 1.1-RC2 that build L3 does not require provenance to be complete. Instead, it only requires the external parameters to be complete. With this requirement, it is still sufficient to mitigate an attack by SSH on the artifact as the verifier would be able to ensure that the external parameters meet expectations. ref: slsa-framework#1298 (comment) Signed-off-by: arewm <[email protected]>
…rovenance (#1315) It was raised in the review of 1.1-RC2 that build L3 does not require provenance to be complete. Instead, it only requires the external parameters to be complete. With this requirement, it is still sufficient to mitigate an attack by SSH on the artifact as the verifier would be able to ensure that the external parameters meet expectations. ref: #1298 (comment) Signed-off-by: arewm <[email protected]> Signed-off-by: arewm <[email protected]>
Signed-off-by: Arnaud Le Hors <[email protected]>
|
@MarkLodato provided some helpful feedback on this PR: https://deploy-preview-1298--slsa.netlify.app/spec/v1.1-rc2/terminology
https://deploy-preview-1298--slsa.netlify.app/spec/v1.1-rc2/threats-overview
https://deploy-preview-1298--slsa.netlify.app/spec/v1.1-rc2/threats
FWIW I think addressing these would be considered 'editorial' if that helps. Thanks Mark! |
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]>
Signed-off-by: Arnaud Le Hors <[email protected]>
Add SLSA v1.1 Release Candidate 2 (RC2).
Rename SLSA v1.1 to v1.1 RC1 (the way it should have been in the first place!) and label it as retired.
Redirect v1.1 to v1.1-rc2.
Update current activities.
Note to reviewers: Besides checking the preview, you might want to checkout this PR and do a diff between docs/spec/v1.1-rc1 and docs/spec/v1.1-rc2 to see what has changed between the 2. RC2 shouldn't include any of the future stuff (i.e., source track, build-env). Otherwise, looking at the files changed on GitHub will show all the RC2 as new and be of little value for review.