From f52d7bc4408d0458b7fd0d2054d87d029330ae02 Mon Sep 17 00:00:00 2001 From: jonvnadelberg <121979961+jonvnadelberg@users.noreply.github.com> Date: Tue, 22 Aug 2023 18:13:00 -0700 Subject: [PATCH 01/16] Update overview.md start of overview rewrite. Signed-off-by: jonvnadelberg <121979961+jonvnadelberg@users.noreply.github.com> --- content/en/docs/about/overview.md | 39 ++++++++++++++++++++++++++++++- 1 file changed, 38 insertions(+), 1 deletion(-) diff --git a/content/en/docs/about/overview.md b/content/en/docs/about/overview.md index 2206560b..7b61a688 100644 --- a/content/en/docs/about/overview.md +++ b/content/en/docs/about/overview.md @@ -9,7 +9,44 @@ weight: 1 ![Sigstore](sigstore-logo_horizontal-color.svg) -**Sigstore empowers software developers to securely sign software artifacts such as release files, container images, binaries, bill of material manifests and more. Signing materials are then stored in a tamper-resistant public log.** +**Sigstore empowers software developers and consumers to securely sign and verify software artifacts such as release files, container images, binaries, software bills of materials (SBOMs), and more. The signing materials are stored in a tamper-resistant public log so there’s no need to manage or store keys.** + +sigstore is a Linux Foundation project backed by Google, Red Hat, and Purdue University. It is 100% open source and free to use for all developers and software providers. The sigstore community develops and maintains the source code and tooling as a public good, non-profit service to improve the open source software supply chain. + +## Why cryptographic signing? + +Digital signatures are a way to verify the authenticity of a software artifact. Software consumers can trace software back to the source to know who created the artifact and that it has not been altered or tampered with after it was signed. + +In a landscape of growing software supply chain attacks, unsigned software is at risk for several attack vectors: + +- Typosquatting +- Package with similar name +- Compromised site where package is hosted +- Tampering after being published + + And so on. + +## Why sigstore? + +Traditional artifact signing relies on exchanging cryptographic keypairs for signature verification. The software creator keeps one key secret (the private “signing” key) and publishes the other (the public “verification” key). When a software consumer wants to verify an artifact’s signature, the veriication keys are exchanged to prove that the holder of the private key created the signature. + +This traditional approach has several weaknesses: + +- Identity. How do you know the person signing the artifact is who they say they are? +- Key management. How do you keep the private key secure so it can’t be lost or stolen? How do you make the public key easily accessible for users, but also protect it from tampering by a malicious attacker? +- Key revocation. If the keypair is compromised, how do you distribute new keys in a way that convinces users of your legitimacy and that you’re not an attacker? + +Sigstore addresses these problems by helping users move away from a key-based signing approach to an identity-based one. When using sigstore’s full capabilities, your artifact is: + +- Signed. With easy-to-use tooling (called Cosign) +- Verified. By checking your identity with our certificate authority (called Fulcio) +- Witnessed. By recording the signing information in a permanent transparency log (called Rekor) + +The signer can even forgo using long-lived keypairs. With “keyless” or “ephemeral key” signing, users verify the artifact using the transparency log for signature verification rather than keys. Sigstore improves on traditional methods of signing to be more convenient and secure: + +- Convenience. Users can take advantage of convenient tooling, easy container signing, and can even bypass the difficult problem of key management and rotation. +- Security. With sigstore, the artifact is not just signed; it’s signed, verified, and witnessed. + It’s free to use for all developers and software providers, with Sigstore’s code and operational tooling being 100% open source, and everything maintained and developed by the Sigstore community. From 44026b3e54d095bda06502c12e531b004bd369b3 Mon Sep 17 00:00:00 2001 From: jonvnadelberg <121979961+jonvnadelberg@users.noreply.github.com> Date: Tue, 22 Aug 2023 18:33:47 -0700 Subject: [PATCH 02/16] Update overview.md Signed-off-by: jonvnadelberg <121979961+jonvnadelberg@users.noreply.github.com> --- content/en/docs/about/overview.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/en/docs/about/overview.md b/content/en/docs/about/overview.md index 7b61a688..956bf124 100644 --- a/content/en/docs/about/overview.md +++ b/content/en/docs/about/overview.md @@ -52,6 +52,7 @@ It’s free to use for all developers and software providers, with Sigstore’s ## How to use Sigstore +To use Sigstore, you must first install the product. See the [Installation](docs/system_config/installation/) * 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/) From 4e0343fc4f4a17e1ac89e83f8adc2addd9a603b2 Mon Sep 17 00:00:00 2001 From: jonvnadelberg <121979961+jonvnadelberg@users.noreply.github.com> Date: Tue, 22 Aug 2023 18:46:22 -0700 Subject: [PATCH 03/16] Update overview.md Signed-off-by: jonvnadelberg <121979961+jonvnadelberg@users.noreply.github.com> --- content/en/docs/about/overview.md | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/content/en/docs/about/overview.md b/content/en/docs/about/overview.md index 956bf124..b790d7e7 100644 --- a/content/en/docs/about/overview.md +++ b/content/en/docs/about/overview.md @@ -50,15 +50,6 @@ The signer can even forgo using long-lived keypairs. With “keyless” or “ep It’s free to use for all developers and software providers, with Sigstore’s code and operational tooling being 100% open source, and everything maintained and developed by the Sigstore community. -## How to use Sigstore - -To use Sigstore, you must first install the product. See the [Installation](docs/system_config/installation/) -* 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. @@ -69,12 +60,24 @@ After the client signs the artifact, the artifact's digest, signature and certif 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. +For more information on the modules that make up Sigstore, see [Toolling](/docs/about/tooling/) + ## Software supply chain security Software supply chains are exposed to multiple risks. Users are susceptible to various targeted attacks, along with account and cryptographic key compromise. Keys in particular are a challenge for software maintainers to manage. Projects often have to maintain a list of current keys in use, and manage the keys of individuals who no longer contribute to a project. Projects all too often store public keys and digests on git repo readme files or websites, two forms of storage susceptible to tampering and less than ideal means of securely communicating trust. The tool sets we’ve historically relied on were not built for the present circumstance of remote teams either. This can be seen by the need to create a web of trust, with teams having to meet in person and sign each others’ keys. The current tooling (outside of controlled environments) all too often feel inappropriate to even technical users. +## How to use Sigstore + +To use Sigstore, you must first install the product. See the [Installation](docs/system_config/installation/) instructions. You can then pick the subject matter you wish to learn about from the menu items on the left. For a quick introduction, you can try using one of the links below: + +* To get a quick view of how to use the program see [Quick Start](/docs/signing/quickstart/) +* To learn how to work with blobs, see [sign a blob](docs/signing/signing_with_blobs/) +* I learn how to work with containers, see [sign a container](docs/signing/signing_with_containers/) +* To use Gitsign, see [Sign Git commits with Gitsign](/docs/signing/gitsign/) +* To learn about verification, see [verify entries with Cosign](/docs/verifying/verify/) + ## About the project Sigstore is a Linux Foundation project backed by Google, Red Hat and Purdue University. We provide a public good, non-profit service to improve the open source software supply chain by easing the adoption of cryptographic software signing. From 2274b0007564f64a1c5cfbffdbe481219f53d171 Mon Sep 17 00:00:00 2001 From: jonvnadelberg <121979961+jonvnadelberg@users.noreply.github.com> Date: Tue, 22 Aug 2023 18:47:50 -0700 Subject: [PATCH 04/16] Update overview.md Signed-off-by: jonvnadelberg <121979961+jonvnadelberg@users.noreply.github.com> --- content/en/docs/about/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/about/overview.md b/content/en/docs/about/overview.md index b790d7e7..f540623e 100644 --- a/content/en/docs/about/overview.md +++ b/content/en/docs/about/overview.md @@ -74,7 +74,7 @@ To use Sigstore, you must first install the product. See the [Installation](docs * To get a quick view of how to use the program see [Quick Start](/docs/signing/quickstart/) * To learn how to work with blobs, see [sign a blob](docs/signing/signing_with_blobs/) -* I learn how to work with containers, see [sign a container](docs/signing/signing_with_containers/) +* To learn how to work with containers, see [sign a container](docs/signing/signing_with_containers/) * To use Gitsign, see [Sign Git commits with Gitsign](/docs/signing/gitsign/) * To learn about verification, see [verify entries with Cosign](/docs/verifying/verify/) From 0c1199cacd034481300a932a9353cf93308a2886 Mon Sep 17 00:00:00 2001 From: jonvnadelberg <121979961+jonvnadelberg@users.noreply.github.com> Date: Tue, 22 Aug 2023 18:49:07 -0700 Subject: [PATCH 05/16] Update overview.md Signed-off-by: jonvnadelberg <121979961+jonvnadelberg@users.noreply.github.com> --- content/en/docs/about/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/about/overview.md b/content/en/docs/about/overview.md index f540623e..0c3e519b 100644 --- a/content/en/docs/about/overview.md +++ b/content/en/docs/about/overview.md @@ -48,7 +48,7 @@ The signer can even forgo using long-lived keypairs. With “keyless” or “ep - Security. With sigstore, the artifact is not just signed; it’s signed, verified, and witnessed. -It’s free to use for all developers and software providers, with Sigstore’s code and operational tooling being 100% open source, and everything maintained and developed by the Sigstore community. +Sigstore is free to use for all developers and software providers, with Sigstore’s code and operational tooling being 100% open source, with everything maintained and developed by the Sigstore community. ## How Sigstore works From c10e83e105e1de05a086e6c9eaf2356da161626b Mon Sep 17 00:00:00 2001 From: jonvnadelberg <121979961+jonvnadelberg@users.noreply.github.com> Date: Wed, 23 Aug 2023 12:04:06 -0700 Subject: [PATCH 06/16] Update overview.md Signed-off-by: jonvnadelberg <121979961+jonvnadelberg@users.noreply.github.com> --- content/en/docs/about/overview.md | 25 ++++++++----------------- 1 file changed, 8 insertions(+), 17 deletions(-) diff --git a/content/en/docs/about/overview.md b/content/en/docs/about/overview.md index 0c3e519b..7da5afb6 100644 --- a/content/en/docs/about/overview.md +++ b/content/en/docs/about/overview.md @@ -11,7 +11,7 @@ weight: 1 **Sigstore empowers software developers and consumers to securely sign and verify software artifacts such as release files, container images, binaries, software bills of materials (SBOMs), and more. The signing materials are stored in a tamper-resistant public log so there’s no need to manage or store keys.** -sigstore is a Linux Foundation project backed by Google, Red Hat, and Purdue University. It is 100% open source and free to use for all developers and software providers. The sigstore community develops and maintains the source code and tooling as a public good, non-profit service to improve the open source software supply chain. +Sigstore is a Linux Foundation project backed by Google, Red Hat, and Purdue University. It is 100% open source and free to use for all developers and software providers. The sigstore community develops and maintains the source code and tooling as a public good, non-profit service to improve the open source software supply chain. ## Why cryptographic signing? @@ -47,26 +47,17 @@ The signer can even forgo using long-lived keypairs. With “keyless” or “ep - Convenience. Users can take advantage of convenient tooling, easy container signing, and can even bypass the difficult problem of key management and rotation. - Security. With sigstore, the artifact is not just signed; it’s signed, verified, and witnessed. +## How sigstore works -Sigstore is free to use for all developers and software providers, with Sigstore’s code and operational tooling being 100% open source, with everything maintained and developed by the Sigstore community. +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. -## 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. - -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. +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. -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. - -For more information on the modules that make up Sigstore, see [Toolling](/docs/about/tooling/) - -## Software supply chain security - -Software supply chains are exposed to multiple risks. Users are susceptible to various targeted attacks, along with account and cryptographic key compromise. Keys in particular are a challenge for software maintainers to manage. Projects often have to maintain a list of current keys in use, and manage the keys of individuals who no longer contribute to a project. Projects all too often store public keys and digests on git repo readme files or websites, two forms of storage susceptible to tampering and less than ideal means of securely communicating trust. +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. -The tool sets we’ve historically relied on were not built for the present circumstance of remote teams either. This can be seen by the need to create a web of trust, with teams having to meet in person and sign each others’ keys. The current tooling (outside of controlled environments) all too often feel inappropriate to even technical users. +For more information on the modules that make up Sigstore, see [Toolling](/docs/about/tooling/ ## How to use Sigstore @@ -84,9 +75,9 @@ Sigstore is a Linux Foundation project backed by Google, Red Hat and Purdue Univ ## Contributing -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. +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/contributing/). ## Learn more From 7f812b64e0b6d0f44c08824ce5895d4ca7ec282d Mon Sep 17 00:00:00 2001 From: jonvnadelberg <121979961+jonvnadelberg@users.noreply.github.com> Date: Wed, 23 Aug 2023 12:25:01 -0700 Subject: [PATCH 07/16] Update overview.md Signed-off-by: jonvnadelberg <121979961+jonvnadelberg@users.noreply.github.com> --- content/en/docs/about/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/about/overview.md b/content/en/docs/about/overview.md index 7da5afb6..8a16da58 100644 --- a/content/en/docs/about/overview.md +++ b/content/en/docs/about/overview.md @@ -17,7 +17,7 @@ Sigstore is a Linux Foundation project backed by Google, Red Hat, and Purdue Uni Digital signatures are a way to verify the authenticity of a software artifact. Software consumers can trace software back to the source to know who created the artifact and that it has not been altered or tampered with after it was signed. -In a landscape of growing software supply chain attacks, unsigned software is at risk for several attack vectors: +In a landscape of growing software supply chain attacks, unsigned software is at risk for several attack vectors:v - Typosquatting - Package with similar name From 6d0c77aa5c725a28ae8a0b0c5c8f6df17b8acfa1 Mon Sep 17 00:00:00 2001 From: jonvnadelberg <121979961+jonvnadelberg@users.noreply.github.com> Date: Wed, 23 Aug 2023 12:38:42 -0700 Subject: [PATCH 08/16] Update overview.md typos and removed redundant text. Signed-off-by: jonvnadelberg <121979961+jonvnadelberg@users.noreply.github.com> --- content/en/docs/about/overview.md | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/content/en/docs/about/overview.md b/content/en/docs/about/overview.md index 8a16da58..378fceb4 100644 --- a/content/en/docs/about/overview.md +++ b/content/en/docs/about/overview.md @@ -17,10 +17,10 @@ Sigstore is a Linux Foundation project backed by Google, Red Hat, and Purdue Uni Digital signatures are a way to verify the authenticity of a software artifact. Software consumers can trace software back to the source to know who created the artifact and that it has not been altered or tampered with after it was signed. -In a landscape of growing software supply chain attacks, unsigned software is at risk for several attack vectors:v +In a landscape of growing software supply chain attacks, unsigned software is at risk for several attack vectors: - Typosquatting -- Package with similar name +- Packages with similar names - Compromised site where package is hosted - Tampering after being published @@ -57,11 +57,11 @@ After the client signs the artifact, the artifact's digest, signature and certif 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. -For more information on the modules that make up Sigstore, see [Toolling](/docs/about/tooling/ +For more information on the modules that make up Sigstore, see [Toolling](/docs/about/tooling/) ## How to use Sigstore -To use Sigstore, you must first install the product. See the [Installation](docs/system_config/installation/) instructions. You can then pick the subject matter you wish to learn about from the menu items on the left. For a quick introduction, you can try using one of the links below: +To use sigstore, you must first install the product. See the [Installation](docs/system_config/installation/) instructions. You can then pick the subject matter you wish to learn about from the menu items on the left. For a quick introduction, you can try using one of the links below: * To get a quick view of how to use the program see [Quick Start](/docs/signing/quickstart/) * To learn how to work with blobs, see [sign a blob](docs/signing/signing_with_blobs/) @@ -69,13 +69,9 @@ To use Sigstore, you must first install the product. See the [Installation](docs * To use Gitsign, see [Sign Git commits with Gitsign](/docs/signing/gitsign/) * To learn about verification, see [verify entries with Cosign](/docs/verifying/verify/) -## About the project - -Sigstore is a Linux Foundation project backed by Google, Red Hat and Purdue University. We provide a public good, non-profit service to improve the open source software supply chain by easing the adoption of cryptographic software signing. - ## Contributing -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. +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](/docs/contributing/). From 15b72f3266665aafec7e2aacf49d5b9ef8d634c7 Mon Sep 17 00:00:00 2001 From: jonvnadelberg <121979961+jonvnadelberg@users.noreply.github.com> Date: Thu, 24 Aug 2023 10:44:22 -0700 Subject: [PATCH 09/16] Update content/en/docs/about/overview.md Co-authored-by: olivekl <83081275+olivekl@users.noreply.github.com> Signed-off-by: jonvnadelberg <121979961+jonvnadelberg@users.noreply.github.com> --- content/en/docs/about/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/about/overview.md b/content/en/docs/about/overview.md index 378fceb4..a97d3b5f 100644 --- a/content/en/docs/about/overview.md +++ b/content/en/docs/about/overview.md @@ -49,7 +49,7 @@ The signer can even forgo using long-lived keypairs. With “keyless” or “ep ## 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 our a code-signing certificate authority (called Fulcio). A verifiable OpenID Connect identity token, which contains a user's email address or service account, is provided in the request. The certificate authority 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. From c2ef4b8d18f7c70bb58bfe2e6a4c5fd513960e33 Mon Sep 17 00:00:00 2001 From: jonvnadelberg <121979961+jonvnadelberg@users.noreply.github.com> Date: Thu, 24 Aug 2023 10:45:13 -0700 Subject: [PATCH 10/16] Update content/en/docs/about/overview.md Co-authored-by: olivekl <83081275+olivekl@users.noreply.github.com> Signed-off-by: jonvnadelberg <121979961+jonvnadelberg@users.noreply.github.com> --- content/en/docs/about/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/about/overview.md b/content/en/docs/about/overview.md index a97d3b5f..063b928b 100644 --- a/content/en/docs/about/overview.md +++ b/content/en/docs/about/overview.md @@ -53,7 +53,7 @@ A sigstore client, such as Cosign, requests a certificate from our a code-signin 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 a transparency log: an immutable, append-only ledger known as Rekor. With this log, signing events can be publicly audited. Identity owners can monitor the log to verify that their identity is being properly used, and someone who downloads and artifact can confirm that the certificate was valid at the time of signing. 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. From 5c8d118727f41f27e208c9288a94696741e3c197 Mon Sep 17 00:00:00 2001 From: jonvnadelberg <121979961+jonvnadelberg@users.noreply.github.com> Date: Thu, 24 Aug 2023 10:57:08 -0700 Subject: [PATCH 11/16] Update overview.md Signed-off-by: jonvnadelberg <121979961+jonvnadelberg@users.noreply.github.com> --- content/en/docs/about/overview.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/content/en/docs/about/overview.md b/content/en/docs/about/overview.md index 063b928b..b34651f1 100644 --- a/content/en/docs/about/overview.md +++ b/content/en/docs/about/overview.md @@ -1,6 +1,6 @@ --- -category: About sigstore -description: Documentation for sigstore +category: About Sigstore +description: Documentation for Sigstore home: true menuTitle: Overview title: Sigstore @@ -11,7 +11,7 @@ weight: 1 **Sigstore empowers software developers and consumers to securely sign and verify software artifacts such as release files, container images, binaries, software bills of materials (SBOMs), and more. The signing materials are stored in a tamper-resistant public log so there’s no need to manage or store keys.** -Sigstore is a Linux Foundation project backed by Google, Red Hat, and Purdue University. It is 100% open source and free to use for all developers and software providers. The sigstore community develops and maintains the source code and tooling as a public good, non-profit service to improve the open source software supply chain. +Sigstore is a project backed by the Open Source Security Foundation (OpenSSF) under the Linux Foundation, with contributions from Google, Red Hat, Chainguard, GitHub and Purdue University. It is 100% open source and free to use for all developers and software providers. The Sigstore community develops and maintains the source code and tooling as a public good, non-profit service to improve the open source software supply chain. ## Why cryptographic signing? @@ -26,7 +26,7 @@ In a landscape of growing software supply chain attacks, unsigned software is at And so on. -## Why sigstore? +## Why Sigstore? Traditional artifact signing relies on exchanging cryptographic keypairs for signature verification. The software creator keeps one key secret (the private “signing” key) and publishes the other (the public “verification” key). When a software consumer wants to verify an artifact’s signature, the veriication keys are exchanged to prove that the holder of the private key created the signature. @@ -36,7 +36,7 @@ This traditional approach has several weaknesses: - Key management. How do you keep the private key secure so it can’t be lost or stolen? How do you make the public key easily accessible for users, but also protect it from tampering by a malicious attacker? - Key revocation. If the keypair is compromised, how do you distribute new keys in a way that convinces users of your legitimacy and that you’re not an attacker? -Sigstore addresses these problems by helping users move away from a key-based signing approach to an identity-based one. When using sigstore’s full capabilities, your artifact is: +Sigstore addresses these problems by helping users move away from a key-based signing approach to an identity-based one. When using Sigstore’s full capabilities, your artifact is: - Signed. With easy-to-use tooling (called Cosign) - Verified. By checking your identity with our certificate authority (called Fulcio) @@ -45,23 +45,23 @@ Sigstore addresses these problems by helping users move away from a key-based si The signer can even forgo using long-lived keypairs. With “keyless” or “ephemeral key” signing, users verify the artifact using the transparency log for signature verification rather than keys. Sigstore improves on traditional methods of signing to be more convenient and secure: - Convenience. Users can take advantage of convenient tooling, easy container signing, and can even bypass the difficult problem of key management and rotation. -- Security. With sigstore, the artifact is not just signed; it’s signed, verified, and witnessed. +- Security. With Sigstore, the artifact is not just signed; it’s signed, verified, and witnessed. -## How sigstore works +## How Sigstore works -A sigstore client, such as Cosign, requests a certificate from our a code-signing certificate authority (called Fulcio). A verifiable OpenID Connect identity token, which contains a user's email address or service account, is provided in the request. The certificate authority verifies this token and issues a short-lived certificate bound to the provided identity. +A Sigstore client, such as Cosign, requests a certificate from our a code-signing certificate authority (called Fulcio). A verifiable OpenID Connect identity token, which contains a user's email address or service account, is provided in the request. The certificate authority 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. +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 a transparency log: an immutable, append-only ledger known as Rekor. With this log, signing events can be publicly audited. Identity owners can monitor the log to verify that their identity is being properly used, and someone who downloads and artifact can confirm that the certificate was valid at the time of signing. -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. +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. For more information on the modules that make up Sigstore, see [Toolling](/docs/about/tooling/) ## How to use Sigstore -To use sigstore, you must first install the product. See the [Installation](docs/system_config/installation/) instructions. You can then pick the subject matter you wish to learn about from the menu items on the left. For a quick introduction, you can try using one of the links below: +To use Sigstore, you must first install the product. See the [Installation](docs/system_config/installation/) instructions. You can then pick the subject matter you wish to learn about from the menu items on the left. For a quick introduction, you can try using one of the links below: * To get a quick view of how to use the program see [Quick Start](/docs/signing/quickstart/) * To learn how to work with blobs, see [sign a blob](docs/signing/signing_with_blobs/) @@ -71,7 +71,7 @@ To use sigstore, you must first install the product. See the [Installation](docs ## Contributing -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. +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](/docs/contributing/). From 5237f0ba03ba480a8b8167de690015d7141b1d2b Mon Sep 17 00:00:00 2001 From: jonvnadelberg <121979961+jonvnadelberg@users.noreply.github.com> Date: Thu, 24 Aug 2023 11:00:45 -0700 Subject: [PATCH 12/16] Update overview.md Signed-off-by: jonvnadelberg <121979961+jonvnadelberg@users.noreply.github.com> --- content/en/docs/about/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/about/overview.md b/content/en/docs/about/overview.md index b34651f1..c28c046d 100644 --- a/content/en/docs/about/overview.md +++ b/content/en/docs/about/overview.md @@ -9,7 +9,7 @@ weight: 1 ![Sigstore](sigstore-logo_horizontal-color.svg) -**Sigstore empowers software developers and consumers to securely sign and verify software artifacts such as release files, container images, binaries, software bills of materials (SBOMs), and more. The signing materials are stored in a tamper-resistant public log so there’s no need to manage or store keys.** +**Sigstore empowers software developers and consumers to securely sign and verify software artifacts such as release files, container images, binaries, software bills of materials (SBOMs), and more. The signing Signatures are generated with ephemeral signing keys so there's no need to manage keys. Signing events are recorded in a tamper-resistant public log so software developers can audit signing events.** Sigstore is a project backed by the Open Source Security Foundation (OpenSSF) under the Linux Foundation, with contributions from Google, Red Hat, Chainguard, GitHub and Purdue University. It is 100% open source and free to use for all developers and software providers. The Sigstore community develops and maintains the source code and tooling as a public good, non-profit service to improve the open source software supply chain. From 18759213dbe8373e27edada81d09f1651daad5c3 Mon Sep 17 00:00:00 2001 From: jonvnadelberg <121979961+jonvnadelberg@users.noreply.github.com> Date: Thu, 24 Aug 2023 11:16:53 -0700 Subject: [PATCH 13/16] Update overview.md Signed-off-by: jonvnadelberg <121979961+jonvnadelberg@users.noreply.github.com> --- content/en/docs/about/overview.md | 34 +++++++++++++++---------------- 1 file changed, 16 insertions(+), 18 deletions(-) diff --git a/content/en/docs/about/overview.md b/content/en/docs/about/overview.md index c28c046d..49a224e1 100644 --- a/content/en/docs/about/overview.md +++ b/content/en/docs/about/overview.md @@ -15,16 +15,14 @@ Sigstore is a project backed by the Open Source Security Foundation (OpenSSF) un ## Why cryptographic signing? -Digital signatures are a way to verify the authenticity of a software artifact. Software consumers can trace software back to the source to know who created the artifact and that it has not been altered or tampered with after it was signed. - -In a landscape of growing software supply chain attacks, unsigned software is at risk for several attack vectors: - -- Typosquatting -- Packages with similar names -- Compromised site where package is hosted -- Tampering after being published +In a landscape of growing software supply chain attacks, unsigned software is at risk for several attack vectors, such as: - And so on. +- **Typosquatting** +- **Packages with similar names** +- **Compromised site where package is hosted** +- **Tampering after being published** + +Digital signatures are a way to verify the authenticity of a software artifact. Software consumers can trace software back to the source to know who created the artifact and that it has not been altered or tampered with after it was signed. ## Why Sigstore? @@ -32,20 +30,20 @@ Traditional artifact signing relies on exchanging cryptographic keypairs for sig This traditional approach has several weaknesses: -- Identity. How do you know the person signing the artifact is who they say they are? -- Key management. How do you keep the private key secure so it can’t be lost or stolen? How do you make the public key easily accessible for users, but also protect it from tampering by a malicious attacker? -- Key revocation. If the keypair is compromised, how do you distribute new keys in a way that convinces users of your legitimacy and that you’re not an attacker? +- **Identity**: How do you know the person signing the artifact is who they say they are? +- **Key management**: How do you keep the private key secure so it can’t be lost or stolen? How do you make the public key easily accessible for users, but also protect it from tampering by a malicious attacker? +- **Key revocation**: If the keypair is compromised, how do you distribute new keys in a way that convinces users of your legitimacy and that you’re not an attacker? Sigstore addresses these problems by helping users move away from a key-based signing approach to an identity-based one. When using Sigstore’s full capabilities, your artifact is: -- Signed. With easy-to-use tooling (called Cosign) -- Verified. By checking your identity with our certificate authority (called Fulcio) -- Witnessed. By recording the signing information in a permanent transparency log (called Rekor) +- **Signed**: By using a Sigstore client (Cosign). +- **Verified**: By checking your identity with our certificate authority (Fulcio). +- **Witnessed**: By recording the signing information in a permanent transparency log (Rekor). The signer can even forgo using long-lived keypairs. With “keyless” or “ephemeral key” signing, users verify the artifact using the transparency log for signature verification rather than keys. Sigstore improves on traditional methods of signing to be more convenient and secure: -- Convenience. Users can take advantage of convenient tooling, easy container signing, and can even bypass the difficult problem of key management and rotation. -- Security. With Sigstore, the artifact is not just signed; it’s signed, verified, and witnessed. +- **Convenience**: Users can take advantage of convenient tooling, easy container signing, and can even bypass the difficult problem of key management and rotation. +- **Security**: With Sigstore, the artifact is not just signed; it’s signed, verified, and witnessed. ## How Sigstore works @@ -61,7 +59,7 @@ For more information on the modules that make up Sigstore, see [Toolling](/docs/ ## How to use Sigstore -To use Sigstore, you must first install the product. See the [Installation](docs/system_config/installation/) instructions. You can then pick the subject matter you wish to learn about from the menu items on the left. For a quick introduction, you can try using one of the links below: +To use Sigstore, you must first install the client. See the [Installation](docs/system_config/installation/) instructions. You can then pick the subject matter you wish to learn about from the menu items on the left. For a quick introduction, you can try using one of the links below: * To get a quick view of how to use the program see [Quick Start](/docs/signing/quickstart/) * To learn how to work with blobs, see [sign a blob](docs/signing/signing_with_blobs/) From b1deac76491d616d5ccccea1a3232eecb1dc3db7 Mon Sep 17 00:00:00 2001 From: jonvnadelberg <121979961+jonvnadelberg@users.noreply.github.com> Date: Thu, 24 Aug 2023 11:26:24 -0700 Subject: [PATCH 14/16] Update overview.md Signed-off-by: jonvnadelberg <121979961+jonvnadelberg@users.noreply.github.com> --- content/en/docs/about/overview.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/en/docs/about/overview.md b/content/en/docs/about/overview.md index 49a224e1..68f1b583 100644 --- a/content/en/docs/about/overview.md +++ b/content/en/docs/about/overview.md @@ -9,13 +9,13 @@ weight: 1 ![Sigstore](sigstore-logo_horizontal-color.svg) -**Sigstore empowers software developers and consumers to securely sign and verify software artifacts such as release files, container images, binaries, software bills of materials (SBOMs), and more. The signing Signatures are generated with ephemeral signing keys so there's no need to manage keys. Signing events are recorded in a tamper-resistant public log so software developers can audit signing events.** +**Sigstore is an open source project for improving software supply chain security. The Sigstore framework and tooling empowers software developers and consumers to securely sign and verify software artifacts such as release files, container images, binaries, software bills of materials (SBOMs), and more. The signing materials are stored in a tamper-resistant public log so there’s no need to manage or store keys.** -Sigstore is a project backed by the Open Source Security Foundation (OpenSSF) under the Linux Foundation, with contributions from Google, Red Hat, Chainguard, GitHub and Purdue University. It is 100% open source and free to use for all developers and software providers. The Sigstore community develops and maintains the source code and tooling as a public good, non-profit service to improve the open source software supply chain. +The project is backed by the Open Source Security Foundation (OpenSSF) under the Linux Foundation, with contributions from Google, Red Hat, Chainguard, GitHub and Purdue University. It is 100% open source and free to use for all developers and software providers. The Sigstore community develops and maintains the source code and tooling as a public good, non-profit service to improve the open source software supply chain. ## Why cryptographic signing? -In a landscape of growing software supply chain attacks, unsigned software is at risk for several attack vectors, such as: +In a landscape of growing software supply chain vulnerability, unsigned software is at risk for several attack vectors, such as: - **Typosquatting** - **Packages with similar names** @@ -26,7 +26,7 @@ Digital signatures are a way to verify the authenticity of a software artifact. ## Why Sigstore? -Traditional artifact signing relies on exchanging cryptographic keypairs for signature verification. The software creator keeps one key secret (the private “signing” key) and publishes the other (the public “verification” key). When a software consumer wants to verify an artifact’s signature, the veriication keys are exchanged to prove that the holder of the private key created the signature. +Traditional artifact signing relies on exchanging cryptographic keypairs for signature verification. The software creator keeps one key secret (the private “signing” key) and publishes the other (the public “verification” key). When a software consumer wants to verify an artifact’s signature, the verification keys are exchanged to prove that the holder of the private key created the signature. This traditional approach has several weaknesses: @@ -53,7 +53,7 @@ You don’t have to manage signing keys, and Sigstore services never obtain your After the client signs the artifact, the artifact's digest, signature and certificate are persisted in a transparency log: an immutable, append-only ledger known as Rekor. With this log, signing events can be publicly audited. Identity owners can monitor the log to verify that their identity is being properly used, and someone who downloads and artifact can confirm that the certificate was valid at the time of signing. -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. +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. Together, verification of this information tells the user that the artifact comes from its expected source and has not been tampered with after its creation. For more information on the modules that make up Sigstore, see [Toolling](/docs/about/tooling/) @@ -69,7 +69,7 @@ To use Sigstore, you must first install the client. See the [Installation](docs/ ## Contributing -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. +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 signing ceremonies to security practices. Ready to jump in? Check the [contributing guidelines](/docs/contributing/). From b9741db7d11d3562ab5a06383a0dce4eeb76d7d1 Mon Sep 17 00:00:00 2001 From: Jon Nadelberg Date: Thu, 24 Aug 2023 19:44:45 +0000 Subject: [PATCH 15/16] resolve conflicts --- content/en/docs/about/overview.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/content/en/docs/about/overview.md b/content/en/docs/about/overview.md index 68f1b583..ade3f75d 100644 --- a/content/en/docs/about/overview.md +++ b/content/en/docs/about/overview.md @@ -11,7 +11,7 @@ weight: 1 **Sigstore is an open source project for improving software supply chain security. The Sigstore framework and tooling empowers software developers and consumers to securely sign and verify software artifacts such as release files, container images, binaries, software bills of materials (SBOMs), and more. The signing materials are stored in a tamper-resistant public log so there’s no need to manage or store keys.** -The project is backed by the Open Source Security Foundation (OpenSSF) under the Linux Foundation, with contributions from Google, Red Hat, Chainguard, GitHub and Purdue University. It is 100% open source and free to use for all developers and software providers. The Sigstore community develops and maintains the source code and tooling as a public good, non-profit service to improve the open source software supply chain. +The project is backed by the Open Source Security Foundation (OpenSSF) under the Linux Foundation, with contributions from Google, Red Hat, Chainguard, GitHub and Purdue University. It is 100% open source and free to use for all developers and software providers. The Sigstore community develops and maintains the source code and tooling as a public good, non-profit service to improve the open source software supply chain. ## Why cryptographic signing? @@ -21,18 +21,18 @@ In a landscape of growing software supply chain vulnerability, unsigned software - **Packages with similar names** - **Compromised site where package is hosted** - **Tampering after being published** - -Digital signatures are a way to verify the authenticity of a software artifact. Software consumers can trace software back to the source to know who created the artifact and that it has not been altered or tampered with after it was signed. - + +Digital signatures are a way to verify the authenticity of a software artifact. Software consumers can trace software back to the source to know who created the artifact and that it has not been altered or tampered with after it was signed. + ## Why Sigstore? -Traditional artifact signing relies on exchanging cryptographic keypairs for signature verification. The software creator keeps one key secret (the private “signing” key) and publishes the other (the public “verification” key). When a software consumer wants to verify an artifact’s signature, the verification keys are exchanged to prove that the holder of the private key created the signature. +Traditional artifact signing relies on exchanging cryptographic keypairs for signature verification. The software creator keeps one key secret (the private “signing” key) and publishes the other (the public “verification” key). When a software consumer wants to verify an artifact’s signature, the verification keys are exchanged to prove that the holder of the private key created the signature. -This traditional approach has several weaknesses: +This traditional approach has several weaknesses: - **Identity**: How do you know the person signing the artifact is who they say they are? - **Key management**: How do you keep the private key secure so it can’t be lost or stolen? How do you make the public key easily accessible for users, but also protect it from tampering by a malicious attacker? -- **Key revocation**: If the keypair is compromised, how do you distribute new keys in a way that convinces users of your legitimacy and that you’re not an attacker? +- **Key revocation**: If the keypair is compromised, how do you distribute new keys in a way that convinces users of your legitimacy and that you’re not an attacker? Sigstore addresses these problems by helping users move away from a key-based signing approach to an identity-based one. When using Sigstore’s full capabilities, your artifact is: @@ -42,12 +42,12 @@ Sigstore addresses these problems by helping users move away from a key-based si The signer can even forgo using long-lived keypairs. With “keyless” or “ephemeral key” signing, users verify the artifact using the transparency log for signature verification rather than keys. Sigstore improves on traditional methods of signing to be more convenient and secure: -- **Convenience**: Users can take advantage of convenient tooling, easy container signing, and can even bypass the difficult problem of key management and rotation. -- **Security**: With Sigstore, the artifact is not just signed; it’s signed, verified, and witnessed. +- **Convenience**: Users can take advantage of convenient tooling, easy container signing, and can even bypass the difficult problem of key management and rotation. +- **Security**: With Sigstore, the artifact is not just signed; it’s signed, verified, and witnessed. ## How Sigstore works -A Sigstore client, such as Cosign, requests a certificate from our a code-signing certificate authority (called Fulcio). A verifiable OpenID Connect identity token, which contains a user's email address or service account, is provided in the request. The certificate authority verifies this token and issues a short-lived certificate bound to the provided identity. +A Sigstore client, such as Cosign, requests a certificate from our a code-signing certificate authority (called Fulcio). A verifiable OpenID Connect identity token, which contains a user's email address or service account, is provided in the request. The certificate authority 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. @@ -76,4 +76,4 @@ Ready to jump in? Check the [contributing guidelines](/docs/contributing/). ## Learn more - [Sigstore YouTube Channel](https://www.youtube.com/@projectsigstore) -- [Sigstore Blog](https://blog.sigstore.dev/) +- [Sigstore Blog](https://blog.sigstore.dev/) From f34b2b10c4bd6577269d7ffa4993553cf5039048 Mon Sep 17 00:00:00 2001 From: jonvnadelberg <121979961+jonvnadelberg@users.noreply.github.com> Date: Thu, 24 Aug 2023 14:11:45 -0700 Subject: [PATCH 16/16] Update overview.md finish requests Signed-off-by: jonvnadelberg <121979961+jonvnadelberg@users.noreply.github.com> --- content/en/about/overview.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/en/about/overview.md b/content/en/about/overview.md index ef97bbb2..e0be4102 100644 --- a/content/en/about/overview.md +++ b/content/en/about/overview.md @@ -10,9 +10,9 @@ weight: 1 ![Sigstore](sigstore-logo_horizontal-color.svg) -**Sigstore is an open source project for improving software supply chain security. The Sigstore framework and tooling empowers software developers and consumers to securely sign and verify software artifacts such as release files, container images, binaries, software bills of materials (SBOMs), and more. The signing materials are stored in a tamper-resistant public log so there’s no need to manage or store keys.** +**Sigstore is an open source project for improving software supply chain security. The Sigstore framework and tooling empowers software developers and consumers to securely sign and verify software artifacts such as release files, container images, binaries, software bills of materials (SBOMs), and more. Signatures are generated with ephemeral signing keys so there's no need to manage keys. Signing events are recorded in a tamper-resistant public log so software developers can audit signing events.** -The project is backed by the Open Source Security Foundation (OpenSSF) under the Linux Foundation, with contributions from Google, Red Hat, Chainguard, GitHub and Purdue University. It is 100% open source and free to use for all developers and software providers. The Sigstore community develops and maintains the source code and tooling as a public good, non-profit service to improve the open source software supply chain. +The project is backed by the Open Source Security Foundation (OpenSSF) under the Linux Foundation, with contributions from Google, Red Hat, Chainguard, GitHub and Purdue University. It is 100% open source and free to use for all developers and software providers. The Sigstore community develops and maintains tools to simplify code signing and verification, and also operates a public-good, non-profit service to improve the open source software supply chain. ## Why cryptographic signing? @@ -41,7 +41,7 @@ Sigstore addresses these problems by helping users move away from a key-based si - **Verified**: By checking your identity with our certificate authority (Fulcio). - **Witnessed**: By recording the signing information in a permanent transparency log (Rekor). -The signer can even forgo using long-lived keypairs. With “keyless” or “ephemeral key” signing, users verify the artifact using the transparency log for signature verification rather than keys. Sigstore improves on traditional methods of signing to be more convenient and secure: +The signer ideally forgoes using long-lived keypairs. With “keyless” or “ephemeral key” signing, users verify the artifact using the transparency log for signature verification rather than keys. Sigstore improves on traditional methods of signing to be more convenient and secure: - **Convenience**: Users can take advantage of convenient tooling, easy container signing, and can even bypass the difficult problem of key management and rotation. - **Security**: With Sigstore, the artifact is not just signed; it’s signed, verified, and witnessed.