Fixed all links bound to 404

All links on the docs site that resolved to 404 now lead somewhere

Some links changed to more useful or up-to-date links

Added link to Slack invite

References #43

Resolves #228

Signed-off-by: Patrick Smyth <[email protected]>

content/en/docs/about/contributing.md

@@ -64,7 +64,7 @@ The Nuxt documentation is a great first stop for anyone new to writing technical
 Resource: https://content.nuxtjs.org/
 
 ## Community
-The [sigstore/community](https://github.com/sigstore/community/) repository contains the most up-to-date information about how to get involved with the Sigstore project and its community.
+The [sigstore/community](https://github.com/sigstore/docs/community/) repository contains the most up-to-date information about how to get involved with the Sigstore project and its community.
 In this repository you can find our [code of conduct](https://github.com/sigstore/community/blob/main/CODE_OF_CONDUCT.md) and our [contributing guidelines](https://github.com/sigstore/community/blob/main/CONTRIBUTING.md).
 
 ## Mailing list
@@ -75,4 +75,4 @@ Docs and other calendar invites may be shared directly with this group, so pleas
 
 ## Slack
 
-You can also keep in touch by joining our [Slack channel](https://sigstore.slack.com). Use [this invite link](https://links.sigstore.dev/slack-invite) to join.
+You can also keep in touch by joining our [Slack channel](https://sigstore.slack.com). Use [this invite link](https://links.sigstore.dev/slack-invite) to join.

content/en/docs/about/faq.md

@@ -70,7 +70,7 @@ reasons:
    [GitHub’s trust root](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification#smime-commit-signature-verification).
 2. Gitsign’s ephemeral keys are only valid for a short time, so using standard
    x509 verification would consider the certificate invalid after expiration.
-   Verification needs to include validation via the [transparency log](/logging/overview/) to
+   Verification needs to include validation via the [transparency log](/docs/logging/overview/) to
    verify that the certificate was valid at the time it was used.
 
 We hope to work closely with GitHub to get these types of signatures recognized
@@ -90,28 +90,28 @@ The commit itself contains a signed digest of the user commit content (that is,
 the author, committer, message, etc.) along with the code signing certificate.
 This data is stored within the commit itself as part of your repository. Review
 guidance on
-[inspecting the Git commit signature](/verifying/inspecting/) for
+[inspecting the Git commit signature](/docs/verifying/inspecting/) for
 more details.
 
 #### 2. Within the Rekor transparency log
 
 To be able to verify signatures for ephemeral certs past their `Not After` time,
 Gitsign records commits and the code signing certificates to
-[Rekor](/logging/overview/). This data is a
+[Rekor](/docs/logging/overview/). This data is a
 [HashedRekord](https://github.com/sigstore/rekor/blob/e375eb461cae524270889b57a249ff086bea6c05/types.md#hashed-rekord)
 containing a SHA256 hash of the commit SHA, as well as the code signing
 certificate. Review guidance on
-[Verifying the Transparency Log](/logging/overview/#auditing-the-public-instance) for more
+[Verifying the Transparency Log](/docs/logging/overview/#auditing-the-public-instance) for more
 details.
 
 By default, data is written to the
-[public Rekor instance](/logging/overview/#auditing-the-public-instance). In
+[public Rekor instance](/docs/logging/overview/#auditing-the-public-instance). In
 particular, users and organizations may be sensitive to the data contained
 within code signing certificates returned by Fulcio, which may include user
 emails or repository identifiers. Review
-[OIDC Usage in Fulcio](/certificate_authority/oidc-in-fulcio/) for more details regarding what
+[OIDC Usage in Fulcio](/docs/certificate_authority/oidc-in-fulcio/) for more details regarding what
 data is contained in the code signing certs. Alternately, you can learn how to
-[Deploy a Rekor Server Manually](/logging/installation/#deploy-a-rekor-server-manually),
+[Deploy a Rekor Server Manually](/docs/logging/installation/#deploy-a-rekor-server-manually),
 which would set up your own Rekor instance.
 
 ### Why does a browser window open for each commit in a rebase?
@@ -120,7 +120,7 @@ For Git, each commit in a rebase is considered a distinct signing operation so
 by default an ephemeral key is generated for each commit. There are a
 few options to help automating the authentication process:
 
-- Setting the [`connectorID`](/signing/gitsign/#configuration) value can be set to
+- Setting the [`connectorID`](/docs/signing/gitsign/#configuration) value can be set to
   automatically select the desired provider for Dex-backed OIDC providers
   (including the public Sigstore instance at `oauth.sigstore.dev`). While this
   still requires a browser window to open, this does not require an extra click
@@ -157,4 +157,4 @@ Public blockchains often end up using a centralized entry point for canonicaliza
 
 ### Can I get Rekor to work with my X format, framework standard?
 
-- Yes. Using pluggable types you can create your own manifest layout and send it to Rekor. Head over to [pluggable types](/logging/pluggable-types/)
+- Yes. Using pluggable types you can create your own manifest layout and send it to Rekor. Head over to [pluggable types](/docs/logging/pluggable-types/)

content/en/docs/about/overview.md

@@ -15,11 +15,11 @@ 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](/docs/signing/quickstart/)
+* I want to [sign a blob](/docs/signing/signing_with_blobs/)
+* I want to [sign a container](/docs/signing/signing_with_containers/)
+* I want to [Sign Git commits with Gitsign](/docs/signing/gitsign/)
+* I want to [verify entries with Cosign](/docs/verifying/verify/)
 
 ## How Sigstore works
 
@@ -45,7 +45,7 @@ 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](/docs/about/contributing/).
 
 ## Learn more
 

content/en/docs/about/security.md

@@ -5,7 +5,7 @@ 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](/docs/about/tooling/).
 
 ## Proving Identity in Sigstore
 
@@ -78,4 +78,4 @@ Clients like Cosign only need to find the correct Rekor entry to verify the arti
 
 - 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.
-- If no third parties monitor the logs, then any misbehavior by Rekor and Fulcio might go undetected.
+- If no third parties monitor the logs, then any misbehavior by Rekor and Fulcio might go undetected.

content/en/docs/about/support.md

@@ -11,7 +11,7 @@ This page describe how you could get in touch with us to get support.
 
 # 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://app.slack.com/client/T01CP44M5K9). You can [join the Slack at this invite link](https://join.slack.com/t/sigstore/shared_invite/zt-1z7jzpemb-xEKSUtpgDFXpIEMwMYZQKQ). Please post any support request in `#general` channel.
 
 # Help from project maintainers
 
@@ -29,4 +29,4 @@ Each repository has a `CODEOWNERS` file describing current maintainers. Join our
 
 # 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][sc] and post them on `#general` channel or open a GitHub issue in the relevant repository.

content/en/docs/about/threat-model.md

@@ -8,7 +8,7 @@ weight: 3
 ## Introduction
 
 **What types of security analysis have you done on Sigstore?**
-This page contains the results of a threat modeling exercise on Sigstore. First, we enumerate the components of Sigstore along with third parties and infrastructure that it uses during the [“keyless” signing](/cosign/sign#keyless-signing) and verification flows. Second, we postulate an attacker that can compromise various subsets of these parties. Finally, we analyze the impact of such an attacker on these security properties. The results of a similar exercise are included in the peer-reviewed paper [Sigstore: Software Signing for Everybody](https://dl.acm.org/doi/pdf/10.1145/3548606.3560596).
+This page contains the results of a threat modeling exercise on Sigstore. First, we enumerate the components of Sigstore along with third parties and infrastructure that it uses during the [“keyless” signing](/docs/signing/overview/) and verification flows. Second, we postulate an attacker that can compromise various subsets of these parties. Finally, we analyze the impact of such an attacker on these security properties. The results of a similar exercise are included in the peer-reviewed paper [Sigstore: Software Signing for Everybody](https://dl.acm.org/doi/pdf/10.1145/3548606.3560596).
 
 This will be most useful to those building secure systems on top of Sigstore, rather than end users. The security guarantees of such systems depends on the details of integration; an example analysis can be found in [TAP-18](https://github.com/theupdateframework/taps/blob/master/tap18.md), which proposes using Sigstore identities with a [TUF](https://theupdateframework.com/) repository used to securely distribute software artifacts.
 
@@ -133,4 +133,4 @@ That policy should cover:
 * Which Sigstore instance(s) do you trust, and how do you retrieve the key material for those instances?
 * How do you handle revocation?
 
-The answers will be different in different settings. For instance, a small organization may be able to meet their security needs by requiring signatures from one fixed party, with a blocklist for revoked artifacts. A large package repository may need to manage signing identities that change frequently over time. We hope to provide more detailed guidance for a variety of settings in future documentation.
+The answers will be different in different settings. For instance, a small organization may be able to meet their security needs by requiring signatures from one fixed party, with a blocklist for revoked artifacts. A large package repository may need to manage signing identities that change frequently over time. We hope to provide more detailed guidance for a variety of settings in future documentation.

content/en/docs/key_management/import-keypair.md

@@ -8,7 +8,7 @@ weight: 510
 
 ### Import a Key Pair
 
-To use a local key not generated by cosign for signing, the key must be imported. To use a key stored in a [KMS](/cosign/kms_support/), importing is not necessary and the key can be [specified by resource name](/cosign/kms_support/#signing-and-verification).
+To use a local key not generated by cosign for signing, the key must be imported. To use a key stored in a [KMS](/docs/key_management/overview/), importing is not necessary and the key can be [specified by resource name](/docs/key_management/overview#signing-and-verification).
 
 The importing of a key pair with `cosign` is as follows.
 
@@ -29,4 +29,4 @@ $ cosign sign --key import-cosign.key $IMAGE_DIGEST
 Enter password for private key:
 tlog entry created with index: *****
 Pushing signature to: *****
-```
+```

content/en/docs/key_management/signing_with_self-managed_keys.md

@@ -26,7 +26,7 @@ To generate keys using a KMS provider, you can use the `cosign generate-key-pair
 $ cosign generate-key-pair --kms <some provider>://<some key>
 ```
 
-Read more about this in the [key management overview](/key_management/overview/).
+Read more about this in the [key management overview](/docs/key_management/overview/).
 
 The public key can be retrieved with:
 
@@ -46,4 +46,4 @@ This section shows traditional key signing from a key pair:
 $ cosign sign --key cosign.key user/demo
 Enter password for private key:
 Pushing signature to: index.docker.io/user/demo:sha256-87ef60f558bad79beea6425a3b28989f01dd417164150ab3baab98dcbf04def8.sig
-```
+```

content/en/docs/logging/CLI.md

@@ -6,11 +6,11 @@ weight: 1825
 
 The following guide is targeted towards developers / software maintainers who would like to make a provenance entry into the rekor transparency log.
 
-The steps outlined below will show how to sign your software and use the Rekor CLI to make and verify an entry. It uses GPG to demonstrate, but other types are outlined in the [Signing and Uploading Other Types](/logging/sign-upload/) page.
+The steps outlined below will show how to sign your software and use the Rekor CLI to make and verify an entry. It uses GPG to demonstrate, but other types are outlined in the [Signing and Uploading Other Types](/docs/logging/sign-upload/) page.
 
 ## Prerequisites
 
-You need to have Rekor CLI installed. See the [Installation](/logging/installation/) page for instructions.
+You need to have Rekor CLI installed. See the [Installation](/docs/logging/installation/) page for instructions.
 
 ## Sign your release
 
@@ -92,4 +92,4 @@ rekor-cli search --rekor_server https://rekor.sigstore.dev --[artifact|public-ke
 For example:
 ```
 rekor-cli search --rekor_server https://rekor.sigstore.dev --sha sha256:e2e90d1a25f90a3156a27f00f3a4179578e3132ed4f010dc3498d09175b6071a
-```
+```

content/en/docs/logging/installation.md

@@ -26,7 +26,7 @@ Rekor releases are available on the [Release page](https://github.com/sigstore/r
 
 Releases are available for both `rekor-server` and `rekor-cli`.
 
-Review [Verifying Binaries](/logging/verify-release/) for details on how to verify Rekor release binaries.
+Review [Verifying Binaries](/docs/logging/verify-release/) for details on how to verify Rekor release binaries.
 
 
 ## Build Rekor CLI manually
@@ -45,7 +45,7 @@ There are a few ways you can deploy a Rekor Server:
 1.  We have a [docker-compose](https://github.com/sigstore/rekor/blob/main/docker-compose.yml) file available.
 2.  Alternatively, you can build a Rekor server yourself.
 
-Note: The Rekor server manually creates a new Merkle tree (or shard) in the Trillian backend every time it starts up, unless an existing one is specified in via the `--trillian_log_server.tlog_id` flag. If you are building the server yourself and do not need [sharding](/rekor/sharding/) functionality, you can find the existing tree's TreeID by issuing this client command while the server is running:
+Note: The Rekor server manually creates a new Merkle tree (or shard) in the Trillian backend every time it starts up, unless an existing one is specified in via the `--trillian_log_server.tlog_id` flag. If you are building the server yourself and do not need [sharding](/docs/logging/sharding/) functionality, you can find the existing tree's TreeID by issuing this client command while the server is running:
 
 `CURRENT_TREE_ID=$(rekor-cli loginfo --format json | jq -r .TreeID)`
 
@@ -148,4 +148,4 @@ rekor-server serve --enable_retrieve_api=false
 
 #### Next Steps
 
-Congratulations! Your local Rekor server is now running. You can interact with it using the [Rekor CLI](/rekor/CLI/).
+Congratulations! Your local Rekor server is now running. You can interact with it using the [Rekor CLI](/docs/logging/cli/).

content/en/docs/logging/overview.md

@@ -18,7 +18,7 @@ Rekor fulfils the signature transparency role of sigstore’s software signing i
 
 ## Usage and installation
 
-You can download and setup the Rekor Server and Rekor CLI by following the instructions on the [Installation](/logging/installation/) page.
+You can download and setup the Rekor Server and Rekor CLI by following the instructions on the [Installation](/docs/logging/installation/) page.
 
 A public instance of Rekor can be found at [rekor.sigstore.dev](https://rekor.sigstore.dev). The public instance offers an SLO
 of 99.5% availability and is monitored by an oncall team.
@@ -37,4 +37,4 @@ to audit the log. You can also monitor the log for specified identities, though
 this feature is a work in progress and supports a limited set of identities and entry types.
 
 You can also run [omniwitness](https://github.com/transparency-dev/witness/tree/main/cmd/omniwitness) to
-audit the log, built by the team who created Trillian, which provides Rekor's verifiable log.
+audit the log, built by the team who created Trillian, which provides Rekor's verifiable log.

content/en/docs/logging/sign-upload.md

@@ -4,7 +4,7 @@ title: Signing and Uploading Other Types
 weight: 1835
 ---
 
-This documentation contains information on how to sign and upload data in different [pluggable types](/logging/pluggable-types/).
+This documentation contains information on how to sign and upload data in different [pluggable types](/docs/logging/pluggable-types/).
 
 The following are covered:
 - [Minisign](#minisign)
@@ -286,4 +286,4 @@ Body: {
   }
 }
 
-```
+```

content/en/docs/policy-controller/installation.md

@@ -23,10 +23,10 @@ The webhook also resolves the image tags to ensure the image being ran is not di
 
 The `policy-controller` admission controller will only validate resources in
 namespaces that have chosen to opt-in. See the
-[Enable policy-controller Admission Controller for Namespaces](/policy-controller/overview/#enable-policy-controller-admission-controller-for-namespaces) instructions for more details.
+[Enable policy-controller Admission Controller for Namespaces](/docs/policy-controller/overview/#configure-policy-controller-admission-controller-for-namespaces) instructions for more details.
 
 The `policy-controller` resyncs `ClusterImagePolicies` by default every 10 hours.
 Customize the resync period by using the `--policy-resync-period` argument and
 defining a duration for the `policy-webhook` deployment. See the [Golang time package's ParseDuration](https://pkg.go.dev/time#example-ParseDuration) for example duration string formats.
 
-See the [Configuring policy-controller ClusterImagePolicy](/policy-controller/overview/#configuring-policy-controller-clusterimagepolicy) instructions for more details on configuration.
+See the [Configuring policy-controller ClusterImagePolicy](/docs/policy-controller/overview/#configuring-policy-controller-clusterimagepolicy) instructions for more details on configuration.

content/en/docs/policy-controller/overview.md

@@ -11,7 +11,7 @@ The `policy-controller` admission controller can be used to enforce policy on a
 
 `policy-controller` also resolves the image tags to ensure the image being ran is not different from when it was admitted.
 
-See the [installation instructions](/policy-controller/installation/) for more information.
+See the [installation instructions](/docs/policy-controller/installation/) for more information.
 
 **This component is still actively under development!**
 
@@ -998,4 +998,4 @@ Authority that matches `tsa-organization` and `commonName`.
 and TrustRoot. We will fix this in a newer API version, but can't do it without
 reving the API version due to backwards compatibility. In CIP the ctLog refers
 to Rekor, which in TrustRoot was correctly named `tLog`. Whereas in TrustRoot
-the `ctLog` correctly refers to the `Certificate Transparency Log`.
+the `ctLog` correctly refers to the `Certificate Transparency Log`.