From 3af54151ee1c90bd693d7b8ee4804d8150bdf776 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E8=AF=BA=E5=A2=A8?= Date: Mon, 21 Aug 2023 01:58:25 +0800 Subject: [PATCH 1/2] docs(specification): improve logging documentation following MD014 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Specification reference: https://github.com/DavidAnson/markdownlint/ Signed-off-by: 诺墨 --- content/en/docs/logging/CLI.md | 24 +++++------ content/en/docs/logging/installation.md | 43 ++++++++++--------- content/en/docs/logging/overview.md | 14 ++---- content/en/docs/logging/sign-upload.md | 30 +++++++------ content/en/docs/logging/verify-release.md | 38 ++++++++-------- content/en/docs/signing/pkcs11.md | 4 +- content/en/docs/system_config/installation.md | 2 +- 7 files changed, 76 insertions(+), 79 deletions(-) diff --git a/content/en/docs/logging/CLI.md b/content/en/docs/logging/CLI.md index 63003d36..23e255f3 100644 --- a/content/en/docs/logging/CLI.md +++ b/content/en/docs/logging/CLI.md @@ -18,13 +18,13 @@ Before using Rekor, you are required to sign your release. The following example You may use either armored or plain binary: -``` +```bash gpg --armor -u jdoe@example.com --output mysignature.asc --detach-sig myrelease.tar.gz ``` You will also need to export your public key -``` +```bash gpg --export --armor "jdoe@example.com" > mypublickey.key ``` @@ -32,7 +32,7 @@ gpg --export --armor "jdoe@example.com" > mypublickey.key The `upload` command sends your public key / signature and artifact URL to the rekor transparency log. -``` +```bash rekor-cli upload --rekor_server https://rekor.sigstore.dev --signature --public-key --artifact | ``` @@ -40,7 +40,7 @@ The Rekor command will first verify your public key and signature and download a If the validations above pass correctly, the entry will be made to Rekor and an entry URL will be returned: -``` +```bash Created entry at: https://rekor.sigstore.dev/api/v1/log/entries/b08416d417acdb0610d4a030d8f697f9d0a718024681a00fa0b9ba67072a38b5 ``` @@ -50,10 +50,9 @@ This URL contains the UUID entry / merkle tree hash (in the above case `b08416d4 The `verify` command allows you to send a public key / signature and artifact to the Rekor transparency log for verification of entry. -You would typically use this command as a means to verify an 'inclusion proof' -showing that your artifact is stored within the transparency log. +You would typically use this command as a means to verify an 'inclusion proof' showing that your artifact is stored within the transparency log. -``` +```bash rekor-cli verify --rekor_server --signature --public-key --artifact | ``` @@ -63,11 +62,11 @@ rekor-cli verify --rekor_server --signature --p An entry in the log can be retrieved by using the `get` command with either the log index or the artifact UUID: -``` +```bash rekor-cli get --rekor_server https://rekor.sigstore.dev --log-index ``` -``` +```bash rekor-cli get --rekor_server https://rekor.sigstore.dev --uuid ``` @@ -75,7 +74,7 @@ rekor-cli get --rekor_server https://rekor.sigstore.dev --uuid The `loginfo` command retrieves the public key of the transparency log (unless already declared within the client `~/.rekor/rekor.yaml`) and then uses this public key to verify the signature on the signed tree head. -``` +```bash rekor-cli loginfo --rekor_server https://rekor.sigstore.dev ``` @@ -85,11 +84,12 @@ If running a redis instance within Rekor, the `search` command performs a redis This command requires one of an artifact, a public key, or a SHA hash (should be prefixed by `sha256:`). -``` +```bash rekor-cli search --rekor_server https://rekor.sigstore.dev --[artifact|public-key|sha] ``` For example: -``` + +```bash rekor-cli search --rekor_server https://rekor.sigstore.dev --sha sha256:e2e90d1a25f90a3156a27f00f3a4179578e3132ed4f010dc3498d09175b6071a ``` \ No newline at end of file diff --git a/content/en/docs/logging/installation.md b/content/en/docs/logging/installation.md index 860eab55..3553e3eb 100644 --- a/content/en/docs/logging/installation.md +++ b/content/en/docs/logging/installation.md @@ -10,13 +10,13 @@ There are several ways to install both the `rekor-cli` and `rekor-server`. If you have Go installed, you can use go to retreive the `rekor-cli` binaries -``` +```bash go install -v github.com/sigstore/rekor/cmd/rekor-cli@latest ``` You may also do the same for `rekor-server`, but **please note** that the Rekor server also requires Trillian and a database. (see below for setup instructions). -``` +```bash go install -v github.com/sigstore/rekor/cmd/rekor-server@latest ``` @@ -28,10 +28,9 @@ 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. - ## Build Rekor CLI manually -``` +```bash git clone https://github.com/sigstore/rekor.git rekor-cli cd rekor-cli make rekor-cli @@ -42,8 +41,8 @@ cp rekor-cli /usr/local/bin/ 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. +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: @@ -73,25 +72,25 @@ Grab the Rekor source: Rekor requires a database. We use MariaDB for now (others to be explored later). Install and set up MariaDB on your machine. -``` +```bash dnf install mariadb mariadb-server systemctl start mariadb systemctl enable mariadb mysql_secure_installation ``` - + The Rekor directory has a `scripts/createdb.sh` file that will set up a test database (default user: test; default password: zaphod) and populate the needed tables for Trillian. If you’re just trying out Rekor, keep the DB user name and password the same as in the script (test/zaphod). If you change these, you need to make the changes on Trillian’s side (visit the [Trillian repo](https://github.com/google/trillian) for details). -``` +```bash cd $GOPATH/pkg/mod/github.com/sigstore/rekor@v0.4.0/scripts/ sh createdb.sh -``` - +``` + ### Build Trillian You also need to build Trillian, an append-only log: -``` +```bash go get -u -t -v github.com/google/trillian cd $GOPATH/src/github.com/google/trillian/cmd/trillian_log_server go build @@ -108,20 +107,21 @@ cp createtree /usr/local/bin/ Next, run the Trillian log server: -``` +```bash trillian_log_server --logtostderr ... ``` Run the signer: -``` +```bash trillian_log_signer --logtostderr --force_master --rpc_endpoint=localhost:8190 -http_endpoint=localhost:8191 --batch_size=1000 --sequencer_guard_window=0 --sequencer_interval=200ms ``` + > Note: you can log both to files and to stderr using `--alsologtostderr` Create the tree: -``` +```bash createtree --admin_server=localhost:8090 ``` @@ -129,7 +129,7 @@ createtree --admin_server=localhost:8090 With Trillian and MariaDB set up, you can now build the Rekor Server: -``` +```bash cd $GOPATH/pkg/mod/github.com/sigstore/rekor@v0.4.0/cmd/rekor-server go build -v -o rekor-server cp rekor-server /usr/local/bin/ @@ -137,14 +137,15 @@ cp rekor-server /usr/local/bin/ #### Start the Rekor Server -``` +```bash rekor-server serve --enable_retrieve_api=false -2020-09-12T16:32:22.705+0100 INFO cmd/root.go:87 Using config file: /Users/lukehinds/go/src/github.com/sigstore/rekor-server/rekor-server.yaml -2020-09-12T16:32:22.705+0100 INFO app/server.go:55 Starting server... -2020-09-12T16:32:22.705+0100 INFO app/server.go:61 Listening on 127.0.0.1:3000 +2020-09-12T16:32:22.705+0100 INFO cmd/root.go:87 Using config file: /Users/lukehinds/go/src/github.com/sigstore/rekor-server/rekor-server.yaml +2020-09-12T16:32:22.705+0100 INFO app/server.go:55 Starting server... +2020-09-12T16:32:22.705+0100 INFO app/server.go:61 Listening on 127.0.0.1:3000 ``` -> If you have a redis server running to enable searching your Rekor server, remove the `enable_reprieve_api` flag + +> If you have a redis server running to enable searching your Rekor server, remove the `enable_reprieve_api` flag #### Next Steps diff --git a/content/en/docs/logging/overview.md b/content/en/docs/logging/overview.md index 1d6cb627..341e02c1 100644 --- a/content/en/docs/logging/overview.md +++ b/content/en/docs/logging/overview.md @@ -20,21 +20,15 @@ Rekor fulfils the signature transparency role of sigstore’s software signing i You can download and setup the Rekor Server and Rekor CLI by following the instructions on the [Installation](/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. +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. ## Auditing the Public Instance -Rekor is built on top of a [verifiable data structure](https://transparency.dev/verifiable-data-structures/). Auditors -can monitor the log for consistency, meaning that the log remains append-only and entries are never mutated or removed. +Rekor is built on top of a [verifiable data structure](https://transparency.dev/verifiable-data-structures/). Auditors can monitor the log for consistency, meaning that the log remains append-only and entries are never mutated or removed. Verifiers can also monitor the log for their identities. Learn more about transparency logs [here](https://transparency.dev/), and about binary transparency [here](https://binary.transparency.dev/). There are few options for auditing and monitoring the Rekor log. We've built a monitor that runs on GitHub Actions, -[Rekor monitor](https://github.com/sigstore/rekor-monitor). Follow the instructions to set up a new repository and -use the [provided reusable workflow](https://github.com/sigstore/rekor-monitor/blob/main/.github/workflows/reusable_monitoring.yml) -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. +[Rekor monitor](https://github.com/sigstore/rekor-monitor). Follow the instructions to set up a new repository and use the [provided reusable workflow](https://github.com/sigstore/rekor-monitor/blob/main/.github/workflows/reusable_monitoring.yml) 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. \ No newline at end of file +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. diff --git a/content/en/docs/logging/sign-upload.md b/content/en/docs/logging/sign-upload.md index bf1647ec..330f813d 100644 --- a/content/en/docs/logging/sign-upload.md +++ b/content/en/docs/logging/sign-upload.md @@ -7,11 +7,14 @@ weight: 1835 This documentation contains information on how to sign and upload data in different [pluggable types](/logging/pluggable-types/). The following are covered: + - [Minisign](#minisign) - [SSH](#ssh) - [PKIX/X509](#pkixx509) -- RPM (TODO) -- TSR (TODO) +- [RPM](#rpm) +- [Alpine](#alpine) +- [RPM](#rpm-1) +- [TSR](#tsr) - [TUF](#tuf) ## Minisign @@ -160,7 +163,7 @@ writing EC key Sign the file with: ```console -$ openssl dgst -sha256 -sign ec_private.pem -out README.md.sig README.md +openssl dgst -sha256 -sign ec_private.pem -out README.md.sig README.md ``` Upload it to rekor with: @@ -220,15 +223,15 @@ Generate a TUF repository (for example, with the [Python reference implementatio With go-tuf: ```console -$ tuf init -$ tuf gen-key root -$ tuf gen-key targets -$ tuf gen-key snapshot -$ tuf gen-key timestamp -$ tuf add path/to/some/target.txt -$ tuf snapshot -$ tuf timestamp -$ tuf commit +tuf init +tuf gen-key root +tuf gen-key targets +tuf gen-key snapshot +tuf gen-key timestamp +tuf add path/to/some/target.txt +tuf snapshot +tuf timestamp +tuf commit ``` You will find the signed metadata in your TUF `repository/` directory: @@ -285,5 +288,4 @@ Body: { } } } - -``` \ No newline at end of file +``` diff --git a/content/en/docs/logging/verify-release.md b/content/en/docs/logging/verify-release.md index cc0bec04..c1c48e2d 100644 --- a/content/en/docs/logging/verify-release.md +++ b/content/en/docs/logging/verify-release.md @@ -25,30 +25,30 @@ For example, with binary `rekor-cli-linux-amd64`, also retrieve `rekor-cli-linux * `rekor-cli-linux-amd64_cert.pem`: The signing certificate. This is an X509 certificate generated by the sigstore root CA, with the email of a project maintainer embedded as a X509v3 Subject Alternative Name. This provides a guarantee that the binary was signed by the individual with access to that account (the email comes from an OpenID provider). In turn, this information is recorded into the transparency log so that the account can be monitored for misuse or compromise. * `rekor-cli-linux-amd64_signature.sig`: This is the signature generated as a result of the signing event. -#### Basic verify +### Basic verify With the above three files, we can now perform a rudimentary verification. We grab the public key from the signing cert: -``` -$ openssl x509 -pubkey -noout -in rekor-cli-linux-amd64_cert.pem > rekor-cli-linux-amd64_cert_public.pem +```sh +openssl x509 -pubkey -noout -in rekor-cli-linux-amd64_cert.pem > rekor-cli-linux-amd64_cert_public.pem ``` And then we verify: -``` +```sh $ openssl dgst -sha256 -verify rekor-cli-linux-amd64_cert_public.pem -signature rekor-cli-linux-amd64_signature.sig rekor-cli-linux-amd64 Verified OK ``` -#### Verify the certificate chain +### Verify the certificate chain We should check the trust chain against sigstore's Root CA. The root CA for Fulcio is currently: -``` +```bash -----BEGIN CERTIFICATE----- MIIB+DCCAX6gAwIBAgITNVkDZoCiofPDsy7dfm6geLbuhzAKBggqhkjOPQQDAzAq MRUwEwYDVQQKEwxzaWdzdG9yZS5kZXYxETAPBgNVBAMTCHNpZ3N0b3JlMB4XDTIx @@ -70,37 +70,37 @@ Save this locally to your machine as `fulcio-root.pem` Let's now validate the certificate chain: -``` +```sh $ openssl verify -verbose -no_check_time -CAfile fulcio-root.pem rekor-cli-linux-amd64_cert.pem rekor-cli-linux-amd64_cert.pem: OK ``` > 📓 We use `-no_check_time` as Fulcio certificates are short-lived (so they always will be expired by design!) -#### Verify the signing identity +### Verify the signing identity However, how do we know we can trust that public key is from a maintainer at sigstore? Let's look at mapping this to an identity: -``` +```sh $ openssl x509 -in rekor-cli-linux-amd64_cert.pem -noout -text |grep email email:ctadeu@gmail.com ``` OK, so we can see that a Fulcio-generated certificate, with a chain to the root certificate has the email identity of a sigstore maintainer (in this instance, our own release manager the awesome Carlos). -#### Verify the entry is in the transparency log +### Verify the entry is in the transparency log On the [release page](https://github.com/sigstore/rekor/releases) you will see some URLs, these are the rekor entries of the signing events. This is the link for the binary and signing materials we have been working with throughout this guide -https://rekor.sigstore.dev/api/v1/log/entries/b6fdc91e6af5bdd8df133802b7966aa53c1e59365741ee56e287f11263e02c33 +[https://rekor.sigstore.dev/api/v1/log/entries/b6fdc91e6af5bdd8df133802b7966aa53c1e59365741ee56e287f11263e02c33](https://rekor.sigstore.dev/api/v1/log/entries/b6fdc91e6af5bdd8df133802b7966aa53c1e59365741ee56e287f11263e02c33) Let's dig into this: -``` +```sh $ curl -X GET "https://rekor.sigstore.dev/api/v1/log/entries/b6fdc91e6af5bdd8df133802b7966aa53c1e59365741ee56e287f11263e02c33" | jq { @@ -140,7 +140,7 @@ $ curl -X GET "https://rekor.sigstore.dev/api/v1/log/entries/b6fdc91e6af5bdd8df1 Let's focus on the body and decode it from base64: -``` +```sh $ curl -X GET "https://rekor.sigstore.dev/api/v1/log/entries/b6fdc91e6af5bdd8df133802b7966aa53c1e59365741ee56e287f11263e02c33" | jq -r '.[].body'| base64 -d | jq -r '.[]' { @@ -162,26 +162,26 @@ $ curl -X GET "https://rekor.sigstore.dev/api/v1/log/entries/b6fdc91e6af5bdd8df1 Ok, now you can see the digest of the artifact that was signed: -``` +```sh $ sha256sum rekor-cli-linux-amd64 ce9a7c82f32194995888758cf107ef0cc52e0b8cdce73b4240658ee9e73783cb rekor-cli-linux-amd64 ``` We can then grab the signing certificate: -``` +```sh echo LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNrakNDQWhpZ0F3SUJBZ0lVQU0rK0dYRFN5bUNPSW82YmxMMG5EZngxb21nd0NnWUlLb1pJemowRUF3TXcKS2pFVk1CTUdBMVVFQ2hNTWMybG5jM1J2Y21VdVpHVjJNUkV3RHdZRFZRUURFd2h6YVdkemRHOXlaVEFlRncweQpNVEEzTWpnd09ETTNOREphRncweU1UQTNNamd3T0RVM05ERmFNQUF3ZGpBUUJnY3Foa2pPUFFJQkJnVXJnUVFBCklnTmlBQVJjMDMrUU4vTHBrOGpqUFQwTmV5a01ucm9mMnpZUkJxNm05ei9TMXhRSzduZnZhU3grRjUrTEtwN3gKR2ExbHY2SWNvRXdwUHA2MUdsYnd5S0VQVWJLdzJrYnJyRVpPMnhKV3kxb0VEUHBYMlJqcTBYS0RZcEF5Zi9mQwoyZzJjSnVtamdnRW5NSUlCSXpBT0JnTlZIUThCQWY4RUJBTUNCNEF3RXdZRFZSMGxCQXd3Q2dZSUt3WUJCUVVICkF3TXdEQVlEVlIwVEFRSC9CQUl3QURBZEJnTlZIUTRFRmdRVTRBUDhtTkI4ejhSZFJyTVVLZ1A2Mm0xUFErd3cKSHdZRFZSMGpCQmd3Rm9BVXlNVWRBRUdhSkNreVVTVHJEYTVLN1VvRzArd3dnWTBHQ0NzR0FRVUZCd0VCQklHQQpNSDR3ZkFZSUt3WUJCUVVITUFLR2NHaDBkSEE2THk5d2NtbDJZWFJsWTJFdFkyOXVkR1Z1ZEMwMk1ETm1aVGRsCk55MHdNREF3TFRJeU1qY3RZbVkzTlMxbU5HWTFaVGd3WkRJNU5UUXVjM1J2Y21GblpTNW5iMjluYkdWaGNHbHoKTG1OdmJTOWpZVE0yWVRGbE9UWXlOREppT1daallqRTBOaTlqWVM1amNuUXdIZ1lEVlIwUkFRSC9CQlF3RW9FUQpZM1JoWkdWMVFHZHRZV2xzTG1OdmJUQUtCZ2dxaGtqT1BRUURBd05vQURCbEFqRUE3TTJwSzhRUFRrSGs1bzZ0CmdnampZdjBLV1BUajRKUTAwU3RjR0xqa1g3SU1iNC9HdXpYRkQ4czZDOEd3NmpwMEFqQW1Xa2JROTVsMzlnUGQKR2pjUjBSQURaT0dYb0NPQURwOE5lSzhBL2dKdWdnR0ZINHZYZ2l1ODJsQm5MOEZSc09jPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==| base64 -d > tlog_signing_cert.pem``` ``` Which is, of course, the same as our signing certificate: -``` -$ diff tlog_signing_cert.pem rekor-cli-linux-amd64_cert.pem +```sh +diff tlog_signing_cert.pem rekor-cli-linux-amd64_cert.pem ``` And the signature can also be retrieved: -``` +```sh echo MGUCMD3oKzgsGnPAkJEXegDIsdlh4BFCQbM6jng4Sy3axY/+2tlK97oe/CkxabT1ZXUqCAIxAJDq+zLfRZZEJD5DvaKhFEu+Jm+jD4UXc3CaZp2MSajiralmtalA6fSGCXjwGfUzOw== | base64 -d > tlog_signing_sig.sig $ diff tlog_signing_sig.sig rekor-cli-linux-amd64_signature.sig @@ -189,7 +189,7 @@ $ diff tlog_signing_sig.sig rekor-cli-linux-amd64_signature.sig So we can then do the same verification using just the tlog! -``` +```sh $ openssl x509 -pubkey -noout -in tlog_signing_cert.pem > tlog_signing_cert_public.pem $ openssl dgst -sha256 -verify tlog_signing_cert_public.pem -signature tlog_signing_sig.sig rekor-cli-linux-amd64 Verified OK diff --git a/content/en/docs/signing/pkcs11.md b/content/en/docs/signing/pkcs11.md index eb7ad87d..6723f8f6 100644 --- a/content/en/docs/signing/pkcs11.md +++ b/content/en/docs/signing/pkcs11.md @@ -10,8 +10,8 @@ This support is enabled through the [crypto11](https://github.com/ThalesIgnite/c For the following examples, we have: ```shell -$ IMAGE=gcr.io/vmtest2/demo -$ IMAGE_DIGEST=$IMAGE@sha256:410a07f17151ffffb513f942a01748dfdb921de915ea6427d61d60b0357c1dcd +IMAGE=gcr.io/vmtest2/demo +IMAGE_DIGEST=$IMAGE@sha256:410a07f17151ffffb513f942a01748dfdb921de915ea6427d61d60b0357c1dcd ``` ## Quick Start diff --git a/content/en/docs/system_config/installation.md b/content/en/docs/system_config/installation.md index 72c760d4..579ab671 100644 --- a/content/en/docs/system_config/installation.md +++ b/content/en/docs/system_config/installation.md @@ -134,7 +134,7 @@ Before using Cosign, you will need to download and also initialize the TUF envir To do this, install and use [go-tuf](https://github.com/theupdateframework/go-tuf)'s CLI tools: ```console -$ go install github.com/theupdateframework/go-tuf/cmd/tuf-client@latest +go install github.com/theupdateframework/go-tuf/cmd/tuf-client@latest ``` Then, obtain trusted root keys for Sigstore. You will use the 5th iteration of Sigstore's TUF root to start the root of trust, due to a backward incompatible change. The TUF client uses this root to start a chain of roots, and will download the latest, unexpired root as part of [its workflow](https://theupdateframework.github.io/specification/latest/#update-root). From 30094d020827af67c195560d770a0717db3b5867 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E8=AF=BA=E5=A2=A8?= Date: Fri, 25 Aug 2023 14:10:20 +0800 Subject: [PATCH 2/2] docs(lint): follow `MD009` and `MD014` to improve docs and replace `console` with `bash` MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Resolves #225 Signed-off-by: 诺墨 --- content/en/system_config/installation.md | 34 ++++++++++++------------ 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/content/en/system_config/installation.md b/content/en/system_config/installation.md index b0754b53..2dbfe81b 100644 --- a/content/en/system_config/installation.md +++ b/content/en/system_config/installation.md @@ -9,7 +9,7 @@ weight: 950 If you have Go 1.19+, you can directly install Cosign by downloading the Cosign binary and running: -```console +```bash go install github.com/sigstore/cosign/v2/cmd/cosign@latest ``` @@ -19,7 +19,7 @@ The resulting binary will be placed at `$GOPATH/bin/cosign` (or `$GOBIN/cosign`, Download the binary for your platform from the [Cosign releases page](https://github.com/sigstore/cosign/releases/latest). -```console +```bash # binary curl -O -L "https://github.com/sigstore/cosign/releases/latest/download/cosign-linux-amd64" mv cosign-linux-amd64 /usr/local/bin/cosign @@ -40,7 +40,7 @@ dpkg -i cosign_${LATEST_VERSION}_amd64.deb If you are using Homebrew (or Linuxbrew), you can install Cosign by running: -```console +```bash brew install cosign ``` @@ -48,7 +48,7 @@ brew install cosign If you are using Arch Linux, you can install Cosign by running: -```console +```bash pacman -S cosign ``` @@ -57,7 +57,7 @@ pacman -S cosign If you are using Alpine Linux edge, with the [community repository enabled](https://wiki.alpinelinux.org/w/index.php?title=Enable_Community_Repository), you can install `cosign` by running: -```console +```bash apk add cosign ``` @@ -65,7 +65,7 @@ apk add cosign If you are using Nix, you can install Cosign by running: -```console +```bash nix-env -iA nixpkgs.cosign ``` @@ -73,7 +73,7 @@ nix-env -iA nixpkgs.cosign If you are on NixOS, you can install Cosign by running: -```console +```bash nix-env -iA nixos.cosign ``` @@ -100,7 +100,7 @@ They are tagged with the release name (for example, `gcr.io/projectsigstore/cosi You can get the latest release with `crane ls gcr.io/projectsigstore/cosign | tail -1`. To list all versions, signatures and SBOMs: -```console +```bash $ crane ls gcr.io/projectsigstore/cosign ... sha256-a95d7c4ab27e48aaf89253e0703014709129f010578be809b6c95ccee908fa1b.sbom @@ -114,7 +114,7 @@ CI Built containers are published for every commit at `gcr.io/projectsigstore/co They are tagged with the commit. They can be found with `crane ls`: -```console +```bash $ crane ls gcr.io/projectsigstore/cosign/ci/cosign 749f896 749f896bb378aca5cb45c5154fc0cb43f6728d48 @@ -134,13 +134,13 @@ Before using Cosign, you will need to download and also initialize the TUF envir To do this, install and use [go-tuf](https://github.com/theupdateframework/go-tuf)'s CLI tools: -```console +```bash go install github.com/theupdateframework/go-tuf/cmd/tuf-client@latest ``` Then, obtain trusted root keys for Sigstore. You will use the 5th iteration of Sigstore's TUF root to start the root of trust, due to a backward incompatible change. The TUF client uses this root to start a chain of roots, and will download the latest, unexpired root as part of [its workflow](https://theupdateframework.github.io/specification/latest/#update-root). -```console +```bash curl -o sigstore-root.json https://raw.githubusercontent.com/sigstore/root-signing/main/ceremony/2022-10-18/repository/5.root.json ``` @@ -150,15 +150,15 @@ Note that you can verify the 5th TUF root against the 1st TUF root, which was si Then initialize the tuf client with the previously obtained root key and the remote repository; -```console -$ tuf-client init https://tuf-repo-cdn.sigstore.dev sigstore-root.json +```bash +tuf-client init https://tuf-repo-cdn.sigstore.dev sigstore-root.json ``` #### Verifying with key You will retrieve the artifact verification key from the trusted TUF repository and use it to verify the Cosign release. -```console +```bash tuf-client get https://tuf-repo-cdn.sigstore.dev artifact.pub > artifact.pub curl -o cosign-release.sig -L https://github.com/sigstore/cosign/releases/download//cosign-.sig @@ -173,13 +173,13 @@ The ``and `` placeholders in the URLs should be replaced with the s ### Verifying Cosign with identity-based verification -Once you have verified Cosign with an artifact key, you can use Cosign to verify future releases of Cosign using identity-based verification. +Once you have verified Cosign with an artifact key, you can use Cosign to verify future releases of Cosign using identity-based verification. #### Verifying Cosign binary To verify a Cosign binary, you will need to fetch the signature and certificate from GitHub. -```console +```bash curl -o cosign-release.sig -L https://github.com/sigstore/cosign/releases/download//cosign--keyless.sig base64 -d cosign-release.sig > cosign-release.sig.decoded @@ -196,7 +196,7 @@ cosign verify-blob new-cosign --certificate cosign-release.pem.decoded --signatu You can also verify a container image of Cosign. You can use [crane](https://github.com/google/go-containerregistry/blob/main/cmd/crane/README.md) to get the latest version of Cosign. You can skip the first two steps if you already have the container image. -```console +```bash COSIGN_VERSION=$(crane ls gcr.io/projectsigstore/cosign | tail -1) COSIGN_DIGEST=$(crane digest gcr.io/projectsigstore/cosign:$COSIGN_VERSION)