From 1a23083792917ae4a28aaec2da5d28d5edd7a18a Mon Sep 17 00:00:00 2001 From: Mend Renovate Date: Mon, 11 Sep 2023 14:06:12 +0200 Subject: [PATCH 01/10] impl: Update dependency markdownlint-cli to v0.36.0 (#963) markdownlint-cli0.35.0 -> 0.36.0 Signed-off-by: Mend Renovate --- package-lock.json | 56 +++++++++++++++++++++++------------------------ package.json | 2 +- 2 files changed, 29 insertions(+), 29 deletions(-) diff --git a/package-lock.json b/package-lock.json index 9b33c5f2f..667248afb 100644 --- a/package-lock.json +++ b/package-lock.json @@ -5,7 +5,7 @@ "packages": { "": { "dependencies": { - "markdownlint-cli": "0.35.0" + "markdownlint-cli": "0.36.0" } }, "node_modules/@isaacs/cliui": { @@ -166,15 +166,15 @@ } }, "node_modules/glob": { - "version": "10.2.7", - "resolved": "https://registry.npmjs.org/glob/-/glob-10.2.7.tgz", - "integrity": "sha512-jTKehsravOJo8IJxUGfZILnkvVJM/MOfHRs8QcXolVef2zNI9Tqyy5+SeuOAZd3upViEZQLyFpQhYiHLrMUNmA==", + "version": "10.3.4", + "resolved": "https://registry.npmjs.org/glob/-/glob-10.3.4.tgz", + "integrity": "sha512-6LFElP3A+i/Q8XQKEvZjkEWEOTgAIALR9AO2rwT8bgPhDd1anmqDJDZ6lLddI4ehxxxR1S5RIqKe1uapMQfYaQ==", "dependencies": { "foreground-child": "^3.1.0", "jackspeak": "^2.0.3", "minimatch": "^9.0.1", - "minipass": "^5.0.0 || ^6.0.2", - "path-scurry": "^1.7.0" + "minipass": "^5.0.0 || ^6.0.2 || ^7.0.0", + "path-scurry": "^1.10.1" }, "bin": { "glob": "dist/cjs/src/bin.js" @@ -195,11 +195,11 @@ } }, "node_modules/ini": { - "version": "3.0.1", - "resolved": "https://registry.npmjs.org/ini/-/ini-3.0.1.tgz", - "integrity": "sha512-it4HyVAUTKBc6m8e1iXWvXSTdndF7HbdN713+kvLrymxTaU4AUBWrJ4vEooP+V7fexnVD3LKcBshjGGPefSMUQ==", + "version": "4.1.1", + "resolved": "https://registry.npmjs.org/ini/-/ini-4.1.1.tgz", + "integrity": "sha512-QQnnxNyfvmHFIsj7gkPcYymR8Jdw/o7mp5ZFihxn6h8Ci6fh3Dx4E1gPjpQEpIuPo9XVNY/ZUwh4BPMjGyL01g==", "engines": { - "node": "^12.13.0 || ^14.15.0 || >=16.0.0" + "node": "^14.17.0 || ^16.13.0 || >=18.0.0" } }, "node_modules/is-fullwidth-code-point": { @@ -280,31 +280,31 @@ } }, "node_modules/markdownlint": { - "version": "0.29.0", - "resolved": "https://registry.npmjs.org/markdownlint/-/markdownlint-0.29.0.tgz", - "integrity": "sha512-ASAzqpODstu/Qsk0xW5BPgWnK/qjpBQ4e7IpsSvvFXcfYIjanLTdwFRJK1SIEEh0fGSMKXcJf/qhaZYHyME0wA==", + "version": "0.30.0", + "resolved": "https://registry.npmjs.org/markdownlint/-/markdownlint-0.30.0.tgz", + "integrity": "sha512-nInuFvI/rEzanAOArW5490Ez4EYpB5ODqVM0mcDYCPx9DKJWCQqCgejjiCvbSeE7sjbDscVtZmwr665qpF5xGA==", "dependencies": { "markdown-it": "13.0.1", - "markdownlint-micromark": "0.1.5" + "markdownlint-micromark": "0.1.7" }, "engines": { "node": ">=16" } }, "node_modules/markdownlint-cli": { - "version": "0.35.0", - "resolved": "https://registry.npmjs.org/markdownlint-cli/-/markdownlint-cli-0.35.0.tgz", - "integrity": "sha512-lVIIIV1MrUtjoocgDqXLxUCxlRbn7Ve8rsWppfwciUNwLlNS28AhNiyQ3PU7jjj4Qvj+rWTTvwkqg7AcdG988g==", + "version": "0.36.0", + "resolved": "https://registry.npmjs.org/markdownlint-cli/-/markdownlint-cli-0.36.0.tgz", + "integrity": "sha512-h4WdqOam3+QOVOcJSOQuG8KvvN8dlS0OiJhbPwYWBk7VMZR40UtSSMIOpSP5B4EHPHg3W3ILSQUvqg1HNpTCxA==", "dependencies": { "commander": "~11.0.0", "get-stdin": "~9.0.0", - "glob": "~10.2.7", + "glob": "~10.3.4", "ignore": "~5.2.4", "js-yaml": "^4.1.0", "jsonc-parser": "~3.2.0", - "markdownlint": "~0.29.0", - "minimatch": "~9.0.1", - "run-con": "~1.2.11" + "markdownlint": "~0.30.0", + "minimatch": "~9.0.3", + "run-con": "~1.3.2" }, "bin": { "markdownlint": "markdownlint.js" @@ -314,9 +314,9 @@ } }, "node_modules/markdownlint-micromark": { - "version": "0.1.5", - "resolved": "https://registry.npmjs.org/markdownlint-micromark/-/markdownlint-micromark-0.1.5.tgz", - "integrity": "sha512-HvofNU4QCvfUCWnocQP1IAWaqop5wpWrB0mKB6SSh0fcpV0PdmQNS6tdUuFew1utpYlUvYYzz84oDkrD76GB9A==", + "version": "0.1.7", + "resolved": "https://registry.npmjs.org/markdownlint-micromark/-/markdownlint-micromark-0.1.7.tgz", + "integrity": "sha512-BbRPTC72fl5vlSKv37v/xIENSRDYL/7X/XoFzZ740FGEbs9vZerLrIkFRY0rv7slQKxDczToYuMmqQFN61fi4Q==", "engines": { "node": ">=16" } @@ -380,12 +380,12 @@ } }, "node_modules/run-con": { - "version": "1.2.12", - "resolved": "https://registry.npmjs.org/run-con/-/run-con-1.2.12.tgz", - "integrity": "sha512-5257ILMYIF4RztL9uoZ7V9Q97zHtNHn5bN3NobeAnzB1P3ASLgg8qocM2u+R18ttp+VEM78N2LK8XcNVtnSRrg==", + "version": "1.3.2", + "resolved": "https://registry.npmjs.org/run-con/-/run-con-1.3.2.tgz", + "integrity": "sha512-CcfE+mYiTcKEzg0IqS08+efdnH0oJ3zV0wSUFBNrMHMuxCtXvBCLzCJHatwuXDcu/RlhjTziTo/a1ruQik6/Yg==", "dependencies": { "deep-extend": "^0.6.0", - "ini": "~3.0.0", + "ini": "~4.1.0", "minimist": "^1.2.8", "strip-json-comments": "~3.1.1" }, diff --git a/package.json b/package.json index 3487e326c..31274154b 100644 --- a/package.json +++ b/package.json @@ -4,6 +4,6 @@ "format": "markdownlint . --fix" }, "dependencies": { - "markdownlint-cli": "0.35.0" + "markdownlint-cli": "0.36.0" } } From f77c6c51dfc51199d7708f74f914642e09fcd3d3 Mon Sep 17 00:00:00 2001 From: Mend Renovate Date: Mon, 11 Sep 2023 14:07:15 +0200 Subject: [PATCH 02/10] impl: Update actions/checkout action to v4 (#965) actions/checkout v3.6.0 -> v4.0.0 Signed-off-by: Mend Renovate --- .github/workflows/lint.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/lint.yml b/.github/workflows/lint.yml index 8e66874cf..78e1123c0 100644 --- a/.github/workflows/lint.yml +++ b/.github/workflows/lint.yml @@ -6,7 +6,7 @@ jobs: runs-on: ubuntu-latest steps: - name: Checkout - uses: actions/checkout@f43a0e5ff2bd294095638e18286ca9a3d1956744 # v3.6.0 + uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac # v4.0.0 - name: Setup Node uses: actions/setup-node@5e21ff4d9bc1a8cf6de233a3057d20ec6b3fb69d # v3.8.1 - run: npm ci --ignore-scripts From 8be4de9c2582536c1e995480727c5f624ad82f39 Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Mon, 11 Sep 2023 13:09:35 +0100 Subject: [PATCH 03/10] impl: bump activesupport from 7.0.6 to 7.0.7.2 in /docs (#957) Bumps activesupport from 7.0.6 to 7.0.7.2. Signed-off-by: dependabot[bot] --- docs/Gemfile.lock | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/Gemfile.lock b/docs/Gemfile.lock index 97ea5b50b..5afe160fd 100644 --- a/docs/Gemfile.lock +++ b/docs/Gemfile.lock @@ -1,7 +1,7 @@ GEM remote: https://rubygems.org/ specs: - activesupport (7.0.6) + activesupport (7.0.7.2) concurrent-ruby (~> 1.0, >= 1.0.2) i18n (>= 1.6, < 2) minitest (>= 5.1) From 39dbf8fb532e993a61a96ea93e90b469f51c2c7b Mon Sep 17 00:00:00 2001 From: Jasper <656460+jwhb@users.noreply.github.com> Date: Mon, 18 Sep 2023 14:18:59 +0200 Subject: [PATCH 04/10] fix: add redirect for removed example.md (#967) fixes link [hypothetical curl example](https://slsa.dev/example.md) to example.md at https://slsa.dev/spec/v1.0/use-cases#motivating-example Signed-off-by: jwhb --- docs/_redirects | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/_redirects b/docs/_redirects index 8adb59072..ea983d018 100644 --- a/docs/_redirects +++ b/docs/_redirects @@ -70,4 +70,5 @@ /verification_summary/v1.1 /spec/v1.1/verification_summary 301 # Removed files. Keep URLs working forever. -/example https://github.com/slsa-framework/slsa/blob/a25364a3b312f572e4620c812820249853bb40e5/docs/example.md 301 +/example https://github.com/slsa-framework/slsa/blob/a25364a3b312f572e4620c812820249853bb40e5/docs/example.md 301 +/example.md https://github.com/slsa-framework/slsa/blob/a25364a3b312f572e4620c812820249853bb40e5/docs/example.md 301 From 22496ae6edf24c15d303cfbfc29500bc30f879fc Mon Sep 17 00:00:00 2001 From: Mend Renovate Date: Sun, 24 Sep 2023 23:43:43 +0200 Subject: [PATCH 05/10] impl: Update dependency markdownlint-cli to v0.37.0 (#970) markdownlint-cli 0.36.0 -> 0.37.0 Signed-off-by: Mend Renovate --- package-lock.json | 16 ++++++++-------- package.json | 2 +- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/package-lock.json b/package-lock.json index 667248afb..2e277df38 100644 --- a/package-lock.json +++ b/package-lock.json @@ -5,7 +5,7 @@ "packages": { "": { "dependencies": { - "markdownlint-cli": "0.36.0" + "markdownlint-cli": "0.37.0" } }, "node_modules/@isaacs/cliui": { @@ -280,9 +280,9 @@ } }, "node_modules/markdownlint": { - "version": "0.30.0", - "resolved": "https://registry.npmjs.org/markdownlint/-/markdownlint-0.30.0.tgz", - "integrity": "sha512-nInuFvI/rEzanAOArW5490Ez4EYpB5ODqVM0mcDYCPx9DKJWCQqCgejjiCvbSeE7sjbDscVtZmwr665qpF5xGA==", + "version": "0.31.1", + "resolved": "https://registry.npmjs.org/markdownlint/-/markdownlint-0.31.1.tgz", + "integrity": "sha512-CKMR2hgcIBrYlIUccDCOvi966PZ0kJExDrUi1R+oF9PvqQmCrTqjOsgIvf2403OmJ+CWomuzDoylr6KbuMyvHA==", "dependencies": { "markdown-it": "13.0.1", "markdownlint-micromark": "0.1.7" @@ -292,9 +292,9 @@ } }, "node_modules/markdownlint-cli": { - "version": "0.36.0", - "resolved": "https://registry.npmjs.org/markdownlint-cli/-/markdownlint-cli-0.36.0.tgz", - "integrity": "sha512-h4WdqOam3+QOVOcJSOQuG8KvvN8dlS0OiJhbPwYWBk7VMZR40UtSSMIOpSP5B4EHPHg3W3ILSQUvqg1HNpTCxA==", + "version": "0.37.0", + "resolved": "https://registry.npmjs.org/markdownlint-cli/-/markdownlint-cli-0.37.0.tgz", + "integrity": "sha512-hNKAc0bWBBuVhJbSWbUhRzavstiB4o1jh3JeSpwC4/dt6eJ54lRfYHRxVdzVp4qGWBKbeE6Pg490PFEfrKjqSg==", "dependencies": { "commander": "~11.0.0", "get-stdin": "~9.0.0", @@ -302,7 +302,7 @@ "ignore": "~5.2.4", "js-yaml": "^4.1.0", "jsonc-parser": "~3.2.0", - "markdownlint": "~0.30.0", + "markdownlint": "~0.31.1", "minimatch": "~9.0.3", "run-con": "~1.3.2" }, diff --git a/package.json b/package.json index 31274154b..c70f038e9 100644 --- a/package.json +++ b/package.json @@ -4,6 +4,6 @@ "format": "markdownlint . --fix" }, "dependencies": { - "markdownlint-cli": "0.36.0" + "markdownlint-cli": "0.37.0" } } From e4d4089b5d4805acd9e04b9f540f87484b96c7fa Mon Sep 17 00:00:00 2001 From: Mend Renovate Date: Sun, 24 Sep 2023 23:44:40 +0200 Subject: [PATCH 06/10] impl: Update actions/checkout action to v4.1.0 (#969) actions/checkout v4.0.0 -> v4.1.0 Signed-off-by: Mend Renovate --- .github/workflows/lint.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/lint.yml b/.github/workflows/lint.yml index 78e1123c0..b4e3b935b 100644 --- a/.github/workflows/lint.yml +++ b/.github/workflows/lint.yml @@ -6,7 +6,7 @@ jobs: runs-on: ubuntu-latest steps: - name: Checkout - uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac # v4.0.0 + uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608 # v4.1.0 - name: Setup Node uses: actions/setup-node@5e21ff4d9bc1a8cf6de233a3057d20ec6b3fb69d # v3.8.1 - run: npm ci --ignore-scripts From 4df75333652d9f26da217f32e93ecf6e757b116b Mon Sep 17 00:00:00 2001 From: Olivier Ramonat Date: Wed, 27 Sep 2023 10:37:06 +0200 Subject: [PATCH 07/10] fix: fix various typos in specification files (#971) I found some typos when reading https://slsa.dev/spec/v1.0/requirements and used github.com/client9/misspell/cmd/misspell to fix various others. Signed-off-by: Olivier Ramonat --- docs/spec/v0.1/provenance.md | 2 +- docs/spec/v0.1/threats.md | 6 +++--- docs/spec/v0.2/provenance.md | 2 +- docs/spec/v1.0-rc1/requirements.md | 2 +- docs/spec/v1.0-rc2/principles.md | 2 +- docs/spec/v1.0-rc2/requirements.md | 2 +- docs/spec/v1.0-rc2/threats.md | 2 +- docs/spec/v1.0/faq.md | 2 +- docs/spec/v1.0/requirements.md | 2 +- docs/spec/v1.0/threats.md | 2 +- docs/spec/v1.1/faq.md | 2 +- docs/spec/v1.1/requirements.md | 2 +- docs/spec/v1.1/threats.md | 4 ++-- 13 files changed, 16 insertions(+), 16 deletions(-) diff --git a/docs/spec/v0.1/provenance.md b/docs/spec/v0.1/provenance.md index 8e5470da5..cabe79537 100644 --- a/docs/spec/v0.1/provenance.md +++ b/docs/spec/v0.1/provenance.md @@ -248,7 +248,7 @@ of the other top-level fields, such as `subject`, see [Statement]._ `metadata.completeness.arguments` _boolean, optional_ > If true, the `builder` claims that `recipe.arguments` is complete, meaning -> that all external inputs are propertly captured in `recipe`. +> that all external inputs are properly captured in `recipe`. `metadata.completeness.environment` _boolean, optional_ diff --git a/docs/spec/v0.1/threats.md b/docs/spec/v0.1/threats.md index 6dfc1fce8..96e675056 100644 --- a/docs/spec/v0.1/threats.md +++ b/docs/spec/v0.1/threats.md @@ -682,7 +682,7 @@ ad-hoc analysis, and can complement source-based typosquatting solutions. ## Availability threats -An availabiliy threat is a potential for an adversary to deny someone from +An availability threat is a potential for an adversary to deny someone from reading a source and its associated change history, or from building a package.
(A)(B) Delete the code (SLSA 3) @@ -704,11 +704,11 @@ attestation showing that some system, such as GitHub, ensures retention and availability.
-
(E) A dependency becomes temporarily or permenantly unavailable to the build process (out of scope) +
(E) A dependency becomes temporarily or permanently unavailable to the build process (out of scope) *Threat:* Unable to perform a build with the intended dependencies. -*Mitigation:* **Outside the scope of SLSA.** That said, some solutions to support Hermetic and Reproducable builds may also reduce the impact of this threat. +*Mitigation:* **Outside the scope of SLSA.** That said, some solutions to support Hermetic and Reproducible builds may also reduce the impact of this threat. [[Hermetic] [Reproducible] @ SLSA 4]
diff --git a/docs/spec/v0.2/provenance.md b/docs/spec/v0.2/provenance.md index b3dfc57f3..1945902a1 100644 --- a/docs/spec/v0.2/provenance.md +++ b/docs/spec/v0.2/provenance.md @@ -260,7 +260,7 @@ of the other top-level fields, such as `subject`, see [Statement]._ `metadata.completeness.parameters` _boolean, optional_ > If true, the `builder` claims that `invocation.parameters` is complete, meaning -> that all external inputs are propertly captured in `invocation.parameters`. +> that all external inputs are properly captured in `invocation.parameters`. `metadata.completeness.environment` _boolean, optional_ diff --git a/docs/spec/v1.0-rc1/requirements.md b/docs/spec/v1.0-rc1/requirements.md index ca14f518f..9bb7b9aa2 100644 --- a/docs/spec/v1.0-rc1/requirements.md +++ b/docs/spec/v1.0-rc1/requirements.md @@ -90,7 +90,7 @@ choose a builder capable of producing Build Level 3 provenance. The producer MUST build their artifact in a consistent manner such that verifiers can form expectations about the build process. In -some implemenatations, the producer MAY provide explicit metadata to a verifier +some implementations, the producer MAY provide explicit metadata to a verifier about their build process. In others, the verifier will form their expectations implicitly (e.g. trust on first use). diff --git a/docs/spec/v1.0-rc2/principles.md b/docs/spec/v1.0-rc2/principles.md index bd9be929f..407091d2f 100644 --- a/docs/spec/v1.0-rc2/principles.md +++ b/docs/spec/v1.0-rc2/principles.md @@ -18,7 +18,7 @@ expensive manual work, and each trusted system expands the attack surface of the supply chain. Verifying that an artifact is produced by a trusted system, though, is easy to automate. -To simultaniously scale and reduce attack surfaces, it is most efficient to trust a limited +To simultaneously scale and reduce attack surfaces, it is most efficient to trust a limited numbers of systems and then automate verification of the artifacts produced by those systems. The attack surface and work to establish trust does not scale with the number of artifacts produced, as happens when artifacts each use a different trusted system. diff --git a/docs/spec/v1.0-rc2/requirements.md b/docs/spec/v1.0-rc2/requirements.md index d65ae497a..815db9ee3 100644 --- a/docs/spec/v1.0-rc2/requirements.md +++ b/docs/spec/v1.0-rc2/requirements.md @@ -103,7 +103,7 @@ choose a builder capable of producing Build Level 3 provenance. The producer MUST build their artifact in a consistent manner such that verifiers can form expectations about the build process. In -some implemenatations, the producer MAY provide explicit metadata to a verifier +some implementations, the producer MAY provide explicit metadata to a verifier about their build process. In others, the verifier will form their expectations implicitly (e.g. trust on first use). diff --git a/docs/spec/v1.0-rc2/threats.md b/docs/spec/v1.0-rc2/threats.md index 58aaffb35..54c38f0cc 100644 --- a/docs/spec/v1.0-rc2/threats.md +++ b/docs/spec/v1.0-rc2/threats.md @@ -187,7 +187,7 @@ producer. The SLSA Build track mitigates these threats when the consumer [verifies artifacts](verifying-artifacts.md) against expectations, confirming -that the artifact they recieved was built in the expected manner. +that the artifact they received was built in the expected manner. ### (E) Compromise build process diff --git a/docs/spec/v1.0/faq.md b/docs/spec/v1.0/faq.md index e02ae2174..9766dd382 100644 --- a/docs/spec/v1.0/faq.md +++ b/docs/spec/v1.0/faq.md @@ -87,7 +87,7 @@ Jenkins plugin. ## Q. What is the difference between a build platform, system, and service? -Build platform and build system have been used interchangably in the past. With +Build platform and build system have been used interchangeably in the past. With the v1.0 specification, however, there has been a unification around the term platform as indicated in the [Terminology](terminology.md). The use of the word `system` still exists related to software and services within the build platform diff --git a/docs/spec/v1.0/requirements.md b/docs/spec/v1.0/requirements.md index 23827046f..63f0e6b2b 100644 --- a/docs/spec/v1.0/requirements.md +++ b/docs/spec/v1.0/requirements.md @@ -102,7 +102,7 @@ choose a builder capable of producing Build Level 3 provenance. The producer MUST build their artifact in a consistent manner such that verifiers can form expectations about the build process. In -some implemenatations, the producer MAY provide explicit metadata to a verifier +some implementations, the producer MAY provide explicit metadata to a verifier about their build process. In others, the verifier will form their expectations implicitly (e.g. trust on first use). diff --git a/docs/spec/v1.0/threats.md b/docs/spec/v1.0/threats.md index a9dfb5979..237169e4d 100644 --- a/docs/spec/v1.0/threats.md +++ b/docs/spec/v1.0/threats.md @@ -189,7 +189,7 @@ producer. The SLSA Build track mitigates these threats when the consumer [verifies artifacts](verifying-artifacts.md) against expectations, confirming -that the artifact they recieved was built in the expected manner. +that the artifact they received was built in the expected manner. ### (E) Compromise build process diff --git a/docs/spec/v1.1/faq.md b/docs/spec/v1.1/faq.md index e02ae2174..9766dd382 100644 --- a/docs/spec/v1.1/faq.md +++ b/docs/spec/v1.1/faq.md @@ -87,7 +87,7 @@ Jenkins plugin. ## Q. What is the difference between a build platform, system, and service? -Build platform and build system have been used interchangably in the past. With +Build platform and build system have been used interchangeably in the past. With the v1.0 specification, however, there has been a unification around the term platform as indicated in the [Terminology](terminology.md). The use of the word `system` still exists related to software and services within the build platform diff --git a/docs/spec/v1.1/requirements.md b/docs/spec/v1.1/requirements.md index 23827046f..63f0e6b2b 100644 --- a/docs/spec/v1.1/requirements.md +++ b/docs/spec/v1.1/requirements.md @@ -102,7 +102,7 @@ choose a builder capable of producing Build Level 3 provenance. The producer MUST build their artifact in a consistent manner such that verifiers can form expectations about the build process. In -some implemenatations, the producer MAY provide explicit metadata to a verifier +some implementations, the producer MAY provide explicit metadata to a verifier about their build process. In others, the verifier will form their expectations implicitly (e.g. trust on first use). diff --git a/docs/spec/v1.1/threats.md b/docs/spec/v1.1/threats.md index 90797b9e3..237169e4d 100644 --- a/docs/spec/v1.1/threats.md +++ b/docs/spec/v1.1/threats.md @@ -5,7 +5,7 @@ description: A comprehensive technical analysis of supply chain threats and thei What follows is a comprehensive technical analysis of supply chain threats and their corresponding mitigations in SLSA. For an introduction to the -supply chain threats that SLSA protects agains, see [Supply chain threats]. +supply chain threats that SLSA protects against, see [Supply chain threats]. The examples on this page are meant to: @@ -189,7 +189,7 @@ producer. The SLSA Build track mitigates these threats when the consumer [verifies artifacts](verifying-artifacts.md) against expectations, confirming -that the artifact they recieved was built in the expected manner. +that the artifact they received was built in the expected manner. ### (E) Compromise build process From 62c0f8a5873ee9c0e4c699fbb5fd94da6ec91721 Mon Sep 17 00:00:00 2001 From: Mend Renovate Date: Mon, 2 Oct 2023 11:16:16 +0200 Subject: [PATCH 08/10] impl: Update amannn/action-semantic-pull-request action to v5.3.0 (#973) amannn/action-semantic-pull-request v5.2.0 -> v5.3.0 Signed-off-by: Mend Renovate --- .github/workflows/conventional-commits.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/conventional-commits.yml b/.github/workflows/conventional-commits.yml index 11a3a4d10..7e7c20923 100644 --- a/.github/workflows/conventional-commits.yml +++ b/.github/workflows/conventional-commits.yml @@ -17,7 +17,7 @@ jobs: - name: semantic-pull-request env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} - uses: amannn/action-semantic-pull-request@c3cd5d1ea3580753008872425915e343e351ab54 # v5.2.0 + uses: amannn/action-semantic-pull-request@47b15d52c5c30e94a17ec87eb8dd51ff5221fed9 # v5.3.0 with: types: | content From 2180a001a01079179f651fc08524762073470197 Mon Sep 17 00:00:00 2001 From: Joshua Lock Date: Wed, 4 Oct 2023 11:04:38 +0100 Subject: [PATCH 09/10] fix: in-toto attestation "processing model" moved (#976) The "processing model" part of the in-toto attestation specification has been renamed and moved to a new "validation model" page. Update the references to the processing model in our "verifying artifacts" page to link to the validation model instead. Signed-off-by: Joshua Lock --- docs/spec/v1.0-rc2/verifying-artifacts.md | 6 +++--- docs/spec/v1.0/verifying-artifacts.md | 6 +++--- docs/spec/v1.1/verifying-artifacts.md | 6 +++--- 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/spec/v1.0-rc2/verifying-artifacts.md b/docs/spec/v1.0-rc2/verifying-artifacts.md index a0520e615..1ca529b56 100644 --- a/docs/spec/v1.0-rc2/verifying-artifacts.md +++ b/docs/spec/v1.0-rc2/verifying-artifacts.md @@ -91,9 +91,9 @@ Once, when bootstrapping the verifier: Given an artifact and its provenance: -1. [Verify][processing-model] the envelope's signature using the roots of +1. [Verify][validation-model] the envelope's signature using the roots of trust, resulting in a list of recognized public keys (or equivalent). -2. [Verify][processing-model] that statement's `subject` matches the digest of +2. [Verify][validation-model] that statement's `subject` matches the digest of the artifact in question. 3. Verify that the `predicateType` is `https://slsa.dev/provenance/v1-rc2`. 4. Look up the SLSA Build Level in the roots of trust, using the recognized @@ -129,7 +129,7 @@ Resulting threat mitigation: [Threat "G"]: threats#g-compromise-package-repo [Threat "H"]: threats#h-use-compromised-package -[processing-model]: https://github.com/in-toto/attestation/tree/main/spec#processing-model +[validation-model]: https://github.com/in-toto/attestation/blob/main/docs/validation.md#validation-model ### Step 2: Check expectations diff --git a/docs/spec/v1.0/verifying-artifacts.md b/docs/spec/v1.0/verifying-artifacts.md index ad9e17db6..826de5507 100644 --- a/docs/spec/v1.0/verifying-artifacts.md +++ b/docs/spec/v1.0/verifying-artifacts.md @@ -94,9 +94,9 @@ Once, when bootstrapping the verifier: Given an artifact and its provenance: -1. [Verify][processing-model] the envelope's signature using the roots of +1. [Verify][validation-model] the envelope's signature using the roots of trust, resulting in a list of recognized public keys (or equivalent). -2. [Verify][processing-model] that statement's `subject` matches the digest of +2. [Verify][validation-model] that statement's `subject` matches the digest of the artifact in question. 3. Verify that the `predicateType` is `https://slsa.dev/provenance/v1`. 4. Look up the SLSA Build Level in the roots of trust, using the recognized @@ -132,7 +132,7 @@ Resulting threat mitigation: [Threat "G"]: threats#g-compromise-package-repo [Threat "H"]: threats#h-use-compromised-package -[processing-model]: https://github.com/in-toto/attestation/tree/main/spec#processing-model +[validation-model]: https://github.com/in-toto/attestation/blob/main/docs/validation.md#validation-model ### Step 2: Check expectations diff --git a/docs/spec/v1.1/verifying-artifacts.md b/docs/spec/v1.1/verifying-artifacts.md index ad9e17db6..826de5507 100644 --- a/docs/spec/v1.1/verifying-artifacts.md +++ b/docs/spec/v1.1/verifying-artifacts.md @@ -94,9 +94,9 @@ Once, when bootstrapping the verifier: Given an artifact and its provenance: -1. [Verify][processing-model] the envelope's signature using the roots of +1. [Verify][validation-model] the envelope's signature using the roots of trust, resulting in a list of recognized public keys (or equivalent). -2. [Verify][processing-model] that statement's `subject` matches the digest of +2. [Verify][validation-model] that statement's `subject` matches the digest of the artifact in question. 3. Verify that the `predicateType` is `https://slsa.dev/provenance/v1`. 4. Look up the SLSA Build Level in the roots of trust, using the recognized @@ -132,7 +132,7 @@ Resulting threat mitigation: [Threat "G"]: threats#g-compromise-package-repo [Threat "H"]: threats#h-use-compromised-package -[processing-model]: https://github.com/in-toto/attestation/tree/main/spec#processing-model +[validation-model]: https://github.com/in-toto/attestation/blob/main/docs/validation.md#validation-model ### Step 2: Check expectations From c35ae9d61eab847652b34da396aa18f442b9ce84 Mon Sep 17 00:00:00 2001 From: kpk47 <1079282+kpk47@users.noreply.github.com> Date: Tue, 10 Oct 2023 15:43:22 -0700 Subject: [PATCH 10/10] content: How to verify VSAs (#964) Describe how to verify VSAs. - Detail verification procedure. - Add verification examples to clarify verification procedure. - Change `vsa.timestamp` from `required` to `optional` because it is not part of the verification procedure. Fixes #878 BREAKING CHANGE: `timeVerified` switch from `required` to `optional`. --------- Signed-off-by: kpk47 Signed-off-by: kpk47 <1079282+kpk47@users.noreply.github.com> Signed-off-by: Mark Lodato Signed-off-by: Joshua Lock Signed-off-by: Mend Renovate Signed-off-by: arewm Co-authored-by: Joshua Lock Co-authored-by: olivekl <83081275+olivekl@users.noreply.github.com> Co-authored-by: Mark Lodato Co-authored-by: Joshua Lock Co-authored-by: Mend Renovate Co-authored-by: Andrew McNamara --- docs/spec/v1.1/verification_summary.md | 105 ++++++++++++++++++++++++- docs/spec/v1.1/whats-new.md | 1 + 2 files changed, 104 insertions(+), 2 deletions(-) diff --git a/docs/spec/v1.1/verification_summary.md b/docs/spec/v1.1/verification_summary.md index b2724c7f8..1d33b14d7 100644 --- a/docs/spec/v1.1/verification_summary.md +++ b/docs/spec/v1.1/verification_summary.md @@ -139,7 +139,7 @@ of the other top-level fields, such as `subject`, see [Statement]._ > URI indicating the verifier’s identity. -`timeVerified` _string ([Timestamp]), required_ +`timeVerified` _string ([Timestamp]), optional_ > Timestamp indicating what time the verification occurred. @@ -245,6 +245,103 @@ WARNING: This is just for demonstration purposes. } ``` +## How to verify + +VSA consumers use VSAs to accomplish goals based on delegated trust. We call the +process of establishing a VSA's authenticity and determining whether it meets +the consumer's goals 'verification'. Goals differ, as do levels of confidence +in VSA producers, so the verification procedure changes to suit its context. +However, there are certain steps that most verification procedures have in +common. + +Verification MUST include the following steps: + +1. Verify the signature on the VSA envelope using the preconfigured roots of + trust. This step ensures that the VSA was produced by a trusted producer + and that it hasn't been tampered with. + +2. Verify the statement's `subject` matches the digest of the artifact in + question. This step ensures that the VSA pertains to the intended artifact. + +3. Verify that the `predicateType` is + `https://slsa.dev/verification_summary/v1`. This step ensures that the + in-toto predicate is using this version of the VSA format. + +4. Verify that the `verifier` matches the public key (or equivalent) used to + verify the signature in step 1. This step identifies the VSA producer in + cases where their identity is not implicitly revealed in step 1. + +5. Verify that the value for `resourceUri` in the VSA matches the expected + value. This step ensures that the consumer is using the VSA for the + producer's intended purpose. + +6. Verify that the value for `slsaResult` is `PASSED`. This step ensures the + artifact is suitable for the consumer's purposes. + +7. Verify that `verifiedLevels` contains the expected value. This step ensures + that the artifact is suitable for the consumer's purposes. + +Verification MAY additionally contain the following step: + +1. (Optional) Verify additional fields required to determine whether the VSA + meets your goal. + +Verification mitigates different threats depending on the VSA's contents and the +verification procudure. + +IMPORTANT: A VSA does not protect against compromise of the verifier, such as by +a malicious insider. Instead, VSA consumers SHOULD carefully consider which +verifiers they add to their roots of trust. + +### Examples + +1. Suppose consumer C wants to delegate to verifier V the decision for whether + to accept artifact A as resource R. Consumer C verifies that: + + - The signature on the VSA envelope using V's public signing key from their + preconfigured root of trust. + + - `subject` is A. + + - `predicateType` is `https://slsa.dev/verification_summary/v1`. + + - `verifier.id` is V. + + - `resourceUri` is R. + + - `slsaResult` is `PASSED`. + + - `verifiedLevels` contains `SLSA_BUILD_LEVEL_UNEVALUATED`. + + Note: This example is analogous to traditional code signing. The expected + value for `verifiedLevels` is arbitrary but prenegotiated by the producer and + the consumer. The consumer does not need to check additional fields, as C + fully delegates the decision to V. + +2. Suppose consumer C wants to enforce the rule "Artifact A at resource R must + have a passing VSA from verifier V showing it meets SLSA Build Level 2+." + Consumer C verifies that: + + - The signature on the VSA envelope using V's public signing key from their + preconfigured root of trust. + + - `subject` is A. + + - `predicateType` is `https://slsa.dev/verification_summary/v1`. + + - `verifier.id` is V. + + - `resourceUri` is R. + + - `slsaResult` is `PASSED`. + + - `verifiedLevels` is `SLSA_BUILD_LEVEL_2` or `SLSA_BUILD_LEVEL_3`. + + Note: In this example, verifying the VSA mitigates the same threats as + verifying the artifact's SLSA provenance. See + [Verifying artifacts](/spec/v1.0/verifying-artifacts) for details about which + threats are addressed by verifying each SLSA level. +
## _SlsaResult (String)_ @@ -254,6 +351,7 @@ WARNING: This is just for demonstration purposes. The result of evaluating an artifact (or set of artifacts) against SLSA. SHOULD be one of these values: +- SLSA_BUILD_LEVEL_UNEVALUATED - SLSA_BUILD_LEVEL_0 - SLSA_BUILD_LEVEL_1 - SLSA_BUILD_LEVEL_2 @@ -269,7 +367,10 @@ Users MAY use custom values here but MUST NOT use custom values starting with ## Change history -- 1: +- 1.1: + - Added Verification section with examples. + - Made `timeVerified` optional. +- 1.0: - Replaced `materials` with `resolvedDependencies`. - Relaxed `SlsaResult` to allow other values. - Converted to lowerCamelCase for consistency with [SLSA Provenance]. diff --git a/docs/spec/v1.1/whats-new.md b/docs/spec/v1.1/whats-new.md index f792a342d..ed3389925 100644 --- a/docs/spec/v1.1/whats-new.md +++ b/docs/spec/v1.1/whats-new.md @@ -12,6 +12,7 @@ changes in v1.1 relative to the prior release, [v1.0]. - Clarify that attestation format schema are informative and the specification texts (SLSA and [in-toto attestation]) are the canonical source of definitions. +- Add procedure for verifying VSAs.