Fixed remaining 404 links

Added link to Slack invite

Changed link to external Slack community

Resolves #228

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

content/en/about/overview.md

@@ -46,7 +46,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](/about/contributing/).
 
 ## Learn more
 

content/en/about/security.md

@@ -6,7 +6,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](/about/tooling/).
 
 ## Proving Identity in Sigstore
 

content/en/about/support.md

@@ -12,7 +12,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://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
 

content/en/about/threat-model.md

@@ -9,7 +9,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](/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.
 

content/en/key_management/import-keypair.md

@@ -9,7 +9,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](/key_management/overview/), importing is not necessary and the key can be [specified by resource name](/key_management/overview/#signing-and-verification).
 
 The importing of a key pair with `cosign` is as follows.
 

content/en/logging/installation.md

@@ -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](/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)`
 
@@ -150,4 +150,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](/logging/cli/).