From 8a4342c6a24b2afb95fcc226aec52ef5eabbfa5e Mon Sep 17 00:00:00 2001 From: Arnaud J Le Hors Date: Fri, 7 Feb 2025 18:27:08 +0100 Subject: [PATCH] Fix yet more broken links Signed-off-by: Arnaud J Le Hors --- docs/_redirects | 9 +++++---- .../supply-chain-threats-build-verification.svg | 0 docs/build/v1.0/requirements.md | 16 +++++++++------- docs/source/draft/source-requirements.md | 2 +- docs/spec/draft/faq.md | 5 +++-- docs/spec/draft/future-directions.md | 2 +- docs/spec/draft/threats.md | 15 +++++++++------ 7 files changed, 28 insertions(+), 21 deletions(-) rename docs/{spec/draft => build/v1.0}/images/supply-chain-threats-build-verification.svg (100%) diff --git a/docs/_redirects b/docs/_redirects index 0a92eb0fb..e7ca209ae 100644 --- a/docs/_redirects +++ b/docs/_redirects @@ -55,10 +55,11 @@ /provenance/v1.1 /spec/v1.1/provenance 301 /provenance/draft /spec/draft/provenance 301 -/spec /spec/v1.0 302 -/spec/faq /spec/v1.0/faq 302 -/spec/v1/* /spec/v1.0/:splat 302 -/spec/current-activities /current-activities 301 # permanent +/spec /spec/v1.0 302 +/spec/faq /spec/v1.0/faq 302 +/spec/v1/* /spec/v1.0/:splat 302 +/spec/current-activities /current-activities 301 # permanent +/spec/v1.1/current-activities /current-activities 301 # permanent # Note: Versions prior to v1.0 stay in /verification_summary. /verification_summary /spec/v1.0/verification_summary 302 # floating diff --git a/docs/spec/draft/images/supply-chain-threats-build-verification.svg b/docs/build/v1.0/images/supply-chain-threats-build-verification.svg similarity index 100% rename from docs/spec/draft/images/supply-chain-threats-build-verification.svg rename to docs/build/v1.0/images/supply-chain-threats-build-verification.svg diff --git a/docs/build/v1.0/requirements.md b/docs/build/v1.0/requirements.md index a3992f7b1..661a3e8b0 100644 --- a/docs/build/v1.0/requirements.md +++ b/docs/build/v1.0/requirements.md @@ -12,7 +12,7 @@ engineers. For an informative description of the levels intended for all audiences, see [Security Levels](levels.md). For background, see [Terminology](terminology.md). To better understand the reasoning behind the requirements, see -[Threats and mitigations](threats.md). +[Threats and mitigations]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be @@ -89,7 +89,7 @@ NOTE: There were more requirements for producers in the initial [draft version (v0.1)](../v0.1/requirements.md#scripted-build) which impacted how a package can be built. These were removed in the v1.0 specification and will be reassessed and re-added as indicated in the -[future directions](future-directions.md). +[future directions]. ### Choose an appropriate build platform @@ -131,7 +131,7 @@ build platform is often a hosted, multi-tenant build service, but it could be a system of multiple independent rebuilders, a special-purpose build platform used by a single software project, or even an individual's workstation. Ideally, one build platform is used by many different software packages so that consumers can -[minimize the number of trusted platforms](principles.md). For more background, +[minimize the number of trusted platforms]. For more background, see [Build Model](terminology.md#build-model). The build platform is responsible for providing two things: [provenance @@ -180,7 +180,7 @@ Provenance. - *Authenticity:* No requirements. - *Accuracy:* No requirements. -[SLSA Provenance]: provenance.md +[SLSA Provenance]: ../../spec/v1.0/provenance.md [associated suite]: ../../attestation-model#recommended-suite ✓✓✓ @@ -221,8 +221,7 @@ build platform (i.e. outside the trust boundary), except as noted below. - Exceptions for fields that MAY be generated by a tenant of the build platform: - The names and cryptographic digests of the output artifacts, i.e. `subject` in [SLSA Provenance]. See [forge output digest of the - provenance](threats#forged-digest) for explanation of why this is - acceptable. + provenance] for explanation of why this is acceptable. - Any field that is not marked as REQUIRED for Build L2. For example, `resolvedDependencies` in [SLSA Provenance] MAY be tenant-generated at Build L2. Builders SHOULD document any such cases of tenant-generated @@ -257,7 +256,7 @@ build platform (i.e. outside the trust boundary), except as noted below. - Completeness of resolved dependencies is best effort. Note: This requirement was called "non-falsifiable" in the initial -[draft version (v0.1)](../v0.1/requirements.md#non-falsifiable). +[draft version (v0.1)](../../spec/v0.1/requirements.md#non-falsifiable). ✓ @@ -339,3 +338,6 @@ considered in the [future directions]. [package ecosystem]: verifying-artifacts.md#package-ecosystem [draft version (v0.1)]: ../../spec/v0.1/requirements.md [future directions]: ../../spec/v1.0/future-directions.md +[Threats and mitigations]: ../../spec/v1.0/threats.md +[forge output digest of the provenance]: ../../spec/v1.0/threats#forged-digest +[minimize the number of trusted platforms]: ../../spec/v1.0/principles.md diff --git a/docs/source/draft/source-requirements.md b/docs/source/draft/source-requirements.md index 59249756d..0883fb665 100644 --- a/docs/source/draft/source-requirements.md +++ b/docs/source/draft/source-requirements.md @@ -319,7 +319,7 @@ Summary attestations are issued by some authority that has sufficient evidence t revision's source level. Summary attestations convey properties about the revision as a whole and summarize properties computed over all the changes that contributed to that revision over its history. -The source track issues summary attestations using [Verification Summary Attestations (VSAs)](./verification_summary.md) as follows: +The source track issues summary attestations using [Verification Summary Attestations (VSAs)] as follows: 1. `subject.uri` SHOULD be set to a human readable URI of the revision. 2. `subject.digest` MUST include the revision identifier (e.g. `gitCommit`) and MAY include other digests over the contents of the revision (e.g. `gitTree`, `dirHash`, etc...). diff --git a/docs/spec/draft/faq.md b/docs/spec/draft/faq.md index 90ed7bb8c..7be9a4dcd 100644 --- a/docs/spec/draft/faq.md +++ b/docs/spec/draft/faq.md @@ -89,7 +89,7 @@ Jenkins plugin. 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 +platform as indicated in the [Terminology]. The use of the word `system` still exists related to software and services within the build platform and to systems outside of a build platform like change management systems. @@ -177,9 +177,10 @@ Some common situations may include: Additional requirements on the self-hosted runners may be added to Build levels greater than L3 when such levels get defined. -[build level requirements]: requirements.md +[build level requirements]: ../../build/v1.0/requirements.md [GitHub Actions]: https://docs.github.com/en/actions/hosting-your-own-runners [Software Bill of Materials (SBOM)]: https://ntia.gov/sbom [SLSA Provenance]: provenance.md [Build track]: levels.md#build-track [in-toto Attestation Framework]: https://github.com/in-toto/attestation/blob/main/spec/ +[Terminology]: ../../build/v1.0/terminology.md diff --git a/docs/spec/draft/future-directions.md b/docs/spec/draft/future-directions.md index 21be81619..f46ff9233 100644 --- a/docs/spec/draft/future-directions.md +++ b/docs/spec/draft/future-directions.md @@ -42,7 +42,7 @@ of build platforms as they are operated. The initial [draft version (v0.1)] of SLSA included a section on [common requirements](../v0.1/requirements.md#common-requirements) that formed the foundation of the guidance for -[verifying build systems](verifying-systems.md), which **may or may not** form +[verifying build systems](../../build/v1.0/verifying-systems.md), which **may or may not** form the basis for a future Build Platform Operations track: - Controls for approval, logging, and auditing of all physical and remote diff --git a/docs/spec/draft/threats.md b/docs/spec/draft/threats.md index 43137fa8a..042da222c 100644 --- a/docs/spec/draft/threats.md +++ b/docs/spec/draft/threats.md @@ -9,7 +9,7 @@ supply chain threats that SLSA is aiming to protect against, see [Supply chain t The examples on this page are meant to: -- Explain the reasons for each of the SLSA [requirements](requirements.md). +- Explain the reasons for each of the SLSA [requirements]. - Increase confidence that the SLSA requirements are sufficient to achieve the desired [level](levels.md) of integrity protection. - Help implementers better understand what they are protecting against so that @@ -40,7 +40,7 @@ along those same lines. Keep in mind that dependencies are [highly recursive](#dependency-threats), so each dependency has its own threats (A) through (I), and the same for *their* dependencies, and so on. For a more detailed explanation of the supply chain model, see -[Terminology](terminology.md). +[Terminology]. Importantly, producers and consumers face *aggregate* risk across all of the software they produce and consume, respectively. Many organizations produce @@ -57,7 +57,7 @@ This includes the threat of an authorized individual introducing an unauthorized change---in other words, an insider threat. SLSA v1.0 does not address source threats, but we anticipate doing so in a -[future version](current-activities.md#source-track). In the meantime, the +[future version](/current-activities.md#source-track). In the meantime, the threats and potential mitigations listed here show how SLSA v1.0 can fit into a broader supply chain security program. @@ -360,7 +360,7 @@ source, dependency, and/or process that is not intended by the software producer. The SLSA Build track mitigates these threats when the consumer -[verifies artifacts](verifying-artifacts.md) against expectations, confirming +[verifies artifacts] against expectations, confirming that the artifact they received was built in the expected manner. ### (D) External build parameters @@ -886,7 +886,7 @@ output artifact. including OS images, as any other artifact to be verified prior to use. The threats described in this document apply recursively to build tooling as do the mitigations and examples. A future -[Build Environment track](current-activities#build-environment-track) may +[Build Environment track](/current-activities#build-environment-track) may provide more comprehensive guidance on how to address more specfiic aspects of this threat. @@ -1063,7 +1063,7 @@ collision resistance. -[apply SLSA recursively]: verifying-artifacts.md#step-3-optional-check-dependencies-recursively +[apply SLSA recursively]: ../../build/v1.0/verifying-artifacts.md#step-3-optional-check-dependencies-recursively [authentic]: requirements.md#provenance-authentic [exists]: requirements.md#provenance-exists [isolated]: requirements.md#isolated @@ -1072,3 +1072,6 @@ collision resistance. [supply chain threats]: threats-overview [vsa]: verification_summary [vsa_verification]: verification_summary#how-to-verify +[Terminology]: ../../build/v1.0/terminology.md +[requirements]: ../../build/v1.0/requirements.md +[verifies artifacts]: ../build/v1.0/verifying-artifacts.md