fixing anchor link references (#1989)

## Type of change
<!-- Please be sure to add the appropriate label to your PR. -->
This PR fixes a few anchor links that have changed since the recent
Images section reorganization. I am also taking this opportunity to fix
the URLs posted in #1736

### What should this PR do?
<!-- Does this PR resolve an issue? Please include a reference to it.
-->
Resolves #1736
Resolves chainguard-dev/internal#4532

### Why are we making this change?
<!-- What larger problem does this PR address? -->
404s are a bad look!

### What are the acceptance criteria? 
<!-- What should be happening for this PR to be accepted? Please list
criteria. -->
<!-- Do any stakeholders need to be tagged in this review? If so, please
add them. -->

I'm also going to try to fix the workflow to notify someone other than
Jamon when there are 404s

### How should this PR be tested?
<!-- What should your reviewer do to test this PR? Please list steps.
-->
I'm editing links directly and fixing aliases where possible, Please
confirm that these changes make sense

---------

Signed-off-by: Mark Drake <[email protected]>

.github/workflows/check-links.yaml

@@ -78,7 +78,7 @@ jobs:
           if [ -z "${existing}" ]; then
             gh issue create \
               --title "[chainlink] check links on edu.chainguard.dev" \
-              --assignee jamonation \
+              --assignee SharpRake \
               --label automated \
               --body-file issue-body.txt
           else

content/chainguard/chainguard-images/features/eol-notifications.md

@@ -31,7 +31,7 @@ The following criteria must by met in order to qualify for an end-of-life email
 
 * A given Image has been pulled in your organization registry within the last 30 days.
 * A given Image must be based on software with multiple concurrent release tracks, according to our [Product Release Lifecycle document](/chainguard/chainguard-images/versions/). 
-    * This means that any Image that only maintains a [single stream of release versions](/chainguard/chainguard-images/versions/#single-release-track-maintained-by-a-given-open-source-project) at a time will not receive EOL notifications. 
+    * This means that any Image that only maintains a [single stream of release versions](/chainguard/chainguard-images/about/versions/#single-release-track-maintained-by-a-given-open-source-project) at a time will not receive EOL notifications. 
 * The software that a given Chainguard Image is named for (the main software package in the Image) must reach an EOL milestone according to Chainguard's internal records, which are based on the records at [endoflife.date](https://endoflife.date/).
 * Chainguard must have an updated tag available to pull in your organization registry.
 

content/chainguard/chainguard-images/getting-started/nginx/index.md

@@ -133,10 +133,10 @@ p {
 
 After copying the code into the `stylesheet.css` file, save and close it.
 
-Next, you will pull down the `linky.png` file using `curl`. Always [inspect the URL](https://raw.githubusercontent.com/chainguard-dev/edu-images-demos/734e6171ee69f0e0dbac95e6ebc1759ac18bf00a/nginx/data/linky.png) before downloading it to ensure it comes from a safe and trustworthy location.
+Next, you will pull down the `linky.png` file using `curl`. Always [inspect the URL](https://raw.githubusercontent.com/chainguard-dev/edu-images-demos/fb54a9767a5474716398ac33de81d66e263d4c6f/nginx/data/linky.png) before downloading it to ensure it comes from a safe and trustworthy location.
 
 ```shell
-curl -O https://raw.githubusercontent.com/chainguard-dev/edu-images-demos/734e6171ee69f0e0dbac95e6ebc1759ac18bf00a/nginx/data/linky.png
+curl -O https://raw.githubusercontent.com/chainguard-dev/edu-images-demos/fb54a9767a5474716398ac33de81d66e263d4c6f/nginx/data/linky.png
 ```
 
 Now, return to the `nginxdemo` directory you made earlier. 

content/chainguard/chainguard-images/how-to-use/how-to-use-chainguard-images.md

@@ -139,7 +139,7 @@ It often happens that you want a [distroless](/chainguard/chainguard-images/gett
 
 1. Compile the dependency from source and use a multi-stage Dockerfile to create a new base image. This works, but may require considerable effort to get the dependency compiling and to keep it up to date. This process quickly becomes untenable if you require several dependencies.
 2. Use the `wolfi-base` image that includes apk tools to install the package in the traditional Dockerfile manner. This works but sacrifices a lot of the advantages of the “distroless” philosophy.
-3. Use Chainguard’s [melange and apko tooling to create a custom base image](/open-source/melange/tutorials/getting-started-with-melange/). This keeps the image as minimal as possible without sacrificing maintainability.
+3. Use Chainguard’s [melange and apko tooling to create a custom base image](/open-source/build-tools/melange/getting-started-with-melange/). This keeps the image as minimal as possible without sacrificing maintainability.
 
 ### Using the wolfi-base Image
 The `wolfi-base` image is a good starting point to try out Chainguard Images. Unlike most of the other images, which are strictly distroless, `wolfi-base` includes the `apk` package manager, which facilitates composing additional software into it. Just keep in mind that the resulting image will be a little larger due to the extra software and won't have a comprehensive SBOM that covers all your dependencies, since the new software will be added as a layer on top of `wolfi-base`.

content/chainguard/chainguard-images/how-to-use/images-directory/index.md

@@ -2,8 +2,8 @@
 title: "Using the Chainguard Directory and Console"
 linktitle: "Images Directory"
 aliases: 
-- /chainguard/chainguard-images/images-directory
-- /chainguard/chainguard-images/images-features/images-directory
+- /chainguard/chainguard-images/working-with-images/images-directory
+- /chainguard/chainguard-images/how-to-use/images-directory
 type: "article"
 description: "A walkthrough of the Chainguard directory and console."
 date: 2024-02-23T11:07:52+02:00

content/chainguard/chainguard-images/how-to-use/retrieve-image-sboms/index.md

@@ -66,7 +66,7 @@ The other extra argument is the `--predicate-type` flag, required to specify whi
 
 ## Image SBOMs in the Chainguard Console
 
-You can also find Image SBOMs in the [Chainguard Console](https://console.chainguard.dev). After signing in to the Console and clicking either the **Public images** or, if available, **Organization images** you'll be presented with a list of images. Clicking on any of these will take you to the image's landing page. There, you can click on the [**SBOM** tab](/chainguard/chainguard-images/images-directory/#sboms-tab) to find and download the SBOM for the given Image. 
+You can also find Image SBOMs in the [Chainguard Console](https://console.chainguard.dev). After signing in to the Console and clicking either the **Public images** or, if available, **Organization images** you'll be presented with a list of images. Clicking on any of these will take you to the image's landing page. There, you can click on the [**SBOM** tab](/chainguard/chainguard-images/how-to-use/images-directory/#sbom-tab) to find and download the SBOM for the given Image. 
 
 The following example shows the **SBOM** tab for the `postgres` Image.
 

content/chainguard/chainguard-images/how-to-use/verifying-chainguard-images-and-metadata-signatures-with-cosign.md

@@ -3,6 +3,7 @@ title: "Verifying Chainguard Images and Metadata Signatures with Cosign"
 linktitle: "Verifying Images"
 aliases:
   - /chainguard/chainguard-images/verifying-images-with-cosign
+  - /chainguard/chainguard-images/verifying-chainguard-images-and-metadata-signatures-with-cosign/
   - /chainguard/chainguard-images/how-to-use/verifying-images-with-cosign
 type: "article"
 description: "A walkthrough of verifying Chainguard Images and metadata signatures with Cosign."

content/chainguard/chainguard-images/overview.md

@@ -71,7 +71,7 @@ The major advantage of distroless images is the reduced size and complexity, whi
 
 You can review more comparisons of Chainguard Images and external images by checking out our [Vulnerability Comparisons](/chainguard/chainguard-images/vuln-comparison/) dashboard.
 
-`chainctl`, Chainguard's command line interface tool, comes with a useful `diff` feature that also allows you to [compare two Chainguard Images](/chainguard/chainguard-images/comparing-images/comparing-images/).
+`chainctl`, Chainguard's command line interface tool, comes with a useful `diff` feature that also allows you to [compare two Chainguard Images](/chainguard/chainguard-images/how-to-use/comparing-images/).
 
 
 ## Architecture

content/chainguard/chainguard-images/staying-secure/security-advisories/how-to-use/index.md

@@ -4,6 +4,7 @@ linktitle: "Using Advisories"
 aliases: 
 - /chainguard/chainguard-images/security-advisories
 - /chainguard/chainguard-images/images-features/security-advisories
+- /chainguard/chainguard-images/working-with-images/security-advisories
 - /chainguard/chainguard-images/working-with-images/security-advisories/how-to-use/
 - /chainguard/chainguard-images/staying-secure/security-advisories/how-to-use/
 type: "article"

content/chainguard/chainguard-images/staying-secure/updating-images/considerations-for-image-updates.md

@@ -70,7 +70,7 @@ Many systems will default to using the `latest` tag in certain cases if you don'
 
 One of the most important features of container builds is their *reproducibility* as you would like to ensure that you are using the same image each time. However, container tags are mutable, meaning that they can change over time. If you pin your application to a specific image tag and then the image associated with that tag gets updated and you redeploy or pull the image again, your application will be using a different image than it was before. Eventually, the image could change to the point that it no longer works with your application.
 
-When it comes to container versions, pinning an application to a major version is usually an acceptable practice since minor version increases typically won't break things. That being said, the potential for "jumping” across minor or major versions without warning means that pinning an application to a major or minor tag isn't suitable for many production workflows. To avoid this problem, it's recommended to [pin projects to an *image digest*](/chainguard/chainguard-images/how-to-use-chainguard-images/#pulling-by-digest). A digest is a content-based hash of the image contents and is guaranteed to be immutable. Because a digest will always point to the same image, its reproducibility is guaranteed. To find the digest for an image, users can run a command like the following.
+When it comes to container versions, pinning an application to a major version is usually an acceptable practice since minor version increases typically won't break things. That being said, the potential for "jumping” across minor or major versions without warning means that pinning an application to a major or minor tag isn't suitable for many production workflows. To avoid this problem, it's recommended to [pin projects to an *image digest*](/chainguard/chainguard-images/about/versions/#single-release-track-maintained-by-a-given-open-source-project). A digest is a content-based hash of the image contents and is guaranteed to be immutable. Because a digest will always point to the same image, its reproducibility is guaranteed. To find the digest for an image, users can run a command like the following.
 
 ```sh
 docker images --digests cgr.dev/chainguard/wolfi-base
@@ -101,4 +101,4 @@ To reiterate, there's no one-size-fits-all approach to keeping one's images up t
 
 * [How to Use Chainguard Images](/chainguard/chainguard-images/how-to-use-chainguard-images/)
 * [How to Use Container Image Digests to Improve Reproducibility](/chainguard/chainguard-images/videos/container-image-digests/)
-* [How To Compare Chainguard Images with chainctl](/chainguard/chainguard-images/comparing-images/)
+* [How To Compare Chainguard Images with chainctl](/chainguard/chainguard-images/how-to-use/comparing-images/)

content/chainguard/chainguard-images/staying-secure/updating-images/how-eol-software-accumulates-cves/index.md

@@ -99,7 +99,7 @@ Ninety-seven percent of these vulnerabilities are within Debian packages. Per [t
 <center><img src="EOL_3.png" alt="Chart highlighting vulnerability counts across the latest cycle release version of Traefik and the associated EOL date for each cycle. The chart shows older versions have significantly more vulnerabilities than newer ones." style="width:950px;"></center>
 <br />
 
-When scanning the official [Alpine-based image for Traefik](https://github.com/traefik/traefik-library-image/tree/master/alpine) with Grype, Chainguard's researchers found that the image versions generally accumulated fewer vulnerabilities than typical, with an average of 25 vulnerabilities identified every six months, as shown in the previous table.
+When scanning the official [Alpine-based image for Traefik](https://github.com/traefik/traefik-library-image/tree/master/tmpl/alpine) with Grype, Chainguard's researchers found that the image versions generally accumulated fewer vulnerabilities than typical, with an average of 25 vulnerabilities identified every six months, as shown in the previous table.
 
 Take version 2.9 of Traefik as an example. It was released on October 3, 2022, with security support provided until April 24, 2023, which is roughly six months. The final update for this version, 2.9.10, was made available on April 6, 2023, just three weeks before the end of its support lifecycle.
 

content/chainguard/chainguard-images/staying-secure/updating-images/renovate/index.md

@@ -101,7 +101,7 @@ At the time of writing, version 3.12 was the current version of the Python image
 
 ![Screenshot showing GitHub PR from Renovate updating python version](python_update.png)
 
-Not all images use semantic versioning. Refer to the [Renovate documentation](https://docs.renovatebot.com/modules/manager/dockerfile/\#additional-information) for details on how to support different schemes.
+Not all images use semantic versioning. Refer to the [Renovate documentation](https://docs.renovatebot.com/) for details on how to support different schemes.
 
 Ideally, image references should also be pinned to a digest, as shown in the following section.
 

content/open-source/build-tools/apko/troubleshooting.md

@@ -52,7 +52,7 @@ If this is your case, you should find error messages similar to this when enabli
 With melange-built package(s), make sure you have a volume sharing your apko / melange files with the location `/work` inside the apko container.
 
 ### The apk index is missing
-If you have a functional volume sharing your packages with the apko container and you're still getting this error, make sure you built a valid apk index as described in [step 4 of the Getting Started with melange Guide](/open-source/melange/tutorials/getting-started-with-melange/#step-4--building-your-apk).
+If you have a functional volume sharing your packages with the apko container and you're still getting this error, make sure you built a valid apk index as described in [step 4 of the Getting Started with melange Guide](/open-source/build-tools/melange/getting-started-with-melange/#4--building-the-minicli-apk-with-melange).
 
 If this is your case, you should find error messages similar to this when enabling debug info with the `--debug` flag:
 

content/open-source/oci/what-are-oci-artifacts.md

@@ -51,7 +51,7 @@ An **SBOM**, or software bill of materials, is a formally structured list of lib
 The open source tool [Cosign](https://github.com/sigstore/cosign), part of the [Sigstore](https://www.sigstore.dev/) project, enables software engineers to store their SBOMs and signatures as artifacts in the same container registry where they store their associated images. However, given the lack of support for OCI Artifacts across registries, Cosign ships all SBOM and signature artifacts as OCI Images and not as OCI Artifacts. In this way, software engineers can take advantage of Cosign regardless of whether their container registry supports the OCI Artifact manifest format or not.
 
 To learn more about storing signatures as artifacts, visit the [section on counter signing](
-https://github.com/sigstore/cosign#counter-signing) in the Cosign repo. To learn more about storing SBOMs as artifacts, visit the [Cosign SBOM Specification](https://github.com/sigstore/cosign/blob/b6aaddc05cbf04819221f9c7084399d4615b9d27/specs/SBOM_SPEC.md) page on Github or the [section on signing SBOMs](https://docs.sigstore.dev/cosign/other_types/#sboms-software-bill-of-materials) in Sigstore’s documentation.
+https://github.com/sigstore/cosign#counter-signing) in the Cosign repo. To learn more about storing SBOMs as artifacts, visit the [Cosign SBOM Specification](https://github.com/sigstore/cosign/blob/b6aaddc05cbf04819221f9c7084399d4615b9d27/specs/SBOM_SPEC.md) page on Github or the [section on signing SBOMs](https://docs.sigstore.dev/cosign/signing/other_types/#sboms-software-bill-of-materials) in Sigstore’s documentation.
 
 ## Considerations
 Community usage and guidance of OCI artifacts and Artifacts are actively evolving and there are a few considerations to keep in mind when you are planning on using them. As noted earlier, not all registries support OCI Artifacts, and the [OCI Image Specification](https://github.com/opencontainers/image-spec) recommends avoiding the use of them if you are concerned about portability. Recommended practices are still also under debate, giving rise to the [OCI Reference Types Working Group](https://github.com/opencontainers/wg-reference-types), which is considering different ways of describing and handling objects stored in an OCI registry. You can read a more about the proposals the group is currently considering by visiting the [Intro to OCI Reference Types](https://www.chainguard.dev/unchained/intro-to-oci-reference-types) post on Chainguard’s blog.

content/open-source/sigstore/fulcio/how-to-generate-a-fulcio-certificate.md

@@ -16,7 +16,7 @@ toc: true
 
 _An earlier version of this material was published in the [Fulcio chapter](https://learning.edx.org/course/course-v1:LinuxFoundationX+LFS182x+2T2022/block-v1:LinuxFoundationX+LFS182x+2T2022+type@sequential+block@2fbe6328019c4b1fbf934bd3bfb7e308/block-v1:LinuxFoundationX+LFS182x+2T2022+type@vertical+block@1f71fcbe8219471fb82e25731b18be11) of the Linux Foundation [Sigstore course](https://learning.edx.org/course/course-v1:LinuxFoundationX+LFS182x+2T2022/home)._
 
-In this tutorial, we are going to create and examine a Fulcio certificate to demonstrate how Fulcio can work in practice. To follow along, you will need Cosign installed on your local system. If you haven't installed Cosign yet, you can follow the instructions described in [How to Install Cosign](/open-source/sigstore/cosign/how-to-install-cosign/), or you can follow one of the installation methods described in the [official documentation](https://docs.sigstore.dev/cosign/installation/).
+In this tutorial, we are going to create and examine a Fulcio certificate to demonstrate how Fulcio can work in practice. To follow along, you will need Cosign installed on your local system. If you haven't installed Cosign yet, you can follow the instructions described in [How to Install Cosign](/open-source/sigstore/cosign/how-to-install-cosign/), or you can follow one of the installation methods described in the [official documentation](https://docs.sigstore.dev/cosign/system_config/installation/).
 
 Pease note that using Cosign requires Go v1.16 or higher. The Go Project provides [official download instructions](https://go.dev/doc/install).
 

content/open-source/sigstore/policy-controller/policies/enforce-sbom-attestation-with-policy-controller.md

@@ -151,4 +151,4 @@ Delete the pod once you're done experimenting with it:
 kubectl delete pod mysbomattestedimage
 ```
 
-To learn more about how the Policy Controller uses Cosign to verify and admit images, review the [Cosign](https://docs.sigstore.dev/cosign/overview/) Sigstore documentation.
+To learn more about how the Policy Controller uses Cosign to verify and admit images, review the [Cosign](https://docs.sigstore.dev/cosign/signing/overview/) Sigstore documentation.

content/open-source/sigstore/policy-controller/policies/maximum-image-age-policy-controller.md

@@ -165,4 +165,4 @@ Delete the pod once you're done experimenting with it:
 kubectl delete pod mydailyfreshimage
 ```
 
-To learn more about how the Policy Controller uses Cosign to verify and admit images, review the [Cosign](https://docs.sigstore.dev/cosign/overview/) Sigstore documentation.
+To learn more about how the Policy Controller uses Cosign to verify and admit images, review the [Cosign](https://docs.sigstore.dev/cosign/signing/overview/) Sigstore documentation.

content/open-source/sigstore/policy-controller/policies/using-policy-controller-to-verify-signed-chainguard-images.md

@@ -100,7 +100,7 @@ spec:
         url: https://rekor.sigstore.dev
 ```
 
-The `glob: cgr.dev/chainguard/**` line, working in combination with the `authorities` section, will allow any image in the `cgr.dev/chainguard` image registry that has a [keyless signature](https://docs.sigstore.dev/signing/overview/) to be admitted into your cluster.
+The `glob: cgr.dev/chainguard/**` line, working in combination with the `authorities` section, will allow any image in the `cgr.dev/chainguard` image registry that has a [keyless signature](https://docs.sigstore.dev/cosign/signing/overview/) to be admitted into your cluster.
 
 The `- keyless` options instruct the Policy Controller what to check for when it examines the signature on any image from the `cgr.dev/chainguard` registry. The specific fields are:
 
@@ -141,4 +141,4 @@ Delete the pod once you're done experimenting with it:
 kubectl delete pod nginx
 ```
 
-To learn more about how the Policy Controller uses Cosign to verify and admit images, review the [Cosign](https://docs.sigstore.dev/cosign/overview/) Sigstore documentation.
+To learn more about how the Policy Controller uses Cosign to verify and admit images, review the [Cosign](https://docs.sigstore.dev/cosign/signing/overview/) Sigstore documentation.