Fix all 404 links

content/en/about/overview.md

@@ -16,19 +16,19 @@ It’s free to use for all developers and software providers, with Sigstore’s
 
 ## How to use Sigstore
 
-* I want to [Quick Start](/signing/quickstart/)
-* I want to [sign a blob](signing/signing_with_blobs/)
-* I want to [sign a container](signing/signing_with_containers/)
-* I want to [Sign Git commits with Gitsign](/signing/gitsign/)
-* I want to [verify entries with Cosign](/verifying/verify/)
+- I want to [Quick Start](/signing/quickstart/)
+- I want to [sign a blob](signing/signing_with_blobs/)
+- I want to [sign a container](signing/signing_with_containers/)
+- I want to [Sign Git commits with Gitsign](/signing/gitsign/)
+- I want to [verify entries with Cosign](/verifying/verify/)
 
 ## How Sigstore works
 
-A Sigstore client, such as Cosign, requests a certificate from Fulcio, a code-signing certificate authority. A verifiable OpenID Connect identity token, which contains a user's email address or service account, is provided in the request. Fulcio verifies this token and issues a short-lived certificate bound to the provided identity. 
+A Sigstore client, such as Cosign, requests a certificate from Fulcio, a code-signing certificate authority. A verifiable OpenID Connect identity token, which contains a user's email address or service account, is provided in the request. Fulcio verifies this token and issues a short-lived certificate bound to the provided identity.
 
 You don’t have to manage signing keys, and Sigstore services never obtain your private key. The public key that a Sigstore client creates gets bound to the issued certificate, and the private key is discarded after a single signing.
 
-After the client signs the artifact, the artifact's digest, signature and certificate are persisted in Rekor, an immutable, append-only transparency ledger, so that signing events can be publicly audited. Identity owners can monitor the log to verify that their identity is being properly used. This also timestamps the signing event, so that the short-lived certificate can be later verified. 
+After the client signs the artifact, the artifact's digest, signature and certificate are persisted in Rekor, an immutable, append-only transparency ledger, so that signing events can be publicly audited. Identity owners can monitor the log to verify that their identity is being properly used. This also timestamps the signing event, so that the short-lived certificate can be later verified.
 
 For verifying an artifact, a Sigstore client will verify the signature on the artifact using the public key from the certificate, verify the identity in the certificate matches an expected identity, verify the certificate's signature using Sigstore's root of trust, and verify proof of inclusion in Rekor.
 
@@ -46,9 +46,9 @@ Sigstore is a Linux Foundation project backed by Google, Red Hat and Purdue Univ
 
 Up to date documentation, best practices and detailed scenarios for Sigstore live here. These pages are maintained by the community and intended to help anyone get set up easily with any of the technologies, to find what you’re looking for fast. It’s also where we keep all the relevant pages for the Sigstore trust root, from ceremonies to security practices.
 
-Ready to jump in? Check the [contributing guidelines](/contributing/).
+Ready to jump in? Check the [contributing guidelines](/about/contributing/).
 
 ## Learn more
 
 - [Sigstore YouTube Channel](https://www.youtube.com/@projectsigstore)
-- [Sigstore Blog](https://blog.sigstore.dev/) 
+- [Sigstore Blog](https://blog.sigstore.dev/)

content/en/about/security.md

@@ -6,28 +6,31 @@ title: Security Model
 weight: 3
 ---
 
-The Sigstore security model has a few key components, each aimed at establishing trust or proving identity. For a quick overview of the key services mentioned in this document, see [Tooling](/tooling/).
+The Sigstore security model has a few key components, each aimed at establishing trust or proving identity. For a quick overview of the key services mentioned in this document, see [Tooling](/about/tooling/).
 
 ## Proving Identity in Sigstore
 
-Sigstore relies on the widely used OpenID Connect (OIDC) protocol to prove identity. When running something like `cosign sign`, users will complete an OIDC flow and authenticate via an identity provider (GitHub, GitLab, Google, etc.) to prove they are the owner of their account. Similarly, automated systems (like GitHub Actions) can use Workload Identity or [SPIFFE](https://spiffe.io/) Verifiable Identity Documents (SVIDs) to authenticate themselves via OIDC. The identity and issuer associated with the OIDC token is embedded in the short-lived certificate issued by Sigstore’s Certificate Authority, Fulcio. 
+Sigstore relies on the widely used OpenID Connect (OIDC) protocol to prove identity. When running something like `cosign sign`, users will complete an OIDC flow and authenticate via an identity provider (GitHub, Google, etc.) to prove they are the owner of their account. Similarly, automated systems (like GitHub Actions) can use Workload Identity or [SPIFFE](https://spiffe.io/) Verifiable Identity Documents (SVIDs) to authenticate themselves via OIDC. The identity and issuer associated with the OIDC token is embedded in the short-lived certificate issued by Sigstore’s Certificate Authority, Fulcio.
 
 ## Sigstore’s Trust Model
 
-Sigstore’s trust model originates from the Trust Root and chains down to short-lived certificates issued by Fulcio. 
+Sigstore’s trust model originates from the Trust Root and chains down to short-lived certificates issued by Fulcio.
 
 ### Sigstore’s Trust Root
 
 The Trust Root, which was established during a public [root key signing ceremony](https://www.youtube.com/watch?v=GEuFsc8Zm9U), is made up of a rotation of five keyholders from varying companies and academic institutions who contribute to Sigstore. It leverages the principles of [The Update Framework](https://theupdateframework.io/) (TUF), a set of defined attacks and threat models specific to software distribution systems. TUF provides a cleverly designed set of protocols to protect against these types of attacks, which the Trust Root follows.
 
 The Sigstore Trust Root is used to secure the keys used by the entire Sigstore project. It allows individuals and systems to automatically retrieve trusted keys and certificates used to verify artifacts produced by the Sigstore ecosystem. Using the Sigstore Trust Root, end users can verify:
-* Certificates issued by Fulcio
-* Entries in the Rekor transparency log
+
+- Certificates issued by Fulcio
+- Entries in the Rekor transparency log
+
 This allows end users to verify (and trust) that the distributors of the software they use are who they say they are.
 
 For more details on the Trust Root or the key signing ceremony, see [A New Kind of Trust Root](https://blog.sigstore.dev/a-new-kind-of-trust-root-f11eeeed92ef). For an overview of TUF, see [The Update Framework and You](https://blog.sigstore.dev/the-update-framework-and-you-2f5cbaa964d5).
 
 ### Rekor Security Model
+
 The Rekor service provides a transparency log of software signatures. The log is append-only and once entries are added they cannot be modified; a valid log can be cryptographically verified by any third-party. As entries are appended into this log, Rekor periodically signs the full [Merkle tree](https://transparency.dev) along with a timestamp.
 
 An entry in Rekor provides a single-party attestation that a piece of data existed prior to a certain time. These timestamps and the contents of the log cannot be tampered with or removed later, providing long-term trust. This long-term trust also requires that the log is monitored.
@@ -36,24 +39,24 @@ Transparency Logs make it hard to forge timestamps long term, but in short time
 
 ### Fulcio Security Model
 
-One of the targets secured by the Sigstore Trust Root is the Fulcio root certificate, which is used to issue short-lived code signing certificates. 
+One of the targets secured by the Sigstore Trust Root is the Fulcio root certificate, which is used to issue short-lived code signing certificates.
 
-**Certificate Transparency Log**
+### Certificate Transparency Log
 
 Fulcio assumes that a valid OIDC token from a trusted provider is sufficient “proof of ownership” of the associated identity. To mitigate against OIDC compromise, Fulcio appends certificates to an immutable, append-only cryptographically verifiable transparency log. This means:
 
-* Fulcio MUST publish all certificates to the log.
-* Clients MUST NOT trust certificates that are not in the log.
+- Fulcio MUST publish all certificates to the log.
+- Clients MUST NOT trust certificates that are not in the log.
 
 As a result, users can detect any mis-issued certificates, either due to the CA acting maliciously or a compromised OIDC identity provider. Combined with Rekor's signature transparency, artifacts signed with compromised accounts can be identified (auditability).
 
 _Note: Fulcio itself does not monitor the certificate transparency log; users are responsible for monitoring the log for unauthorized certificates issued to their identities._
 
-**Short Lived Certificates**
+### Short Lived Certificates
 
 Fulcio also uses short-lived certificates as a solution to the key management problem. Traditional signing involves issuing long-lived certificates, but this method assumes that users won’t lose their private key or that the key won’t get stolen or otherwise compromised for long periods of time.
 
-Fulcio was designed to avoid revocation by issuing short-lived certificates instead. When signing, the user only needs to know that the artifact was signed while the certificate was valid. 
+Fulcio was designed to avoid revocation by issuing short-lived certificates instead. When signing, the user only needs to know that the artifact was signed while the certificate was valid.
 
 How can a user do that?
 
@@ -63,19 +66,20 @@ End users can leverage Fulcio's short-lived code signing certificates and Rekor'
 
 Storing the signature in a transparency log also makes certificates easily discoverable so that maintainers don’t have to worry about public key distribution.
 
-**Ephemeral Keys**
+### Ephemeral Keys
 
 Sigstore clients like Cosign can also eliminate the key management problem by using ephemeral keys. These ephemeral keys only exist in memory; the private key never hits disk and is never known by Sigstore services.
 
 Cosign will:
+
 1. Generate an ephemeral public/private keypair in memory
 1. Bind the public key to a short-lived certificate requested from Fulcio
 1. Sign an artifact with the ephemeral private key while the certificate is still valid
 1. Store the signature and certificate in Rekor as proof the artifact was signed while the certificate was valid
 
 Clients like Cosign only need to find the correct Rekor entry to verify the artifact.
 
-## What Sigstore *Doesn't* Guarantee
+## What Sigstore _Doesn't_ Guarantee
 
 - If an OIDC identity or OIDC provider is compromised, Fulcio might issue unauthorized certificates. However, these certificates are useless unless they are published to the certificate transparency log, so such compromise can be detected.
 - If Fulcio is compromised, it might issue unauthorized certificates. However, like before, these should be detectable.

content/en/about/support.md

@@ -10,11 +10,11 @@ If you are not able to find the relevant information to solve your issue, you ca
 
 This page describe how you could get in touch with us to get support.
 
-# Help from the community
+## Help from the community
 
-Sigstore has a [Slack community](/community/#slack). Please post any support request in `#general` channel.
+Sigstore has a [Slack community](https://sigstore.slack.com/), and you can [request an invite at this link](https://join.slack.com/t/sigstore/shared_invite/zt-1z7jzpemb-xEKSUtpgDFXpIEMwMYZQKQ). Please post any support requests in the `#general` channel.
 
-# Help from project maintainers
+## Help from project maintainers
 
 Each repository has a `CODEOWNERS` file describing current maintainers. Join our Slack channel and get in touch with them.
 
@@ -28,6 +28,6 @@ Each repository has a `CODEOWNERS` file describing current maintainers. Join our
 [rekor]: https://github.com/sigstore/rekor/blob/main/CODEOWNERS
 [sigstore]: https://github.com/sigstore/sigstore/blob/main/CODEOWNERS
 
-# Asking questions
+## Asking questions
 
-We welcome questions! You can either join the [Slack community][sc] and post them on `#general` channel or open a GitHub issue in the relevant repository.
+We welcome questions! You can either join the [Slack community](https://sigstore.slack.com/) and post them on `#general` channel or open a GitHub issue in the relevant repository.