From 8e9480ab06023bab9111969e6f1ec02e4dc1c4b2 Mon Sep 17 00:00:00 2001 From: Olivier Ramonat Date: Wed, 27 Sep 2023 10:13:57 +0200 Subject: [PATCH] fix: fix various typos in specification files 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