Fix yet more broken links

Signed-off-by: Arnaud J Le Hors <[email protected]>

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

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
 
 <td>✓<td>✓<td>✓
@@ -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).
 
 <td> <td> <td>✓
 </table>
@@ -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

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...).

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

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

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.
 
 <!-- Links -->
 
-[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