Repository files navigation

Signing OCI containers (and other artifacts) usingSigstore!

Cosign aims to make signaturesinvisible infrastructure.

Cosign supports:

• "Keyless signing" with the Sigstore public good Fulcio certificate authority and Rekor transparency log (default)
• Hardware and KMS signing
• Signing with a cosign generated encrypted private/public keypair
• Container Signing, Verification and Storage in an OCI registry.
• Bring-your-own PKI

Cosign is developed as part of thesigstore project.We also use aslack channel!Clickhere for the invite link.

For Homebrew, Arch, Nix, GitHub Action, and Kubernetes installs see theinstallation docs.

For Linux and macOS binaries see theGitHub release assets.

🚨 If you are downloading releases of cosign from our GCS bucket - please see more information on the July 31, 2023deprecation notice 🚨

If you have Go 1.22+, you can setup a development environment:

$ git clone https://github.com/sigstore/cosign$cd cosign$ go install ./cmd/cosign$$(go env GOPATH)/bin/cosign

If you are interested in contributing tocosign, please read thecontributing documentation.

Future Cosign development will be focused the next major release which will be based onsigstore-go. Maintainers will be focused on feature development withinsigstore-go. Contributions to sigstore-go, particularly around bring-your-own keys and signing, are appreciated.Please see theissue tracker for good first issues.

Cosign 2.x is a stable release and will continue to receive periodic feature updates and bug fixes. PRsthat are small in scope and size are most likely to be quickly reviewed.

PRs which significantly modify or break the API will not be accepted. PRs which are significant in size but do notintroduce breaking changes may be accepted, but will be considered lower priority than PRs in sigstore-go.

Here is how to install and use cosign inside a Dockerfile through the ghcr.io/sigstore/cosign/cosign image:

FROM ghcr.io/sigstore/cosign/cosign:v2.4.1 as cosign-bin# Source: https://github.com/chainguard-images/staticFROM cgr.dev/chainguard/static:latestCOPY --from=cosign-bin /ko-app/cosign /usr/local/bin/cosignENTRYPOINT ["cosign" ]

This shows how to:

• sign a container image with the default identity-based "keyless signing" method (seethe documentation for more information)
• verify the container image

Note that you should always sign images based on their digest (@sha256:...)rather than a tag (:latest) because otherwise you might sign something youdidn't intend to!

 cosign sign$IMAGEGenerating ephemeral keys...Retrieving signed certificate...Note that there may be personally identifiable information associated with this signed artifact.This may include the email address associated with the account with which you authenticate.This information will be usedforsigning this artifact and will be storedin public transparency logs and cannot be removed later.By typing'y', you attest that you grant (or have permission to grant) and agree to have this information stored permanentlyin transparency logs.Are you sure you would like to continue? [y/N] yYour browser will now be opened to:https://oauth2.sigstore.dev/auth/auth?access_type=online&client_id=sigstore&code_challenge=OrXitVKUZm2lEWHVt1oQWR4HZvn0rSlKhLcltglYxCY&code_challenge_method=S256&nonce=2KvOWeTFxYfxyzHtssvlIXmY6Jk&redirect_uri=http%3A%2F%2Flocalhost%3A57102%2Fauth%2Fcallback&response_type=code&scope=openid+email&state=2KvOWfbQJ1caqScgjwibzK2qJmbSuccessfully verified SCT...tlog entry created with index: 12086900Pushing signature to:$IMAGE

Cosign will prompt you to authenticate via OIDC, where you'll sign in with your email address.Under the hood, cosign will request a code signing certificate from the Fulcio certificate authority.The subject of the certificate will match the email address you logged in with.Cosign will then store the signature and certificate in the Rekor transparency log, and upload the signature to the OCI registry alongside the image you're signing.

To verify the image, you'll need to pass in the expected certificate subject and certificate issuer via the--certificate-identity and--certificate-oidc-issuer flags:

cosign verify $IMAGE --certificate-identity=$IDENTITY --certificate-oidc-issuer=$OIDC_ISSUER

You can also pass in a regex for the certificate identity and issuer flags,--certificate-identity-regexp and--certificate-oidc-issuer-regexp.

This command returns0 ifat least onecosign formatted signature for the image is foundmatching the public key.See the detailed usage below for information and caveats on other signature formats.

Any valid payloads are printed to stdout, in json format.Note that these signed payloads include the digest of the container image, which is how we can besure these "detached" signatures cover the correct image.

$ cosign verify --key cosign.pub$IMAGE_URI:1hThe following checks were performed on these signatures:  - The cosign claims were validated  - The signatures were verified against the specified public key{"Critical":{"Identity":{"docker-reference":""},"Image":{"Docker-manifest-digest":"sha256:87ef60f558bad79beea6425a3b28989f01dd417164150ab3baab98dcbf04def8"},"Type":"cosign container image signature"},"Optional":null}

Note: This section is out of date.

Note: Most verification workflows require periodically requesting service keys from a TUF repository.For airgapped verification of signatures using the public-good instance, you will need to retrieve thetrusted root file from the productionTUF repository. The contents of this file will change without notification. By not using TUF, you will needto build your own mechanism to keep your airgapped copy of this file up-to-date.

Cosign can do completely offline verification by verifying abundle which is typically distributed as an annotation on the image manifest.As long as this annotation is present, then offline verification can be done.This bundle annotation is always included by default for keyless signing, so the defaultcosign sign functionality will include all materials needed for offline verification.

To verify an image in an air-gapped environment, the image and signatures must be available locally on the filesystem.

An image can be saved locally usingcosign save (note, this step must be done with a network connection):

cosign initialize # This will pull in the latest TUF rootcosign save $IMAGE_NAME --dir ./path/to/dir

Now, in an air-gapped environment, this local image can be verified:

cosign verify --certificate-identity $CERT_IDENTITY --certificate-oidc-issuer $CERT_OIDC_ISSUER --offline --local-image ./path/to/dir

You'll need to pass in expected values for$CERT_IDENTITY and$CERT_OIDC_ISSUER to correctly verify this image.If you signed with a keypair, the same command will work, assuming the public key material is present locally:

cosign verify --key cosign.pub --offline --local-image ./path/to/dir

While parts ofcosign are stable, we are continuing to experiment and add new features.The following feature set is not considered stable yet, but we are committed to stabilizing it over time!

While thecosign code for uploading, signing, retrieving, and verifying several artifact types is stable,the format specifications for some of those types may not be considered stable yet.Some of these are developed outside of thecosign project, so we are waiting for them to stabilize first.

These include:

• The SBOM specification for storing SBOMs in a container registry
• The In-Toto attestation format

OCI registries are useful for storing more than just container images!Cosign also includes some utilities for publishing generic artifacts, including binaries, scripts, and configuration files using the OCI protocol.

This section shows how to leverage these for an easy-to-use, backwards-compatible artifact distribution system that integrates well with the rest of Sigstore.

Seethe documentation for more information.

You can publish an artifact withcosign upload blob:

$echo"my first artifact"> artifact$ BLOB_SUM=$(shasum -a 256 artifact| cut -d'' -f 1)&&echo"$BLOB_SUM"c69d72c98b55258f9026f984e4656f0e9fd3ef024ea3fac1d7e5c7e6249f1626$ BLOB_NAME=my-artifact-$(uuidgen| head -c 8| tr'A-Z''a-z')$ BLOB_URI=ttl.sh/$BLOB_NAME:1h$ BLOB_URI_DIGEST=$(cosign upload blob -f artifact$BLOB_URI)&&echo"$BLOB_URI_DIGEST"Uploading file from [artifact] to [ttl.sh/my-artifact-f42c22e0:5m] with mediatype [text/plain]File [artifact] is available directly at [ttl.sh/v2/my-artifact-f42c22e0/blobs/sha256:c69d72c98b55258f9026f984e4656f0e9fd3ef024ea3fac1d7e5c7e6249f1626]Uploaded image to:ttl.sh/my-artifact-f42c22e0@sha256:790d47850411e902aabebc3a684eeb78fcae853d4dd6e1cc554d70db7f05f99f

Your users can download it from the "direct" url with standard tools like curl or wget:

$ curl -L ttl.sh/v2/$BLOB_NAME/blobs/sha256:$BLOB_SUM> artifact-fetched

The digest is baked right into the URL, so they can check that as well:

$ cat artifact-fetched| shasum -a 256c69d72c98b55258f9026f984e4656f0e9fd3ef024ea3fac1d7e5c7e6249f1626  -

You can sign it with the normalcosign sign command and flags:

$ cosign sign --key cosign.key$BLOB_URI_DIGESTEnter passwordfor private key:Pushing signature to: ttl.sh/my-artifact-f42c22e0

As usual, make sure to reference any images you sign by their digest to make sure you don't sign the wrong thing!

Tekton bundles can be uploaded and managed within an OCI registry.The specification ishere.This means they can also be signed and verified withcosign.

Tekton Bundles can currently be uploaded with thetkn cli, but we may add this support tocosign in the future.

$ tkn bundle push us.gcr.io/dlorenc-vmtest2/pipeline:latest -f task-output-image.yamlCreating Tekton Bundle:        - Added TaskRun:  to imagePushed Tekton Bundle to us.gcr.io/dlorenc-vmtest2/pipeline@sha256:124e1fdee94fe5c5f902bc94da2d6e2fea243934c74e76c2368acdc8d3ac7155$ cosign sign --key cosign.key us.gcr.io/dlorenc-vmtest2/pipeline@sha256:124e1fdee94fe5c5f902bc94da2d6e2fea243934c74e76c2368acdc8d3ac7155Enter passwordfor private key:tlog entry created with index: 5086Pushing signature to: us.gcr.io/dlorenc-vmtest2/demo:sha256-124e1fdee94fe5c5f902bc94da2d6e2fea243934c74e76c2368acdc8d3ac7155.sig

Web Assembly Modules can also be stored in an OCI registry, using thisspecification.

Cosign can upload these using thecosign wasm upload command:

$ cosign upload wasm -f hello.wasm us.gcr.io/dlorenc-vmtest2/wasm$ cosign sign --key cosign.key us.gcr.io/dlorenc-vmtest2/wasm@sha256:9e7a511fb3130ee4641baf1adc0400bed674d4afc3f1b81bb581c3c8f613f812Enter passwordfor private key:tlog entry created with index: 5198Pushing signature to: us.gcr.io/dlorenc-vmtest2/wasm:sha256-9e7a511fb3130ee4641baf1adc0400bed674d4afc3f1b81bb581c3c8f613f812.sig

eBPF modules can also be stored in an OCI registry, using thisspecification.

The image below was built using thebee tool. More information can be foundhere

Cosign can then sign these images as they can any other OCI image.

$ bee build ./examples/tcpconnect/tcpconnect.c localhost:5000/tcpconnect:test$ bee push localhost:5000/tcpconnect:test$ cosign sign  --key cosign.key localhost:5000/tcpconnect@sha256:7a91c50d922925f152fec96ed1d84b7bc6b2079c169d68826f6cf307f22d40e6Enter passwordfor private key:Pushing signature to: localhost:5000/tcpconnect$ cosign verify --key cosign.pub localhost:5000/tcpconnect:testVerificationfor localhost:5000/tcpconnect:test --The following checks were performed on each of these signatures:  - The cosign claims were validated  - The signatures were verified against the specified public key[{"critical":{"identity":{"docker-reference":"localhost:5000/tcpconnect"},"image":{"docker-manifest-digest":"sha256:7a91c50d922925f152fec96ed1d84b7bc6b2079c169d68826f6cf307f22d40e6"},"type":"cosign container image signature"},"optional":null}]

Cosign also has built-in support forin-toto attestations.The specification for these is definedhere.

You can create and sign one from a local predicate file using the following commands:

$ cosign attest --predicate<file> --key cosign.key$IMAGE_URI_DIGEST

All of the standard key management systems are supported.Payloads are signed using the DSSE signing spec, definedhere.

To verify:

$ cosign verify-attestation --key cosign.pub$IMAGE_URI

See theUsage documentation for more information.

See theHardware Tokens documentation for information on how to usecosign with hardware.

cosign usesgo-containerregistry for registryinteractions, which has generally excellent compatibility, but some registries may have quirks.

Today,cosign has been tested and works against the following registries:

• AWS Elastic Container Registry
• GCP's Artifact Registry and Container Registry
• Docker Hub
• Azure Container Registry
• JFrog Artifactory Container Registry
• The CNCF distribution/distribution Registry
• GitLab Container Registry
• GitHub Container Registry
• The CNCF Harbor Registry
• Digital Ocean Container Registry
• Sonatype Nexus Container Registry
• Alibaba Cloud Container Registry
• Red Hat Quay Container Registry 3.6+ / Red Hat quay.io
• Elastic Container Registry
• IBM Cloud Container Registry
• Cloudsmith Container Registry
• The CNCF zot Registry
• OVHcloud Managed Private Registry

We aim for wide registry support. Tosign images in registries which do not yet fully supportOCI media types, one may need to useCOSIGN_DOCKER_MEDIA_TYPES to fall back to legacy equivalents. For example:

COSIGN_DOCKER_MEDIA_TYPES=1 cosign sign --key cosign.key legacy-registry.example.com/my/image@$DIGEST

Please help test and file bugs if you see issues!Instructions can be found in thetracking issue.

cosign only generates ECDSA-P256 keys and uses SHA256 hashes, for both ephemeral keyless signing and managed key signing.Keys are stored in PEM-encoded PKCS8 format.However, you can usecosign to store and retrieve signatures in any format, from any algorithm.

cosign only supports Red Hat'ssimple signingformat for payloads.That looks like:

{"critical": {"identity": {"docker-reference":"testing/manifest"           },"image": {"Docker-manifest-digest":"sha256:20be...fe55"           },"type":"cosign container image signature"    },"optional": {"creator":"Bob the Builder","timestamp":1458239713    }}

Note: This can be generated for an image reference usingcosign generate $IMAGE_URI_DIGEST.

I'm happy to switch this format to something else if it makes sense.Seenotaryproject/notation#40 for one option.

cosign signatures are stored as separate objects in the OCI registry, with only a weakreference back to the object they "sign".This means this relationship is opaque to the registry, and signatureswill not be deletedor garbage-collected when the image is deleted.Similarly, theycan easily be copied from one environment to another, but this is notautomatic.

Multiple signatures are stored in a list which is unfortunately a race condition today.To add a signature, clients orchestrate a "read-append-write" operation, so the last writewill win in the case of contention.

cosign will default to storing signatures in the same repo as the image it is signing.To specify a different repo for signatures, you can set theCOSIGN_REPOSITORY environment variable.

This will replace the repo in the provided image like this:

$export COSIGN_REPOSITORY=gcr.io/my-new-repo$ cosign sign --key cosign.key$IMAGE_URI_DIGEST

So the signature forgcr.io/dlorenc-vmtest2/demo will be stored ingcr.io/my-new-repo/demo:sha256-DIGEST.sig.

Note: different registries might expect different formats for the "repository."

• To useGCR, a registry namelikegcr.io/$REPO is sufficient, as in the example above.

• To useArtifact Registry,specify a full image name like$LOCATION-docker.pkg.dev/$PROJECT/$REPO/$STORAGE_IMAGE, not just arepository. For example,

  $export COSIGN_REPOSITORY=us-docker.pkg.dev/my-new-repo/demo$ cosign sign --key cosign.key$IMAGE_URI_DIGEST

  where thesha256-DIGEST will match the digest forgcr.io/dlorenc-vmtest2/demo. Specifying just a repo like$LOCATION-docker.pkg.dev/$PROJECT/$REPO will not work in Artifact Registry.

cosign is inspired by tools likeminisign andsignify.

Generated private keys are stored in PEM format.The keys encrypted under a password using scrypt as a KDF and nacl/secretbox for encryption.

They have a PEM header ofENCRYPTED SIGSTORE PRIVATE KEY:

-----BEGIN ENCRYPTED SIGSTORE PRIVATE KEY-----...-----END ENCRYPTED SIGSTORE PRIVATE KEY-----

Public keys are stored on disk in PEM-encoded standard PKIX format with a header ofPUBLIC KEY.

-----BEGIN PUBLIC KEY-----MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAELigCnlLNKgOglRTx1D7JhI7eRw99QolE9Jo4QUxnbMy5nUuBL+UZF9qqfm/Dg1BNeHRThHzWh2ki9vAEgWEDOw==-----END PUBLIC KEY-----

cosign stores signatures in an OCI registry, and uses a naming convention (tag basedon the sha256 of what we're signing) for locating the signature index.

reg.example.com/ubuntu@sha256:703218c0465075f4425e58fac086e09e1de5c340b12976ab9eb8ad26615c3715 has signatures located atreg.example.com/ubuntu:sha256-703218c0465075f4425e58fac086e09e1de5c340b12976ab9eb8ad26615c3715.sig

Roughly (ignoring ports in the hostname):s/:/-/g ands/@/:/g to find the signature index.

SeeRace conditions for some caveats around this strategy.

Alternative implementations could use transparency logs, local filesystem, a separate repositoryregistry, an explicit reference to a signature index, a new registry API, grafeas, etc.

cosign only works for artifacts stored as "manifests" in the registry today.The proposed mechanism is flexible enough to support signing arbitrary things.

cosign supports using a KMS provider to generate and sign keys.Right now cosign supports Hashicorp Vault, AWS KMS, GCP KMS, Azure Key Vault and we are hoping to support more in the future!

See theKMS docs for more details.

Push an artifact to a registry usingoras (in this case,cosign itself!):

$ oras push us-central1-docker.pkg.dev/dlorenc-vmtest2/test/artifact ./cosignUploading f53604826795 cosignPushed us-central1-docker.pkg.dev/dlorenc-vmtest2/test/artifactDigest: sha256:551e6cce7ed2e5c914998f931b277bc879e675b74843e6f29bc17f3b5f692bef

Now sign it! Usingcosign of course:

$ cosign sign --key cosign.key us-central1-docker.pkg.dev/dlorenc-vmtest2/test/artifact@sha256:551e6cce7ed2e5c914998f931b277bc879e675b74843e6f29bc17f3b5f692befEnter passwordfor private key:Pushing signature to: us-central1-docker.pkg.dev/dlorenc-vmtest2/test/artifact:sha256-551e6cce7ed2e5c914998f931b277bc879e675b74843e6f29bc17f3b5f692bef.sig

Finally, verifycosign withcosign again:

$ cosign verify --key cosign.pub  us-central1-docker.pkg.dev/dlorenc-vmtest2/test/artifact@sha256:551e6cce7ed2e5c914998f931b277bc879e675b74843e6f29bc17f3b5f692befThe following checks were performed on each of these signatures:  - The cosign claims were validated  - The claims were presentin the transparency log  - The signatures were integrated into the transparency log when the certificate was valid  - The signatures were verified against the specified public key  - The code-signing certificate was verified using trusted certificate authority certificates{"Critical":{"Identity":{"docker-reference":""},"Image":{"Docker-manifest-digest":"sha256:551e6cce7ed2e5c914998f931b277bc879e675b74843e6f29bc17f3b5f692bef"},"Type":"cosign container image signature"},"Optional":null}

It's hard to answer this briefly.This post contains some comparisons:

Notary V2 and Cosign

If you find other comparison posts, please send a PR here and we'll link them all.

containers/image signing is close tocosign, and we reuse payload formats.cosign differs in that it signs with ECDSA-P256 keys instead of PGP, and storessignatures in the registry.

I believe this tool is complementary to TUF, and they can be used together.I haven't tried yet, but think we can also reuse a registry for TUF storage.

• No external services for signature storage, querying, or retrieval
• We aim for as much registry support as possible
• Everything should work over the registry API
• PGP should not be required at all.
• Users must be able to find all signatures for an image
• Signers can sign an image after push
• Multiple entities can sign an image
• Signing an image does not mutate the image
• Pure-go implementation

The naming convention and read-modify-write update patterns we use to store things ina registry are a bit, well, "hacky".I think they're the best (only) real option available today, but if the registry APIchanges we can improve these.

cosign can sign anything in a registry.These examples show signing a single image, but you could also sign a multi-platformIndex,or any other type of artifact.This includes Helm Charts, Tekton Pipelines, and anything else currently using OCI registriesfor distribution.

This also means new artifact types can be uploaded to a registry and signed.One interesting type to store and sign would be TUF repositories.I haven't tried yet, but I'm fairly certain TUF could be implemented on top of this.

cosign signatures protect the digests of objects stored in a registry.The optionalannotations support (via the-a flag tocosign sign) can be used to add extradata to the payload that is signed and protected by the signature.One use-case for this might be to sign a tag->digest mapping.

If you would like to attest that a specific tag (or set of tags) should point at a digest, you canrun something like:

$ docker push$IMAGE_URIThe push refers to repository [dlorenc/demo]994393dc58e7: Pushed5m: digest: sha256:1304f174557314a7ed9eddb4eab12fed12cb0cd9809e4c28f29af86979a3c870 size: 528$ TAG=sign-me$ cosign sign --key cosign.key -a tag=$TAG$IMAGE_URI_DIGESTEnter passwordfor private key:Pushing signature to: dlorenc/demo:1304f174557314a7ed9eddb4eab12fed12cb0cd9809e4c28f29af86979a3c870.sig

Then you can verify that the tag->digest mapping is also covered in the signature, using the-a flag tocosign verify.This example verifies that the digest$TAG which points to (sha256:1304f174557314a7ed9eddb4eab12fed12cb0cd9809e4c28f29af86979a3c870)has been signed,and also that thetag annotation has the valuesign-me:

$ cosign verify --key cosign.pub -a tag=$TAG$IMAGE_URI| jq.{"Critical": {"Identity": {"docker-reference":""    },"Image": {"Docker-manifest-digest":"97fc222cee7991b5b061d4d4afdb5f3428fcb0c9054e1690313786befa1e4e36"    },"Type":"cosign container image signature"  },"Optional": {"tag":"sign-me"  }}

Timestamps could also be added here, to implement TUF-style freeze-attack prevention.

Again,cosign can sign anything in a registry.You could usecosign to sign an image that is intended to be used as a base image,and include that provenance metadata in resulting derived images.This could be used to enforce that an image was built from an authorized base image.

Rough Idea:

• OCI manifests have an ordered list oflayerDescriptors, which can contain annotations.Seehere for thespecification.
• A base image is an ordered list of layers to which other layers are appended, as well as aninitial configuration object that is mutated.
  • A derived image is free to completely delete/destroy/recreate the config from its base image,so signing the config would provided limited value.
• We can sign the full set of ordered base layers, and attach that signature as an annotation tothelast layer in the resulting child image.

This example manifest manifest represents an image that has been built from a base image with twolayers.One additional layer is added, forming the final image.

{"schemaVersion":2,"config": {"mediaType":"application/vnd.oci.image.config.v1+json","size":7023,"digest":"sha256:b5b2b2c507a0944348e0303114d8d93aaaa081732b86451d9bce1f432a537bc7"  },"layers": [    {"mediaType":"application/vnd.oci.image.layer.v1.tar+gzip","size":32654,"digest":"sha256:9834876dcfb05cb167a5c24953eba58c4ac89b1adf57f28f2f9d09af107ee8f0"    },    {"mediaType":"application/vnd.oci.image.layer.v1.tar+gzip","size":16724,"digest":"sha256:3c3a4604a545cdc127456d94e421cd355bca5b528f4a9c1905b15da2eb4a4c6b","annotations": {"dev.cosign.signature.baseimage":"Ejy6ipGJjUzMDoQFePWixqPBYF0iSnIvpMWps3mlcYNSEcRRZelL7GzimKXaMjxfhy5bshNGvDT5QoUJ0tqUAg=="      }    },    {"mediaType":"application/vnd.oci.image.layer.v1.tar+gzip","size":73109,"digest":"sha256:ec4b8955958665577945c89419d1af06b5f7636b4ac3da7f12184802ad867736"    }  ],}

Note that this could be applied recursively, for multiple intermediate base images.

Cosign signatures (and their protected payloads) are stored as artifacts in a registry.These signature objects can also be signed, resulting in a new, "counter-signature" artifact.This "counter-signature" protects the signature (or set of signatures)and the referenced artifact, which allowsit to act as an attestation to thesignature(s) themselves.

Before we sign the signature artifact, we first give it a memorable name so we can find it later.

$ cosign sign --key cosign.key -a sig=original$IMAGE_URI_DIGESTEnter passwordfor private key:Pushing signature to: dlorenc/demo:sha256-97fc222cee7991b5b061d4d4afdb5f3428fcb0c9054e1690313786befa1e4e36.sig$ cosign verify --key cosign.pub dlorenc/demo| jq.{"Critical": {"Identity": {"docker-reference":""    },"Image": {"Docker-manifest-digest":"97fc222cee7991b5b061d4d4afdb5f3428fcb0c9054e1690313786befa1e4e36"    },"Type":"cosign container image signature"  },"Optional": {"sig":"original"  }}

Now give that signature a memorable name, then sign that:

$ crane tag$(cosign triangulate$IMAGE_URI) mysignature2021/02/15 20:22:55 dlorenc/demo:mysignature: digest: sha256:71f70e5d29bde87f988740665257c35b1c6f52dafa20fab4ba16b3b1f4c6ba0e size: 556$ cosign sign --key cosign.key -a sig=counter dlorenc/demo:mysignatureEnter passwordfor private key:Pushing signature to: dlorenc/demo:sha256-71f70e5d29bde87f988740665257c35b1c6f52dafa20fab4ba16b3b1f4c6ba0e.sig$ cosign verify --key cosign.pub dlorenc/demo:mysignature{"Critical":{"Identity":{"docker-reference":""},"Image":{"Docker-manifest-digest":"71f70e5d29bde87f988740665257c35b1c6f52dafa20fab4ba16b3b1f4c6ba0e"},"Type":"cosign container image signature"},"Optional":{"sig":"counter"}}

Finally, check the original signature:

$ crane manifest dlorenc/demo@sha256:71f70e5d29bde87f988740665257c35b1c6f52dafa20fab4ba16b3b1f4c6ba0e{"schemaVersion": 2,"config": {"mediaType":"application/vnd.oci.image.config.v1+json","size": 233,"digest":"sha256:3b25a088710d03f39be26629d22eb68cd277a01673b9cb461c4c24fbf8c81c89"  },"layers": [    {"mediaType":"application/vnd.oci.descriptor.v1+json","size": 217,"digest":"sha256:0e79a356609f038089088ec46fd95f4649d04de989487220b1a0adbcc63fadae","annotations": {"dev.sigstore.cosign/signature":"5uNZKEP9rm8zxAL0VVX7McMmyArzLqtxMTNPjPO2ns+5GJpBeXg+i9ILU+WjmGAKBCqiexTxzLC1/nkOzD4cDA=="      }    }  ]}

We cut releases as needed. Patch releases are cut to fix small bugs. Minor releases arecut periodically when there are multiple bugs fixed or features added. Major releaseswill be released when there are breaking features.

Should you discover any security issues, please refer to sigstore'ssecurityprocess

The GitHub release assets forcosign contain Sigstore bundle files produced byGoReleaser while signing the cosign blob that is used to verify the integrity of the release binaries. This file is not used by cosign itself, but is provided for users who wish toverify the integrity of the release binaries.