From 9d89837963d8be644b84ee743df77484eeb0b71b Mon Sep 17 00:00:00 2001 From: Andreas Deininger Date: Fri, 26 Apr 2024 21:57:29 +0200 Subject: [PATCH] Fix: fixing typos --- ...md => 2023-06-13-slsa-github-workflows-container-based.md} | 0 docs/_posts/2023-08-28-bring-your-own-builder-github.md | 4 ++-- docs/spec-stages.md | 2 +- docs/spec/v0.1/provenance.md | 2 +- docs/spec/v0.1/requirements.md | 2 +- docs/spec/v0.1/use-cases.md | 2 +- docs/spec/v0.2/provenance.md | 2 +- docs/spec/v1.0-rc1/use-cases.md | 2 +- docs/spec/v1.0-rc2/future-directions.md | 2 +- docs/spec/v1.0-rc2/levels.md | 2 +- docs/spec/v1.0-rc2/use-cases.md | 2 +- docs/spec/v1.0/future-directions.md | 2 +- docs/spec/v1.0/levels.md | 2 +- docs/spec/v1.1/future-directions.md | 2 +- docs/spec/v1.1/levels.md | 2 +- 15 files changed, 15 insertions(+), 15 deletions(-) rename docs/_posts/{2023-06-13-slsa-github-worfklows-container-based.md => 2023-06-13-slsa-github-workflows-container-based.md} (100%) diff --git a/docs/_posts/2023-06-13-slsa-github-worfklows-container-based.md b/docs/_posts/2023-06-13-slsa-github-workflows-container-based.md similarity index 100% rename from docs/_posts/2023-06-13-slsa-github-worfklows-container-based.md rename to docs/_posts/2023-06-13-slsa-github-workflows-container-based.md diff --git a/docs/_posts/2023-08-28-bring-your-own-builder-github.md b/docs/_posts/2023-08-28-bring-your-own-builder-github.md index 275c2eadc..a62cf7b0e 100644 --- a/docs/_posts/2023-08-28-bring-your-own-builder-github.md +++ b/docs/_posts/2023-08-28-bring-your-own-builder-github.md @@ -4,9 +4,9 @@ author: "Andres Almiray (JReleaser), Adam Korczynski (Ada Logics), Philip Harris is_guest_post: false --- -It has been an exciting quarter for supply chain security and SLSA, with the release of the [SLSA v1.0 specification](2023-04-19-slsa-v1-final.md), [SLSA provenance support for npm](https://github.blog/2023-04-19-introducing-npm-package-provenance/), and the announcement of new SLSA Level 3 builders for [Node.js](2023-05-11-bringing-improved-supply-chain-security-to-the-nodejs-ecosystem.md) and [containers](2023-06-13-slsa-github-worfklows-container-based.md)! +It has been an exciting quarter for supply chain security and SLSA, with the release of the [SLSA v1.0 specification](2023-04-19-slsa-v1-final.md), [SLSA provenance support for npm](https://github.blog/2023-04-19-introducing-npm-package-provenance/), and the announcement of new SLSA Level 3 builders for [Node.js](2023-05-11-bringing-improved-supply-chain-security-to-the-nodejs-ecosystem.md) and [containers](2023-06-13-slsa-github-workflows-container-based.md)! -SLSA already provides and maintains official builders for [Go](2022-06-20-slsa-github-workflows.md), [Node.js](2023-05-11-bringing-improved-supply-chain-security-to-the-nodejs-ecosystem.md) and [Container](2023-06-13-slsa-github-worfklows-container-based.md) based projects. But what if you don't use any of these languages or use custom tooling that isn't supported by the official builders? +SLSA already provides and maintains official builders for [Go](2022-06-20-slsa-github-workflows.md), [Node.js](2023-05-11-bringing-improved-supply-chain-security-to-the-nodejs-ecosystem.md) and [Container](2023-06-13-slsa-github-workflows-container-based.md) based projects. But what if you don't use any of these languages or use custom tooling that isn't supported by the official builders? To empower the community to create their own provenance builders and leverage the secure architecture of the official SLSA builders we are releasing the ["Build Your Own Builder" (BYOB) framework](https://github.com/slsa-framework/slsa-github-generator/tree/main#build-your-own-builder) for GitHub Actions. This makes it easy to take an existing GitHub Action (e.g. [JReleaser](https://jreleaser.org/)) and make it produce [SLSA Build Level 3 provenance](/spec/v1.0/requirements#provenance-generation). diff --git a/docs/spec-stages.md b/docs/spec-stages.md index 08c8a34d8..4579b53f6 100644 --- a/docs/spec-stages.md +++ b/docs/spec-stages.md @@ -63,7 +63,7 @@ for other considerations related to an This stage indicates that the specification is no longer maintained. It has been either rendered obsolete by a newer version or abandoned for some reason. The status of the document may provide -additional information and point to the new document to use intead if +additional information and point to the new document to use instead if there is one. ## Versioning diff --git a/docs/spec/v0.1/provenance.md b/docs/spec/v0.1/provenance.md index cabe79537..56bc6c5cf 100644 --- a/docs/spec/v0.1/provenance.md +++ b/docs/spec/v0.1/provenance.md @@ -428,7 +428,7 @@ Here `entryPoint` references the `filename` from the CloudBuild // ... at the path path/to/cloudbuild.yaml. "entryPoint": "path/to/cloudbuild.yaml", // The only possible user-defined parameters that can affect a BuildTrigger - // are the subtitutions in the BuildTrigger. + // are the substitutions in the BuildTrigger. "arguments": { "substitutions": {...} } diff --git a/docs/spec/v0.1/requirements.md b/docs/spec/v0.1/requirements.md index 3ffae66e0..4aebdd3b3 100644 --- a/docs/spec/v0.1/requirements.md +++ b/docs/spec/v0.1/requirements.md @@ -63,7 +63,7 @@ _○ = REQUIRED unless there is a justification_ ## Definitions > See also [Terminology](terminology.md) for general SLSA concepts. The -> defintions below are only used in this document. +> definitions below are only used in this document. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be diff --git a/docs/spec/v0.1/use-cases.md b/docs/spec/v0.1/use-cases.md index 7363f185a..c00e6a2d3 100644 --- a/docs/spec/v0.1/use-cases.md +++ b/docs/spec/v0.1/use-cases.md @@ -43,7 +43,7 @@ Example ways an organization might use SLSA internally: - A large company uses SLSA to require two person review for every production change, scalably across hundreds or thousands of employees/teams. - An open source project uses SLSA to ensure that compromised credentials - cannot be abused to release an unofficial package to a package repostory. + cannot be abused to release an unofficial package to a package repository. **Case study:** [Google (Binary Authorization for Borg)](https://cloud.google.com/docs/security/binary-authorization-for-borg) diff --git a/docs/spec/v0.2/provenance.md b/docs/spec/v0.2/provenance.md index 1945902a1..080125314 100644 --- a/docs/spec/v0.2/provenance.md +++ b/docs/spec/v0.2/provenance.md @@ -517,7 +517,7 @@ Here `entryPoint` references the `filename` from the CloudBuild "digest": {"sha1": "abc..."} }, // The only possible user-defined parameters that can affect a BuildTrigger - // are the subtitutions in the BuildTrigger. + // are the substitutions in the BuildTrigger. "parameters": { "substitutions": {...} } diff --git a/docs/spec/v1.0-rc1/use-cases.md b/docs/spec/v1.0-rc1/use-cases.md index 7363f185a..c00e6a2d3 100644 --- a/docs/spec/v1.0-rc1/use-cases.md +++ b/docs/spec/v1.0-rc1/use-cases.md @@ -43,7 +43,7 @@ Example ways an organization might use SLSA internally: - A large company uses SLSA to require two person review for every production change, scalably across hundreds or thousands of employees/teams. - An open source project uses SLSA to ensure that compromised credentials - cannot be abused to release an unofficial package to a package repostory. + cannot be abused to release an unofficial package to a package repository. **Case study:** [Google (Binary Authorization for Borg)](https://cloud.google.com/docs/security/binary-authorization-for-borg) diff --git a/docs/spec/v1.0-rc2/future-directions.md b/docs/spec/v1.0-rc2/future-directions.md index b5c40f416..05f200433 100644 --- a/docs/spec/v1.0-rc2/future-directions.md +++ b/docs/spec/v1.0-rc2/future-directions.md @@ -1,6 +1,6 @@ --- title: Future directions -description: The initial draft version (v0.1) of SLSA had a larger scope including protections against tampering with source code and a higher level of build integrity (Build L4). This page collects some early thoughts on how SLSA **might** evolve in future versios to re-introduce these notions and add other additional aspects of automatable supply chain security. +description: The initial draft version (v0.1) of SLSA had a larger scope including protections against tampering with source code and a higher level of build integrity (Build L4). This page collects some early thoughts on how SLSA **might** evolve in future versions to re-introduce these notions and add other additional aspects of automatable supply chain security. --- The initial [draft version (v0.1)] of SLSA had a larger scope including diff --git a/docs/spec/v1.0-rc2/levels.md b/docs/spec/v1.0-rc2/levels.md index 230cf19ef..67e262af6 100644 --- a/docs/spec/v1.0-rc2/levels.md +++ b/docs/spec/v1.0-rc2/levels.md @@ -28,7 +28,7 @@ tracks without invalidating previous levels. | [Build L3] | Hardened build service | Tampering during the build +hermeticity or completeness of provenance --> > Note: The [previous version] of the specification used a single unnamed track, > SLSA 1–4. For version 1.0 the Source aspects were removed to focus on the diff --git a/docs/spec/v1.0-rc2/use-cases.md b/docs/spec/v1.0-rc2/use-cases.md index 7363f185a..c00e6a2d3 100644 --- a/docs/spec/v1.0-rc2/use-cases.md +++ b/docs/spec/v1.0-rc2/use-cases.md @@ -43,7 +43,7 @@ Example ways an organization might use SLSA internally: - A large company uses SLSA to require two person review for every production change, scalably across hundreds or thousands of employees/teams. - An open source project uses SLSA to ensure that compromised credentials - cannot be abused to release an unofficial package to a package repostory. + cannot be abused to release an unofficial package to a package repository. **Case study:** [Google (Binary Authorization for Borg)](https://cloud.google.com/docs/security/binary-authorization-for-borg) diff --git a/docs/spec/v1.0/future-directions.md b/docs/spec/v1.0/future-directions.md index bfa8cc45f..699bf39df 100644 --- a/docs/spec/v1.0/future-directions.md +++ b/docs/spec/v1.0/future-directions.md @@ -1,6 +1,6 @@ --- title: Future directions -description: The initial draft version (v0.1) of SLSA had a larger scope including protections against tampering with source code and a higher level of build integrity (Build L4). This page collects some early thoughts on how SLSA **might** evolve in future versios to re-introduce these notions and add other additional aspects of automatable supply chain security. +description: The initial draft version (v0.1) of SLSA had a larger scope including protections against tampering with source code and a higher level of build integrity (Build L4). This page collects some early thoughts on how SLSA **might** evolve in future versions to re-introduce these notions and add other additional aspects of automatable supply chain security. --- The initial [draft version (v0.1)] of SLSA had a larger scope including diff --git a/docs/spec/v1.0/levels.md b/docs/spec/v1.0/levels.md index 11b384b10..ccecf1690 100644 --- a/docs/spec/v1.0/levels.md +++ b/docs/spec/v1.0/levels.md @@ -28,7 +28,7 @@ tracks without invalidating previous levels. | [Build L3] | Hardened build platform | Tampering during the build +hermeticity or completeness of provenance --> > Note: The [previous version] of the specification used a single unnamed track, > SLSA 1–4. For version 1.0 the Source aspects were removed to focus on the diff --git a/docs/spec/v1.1/future-directions.md b/docs/spec/v1.1/future-directions.md index bfa8cc45f..699bf39df 100644 --- a/docs/spec/v1.1/future-directions.md +++ b/docs/spec/v1.1/future-directions.md @@ -1,6 +1,6 @@ --- title: Future directions -description: The initial draft version (v0.1) of SLSA had a larger scope including protections against tampering with source code and a higher level of build integrity (Build L4). This page collects some early thoughts on how SLSA **might** evolve in future versios to re-introduce these notions and add other additional aspects of automatable supply chain security. +description: The initial draft version (v0.1) of SLSA had a larger scope including protections against tampering with source code and a higher level of build integrity (Build L4). This page collects some early thoughts on how SLSA **might** evolve in future versions to re-introduce these notions and add other additional aspects of automatable supply chain security. --- The initial [draft version (v0.1)] of SLSA had a larger scope including diff --git a/docs/spec/v1.1/levels.md b/docs/spec/v1.1/levels.md index 93adf66ef..98bce5869 100644 --- a/docs/spec/v1.1/levels.md +++ b/docs/spec/v1.1/levels.md @@ -28,7 +28,7 @@ tracks without invalidating previous levels. | [Build L3] | Hardened build platform | Tampering during the build +hermeticity or completeness of provenance --> > Note: The [previous version] of the specification used a single unnamed track, > SLSA 1–4. For version 1.0 the Source aspects were removed to focus on the