Container Signing

Related tags

Security cosign
Overview

cosign

Container Signing, Verification and Storage in an OCI registry.

Cosign aims to make signatures invisible infrastructure.

intro

Info

Cosign is developed as part of the sigstore project. Come on over to our slack channel!

Installation

For now, clone and go build -o cosign ./cmd. I'll publish releases when I'm comfortable supporting this for others to use.

Quick Start

This shows how to:

  • generate a keypair
  • sign a container image and store that signature in the registry
  • find signatures for a container image, and verify them against a public key

Generate a keypair

$ cosign generate-key-pair
Enter password for private key:
Enter again:
Private key written to cosign.key
Public key written to cosign.key

Sign a container and store the signature in the registry

$ cosign sign -key cosign.key us-central1-docker.pkg.dev/dlorenc-vmtest2/test/taskrun
Enter password for private key:
Pushing signature to: us-central1-docker.pkg.dev/dlorenc-vmtest2/test/taskrun:sha256-87ef60f558bad79beea6425a3b28989f01dd417164150ab3baab98dcbf04def8

Verify a container against a public key

This command returns 0 if at least one cosign formatted signature for the image is found matching 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 be sure these "detached" signatures cover the correct image.

$ cosign verify -key cosign.pub us-central1-docker.pkg.dev/dlorenc-vmtest2/test/taskrun
{"Critical":{"Identity":{"docker-reference":""},"Image":{"Docker-manifest-digest":"87ef60f558bad79beea6425a3b28989f01dd417164150ab3baab98dcbf04def8"},"Type":""},"Optional":null}

Detailed Usage

Sign a container multiple times

Multiple signatures can be "attached" to a single container image:

$ cosign sign -key cosign.key us-central1-docker.pkg.dev/dlorenc-vmtest2/test/taskrun
Enter password for private key:
Pushing signature to: us-central1-docker.pkg.dev/dlorenc-vmtest2/test/taskrun:sha256-87ef60f558bad79beea6425a3b28989f01dd417164150ab3baab98dcbf04def8

$ cosign sign -key other-cosign.key us-central1-docker.pkg.dev/dlorenc-vmtest2/test/taskrun
Enter password for private key:
Pushing signature to: us-central1-docker.pkg.dev/dlorenc-vmtest2/test/taskrun:sha256-87ef60f558bad79beea6425a3b28989f01dd417164150ab3baab98dcbf04def8

We only actually sign the digest, but you can pass by tag or digest:

$ cosign sign -key other-cosign.key us-central1-docker.pkg.dev/dlorenc-vmtest2/test/taskrun:v1
Enter password for private key:
Pushing signature to: us-central1-docker.pkg.dev/dlorenc-vmtest2/test/taskrun:sha256-87ef60f558bad79beea6425a3b28989f01dd417164150ab3baab98dcbf04def8

$ cosign sign -key other-cosign.key us-central1-docker.pkg.dev/dlorenc-vmtest2/test/taskrun:v1
Enter password for private key:
Pushing signature to: us-central1-docker.pkg.dev/dlorenc-vmtest2/test/taskrun:sha256-87ef60f558bad79beea6425a3b28989f01dd417164150ab3baab98dcbf04def8

The -a flag can be used to add annotations to the generated, signed payload. This flag can be repeated:

$ cosign sign -key cosign.key -a foo=bar -a baz=bat us-central1-docker.pkg.dev/dlorenc-vmtest2/test/taskrun:v1
Enter password for private key:
Pushing signature to: us-central1-docker.pkg.dev/dlorenc-vmtest2/test/taskrun:sha256-87ef60f558bad79beea6425a3b28989f01dd417164150ab3baab98dcbf04def8

These values are included in the signed payload under the Optional section. (More on this later):

"Optional":{"baz":"bat","foo":"bar"}

Sign and upload a generated payload (in another format, from another tool)

The payload must be specified as a path to a file:

$ cosign sign -key key.pem -payload payload.json us-central1-docker.pkg.dev/dlorenc-vmtest2/test/taskrun
Qr883oPOj0dj82PZ0d9mQ2lrdM0lbyLSXUkjt6ejrxtHxwe7bU6Gr27Sysgk1jagf1htO/gvkkg71oJiwWryCQ==
Using payload from: payload.json
Enter password for private key:
Pushing signature to: us-central1-docker.pkg.dev/dlorenc-vmtest2/test/taskrun:sha256-87ef60f558bad79beea6425a3b28989f01dd417164150ab3baab98dcbf04def8

Signatures are uploaded to an OCI artifact stored with a predictable name. This name can be located with the cosign triangulate command:

cosign triangulate gcr.io/dlorenc-vmtest2/demo
gcr.io/dlorenc-vmtest2/demo:sha256-97fc222cee7991b5b061d4d4afdb5f3428fcb0c9054e1690313786befa1e4e36.cosign

Sign but skip upload (to store somewhere else)

The base64 encoded signature is printed to stdout. This can be stored somewhere else.

$ cosign sign -key key.pem --upload=false us-central1-docker.pkg.dev/dlorenc-vmtest2/test/taskrun
Qr883oPOj0dj82PZ0d9mQ2lrdM0lbyLSXUkjt6ejrxtHxwe7bU6Gr27Sysgk1jagf1htO/gvkkg71oJiwWryCQ==

Generate the signature payload (to sign with another tool)

The json payload is printed to stdout:

$ cosign generate us-central1-docker.pkg.dev/dlorenc-vmtest2/test/taskrun
{"Critical":{"Identity":{"docker-reference":""},"Image":{"Docker-manifest-digest":"87ef60f558bad79beea6425a3b28989f01dd417164150ab3baab98dcbf04def8"},"Type":""},"Optional":null}

This can be piped directly into openssl:

$ cosign generate us-central1-docker.pkg.dev/dlorenc-vmtest2/test/taskrun | openssl...

Upload a generated signature

The signature is passed via the -signature flag. It can be a file:

$ cosign upload -signature file.sig us-central1-docker.pkg.dev/dlorenc-vmtest2/test/taskrun
Pushing signature to: us-central1-docker.pkg.dev/dlorenc-vmtest2/test/taskrun:sha256-87ef60f558bad79beea6425a3b28989f01dd417164150ab3baab98dcbf04def8

the base64-encoded signature:

$ cosign upload -signature Qr883oPOj0dj82PZ0d9mQ2lrdM0lbyLSXUkjt6ejrxtHxwe7bU6Gr27Sysgk1jagf1htO/gvkkg71oJiwWryCQ== us-central1-docker.pkg.dev/dlorenc-vmtest2/test/taskrun
Pushing signature to: us-central1-docker.pkg.dev/dlorenc-vmtest2/test/taskrun:sha256-87ef60f558bad79beea6425a3b28989f01dd417164150ab3baab98dcbf04def

or, - for stdin for chaining from other commands:

$ cosign generate us-central1-docker.pkg.dev/dlorenc-vmtest2/test/taskrun | openssl... | cosign upload -signature -- us-central1-docker.pkg.dev/dlorenc-vmtest2/test/taskrun
Pushing signature to: us-central1-docker.pkg.dev/dlorenc-vmtest2/test/taskrun:sha256-87ef60f558bad79beea6425a3b28989f01dd417164150ab3baab98dcbf04def

Verifying claims

Important Note:

Signature payloads created by cosign included the digest of the container image they are attached to. By default, cosign validates that this digest matches the container during cosign verify.

If you are using other payload formats with cosign, you can use the -check-claims=false flag:

$ cosign verify -check-claims=false -key public-key.pem us-central1-docker.pkg.dev/dlorenc-vmtest2/test/taskrun
Warning: the following claims have not been verified:
{"Critical":{"Identity":{"docker-reference":""},"Image":{"Docker-manifest-digest":"87ef60f558bad79beea6425a3b28989f01dd417164150ab3baab98dcbf04def8"},"Type":"cosign container signature"},"Optional":null}

This will still verify the signature and payload against the supplied public key, but will not verify any claims in the payload.

Annotations made in the original signature (cosign sign -a foo=bar) are present under the Optional section of the payload:

$ cosign verify -key cosign.pub  gcr.io/dlorenc-vmtest2/demo | jq .
{
  "Critical": {
    "Identity": {
      "docker-reference": ""
    },
    "Image": {
      "Docker-manifest-digest": "97fc222cee7991b5b061d4d4afdb5f3428fcb0c9054e1690313786befa1e4e36"
    },
    "Type": "cosign container signature"
  },
  "Optional": {
    "sig": "original"
  }
}

These can be checked with matching -a foo=bar flags on cosign verify. When using this flag, every specified key-value pair must exist and match in the verified payload. The payload may contain other key-value pairs.

# This works
$ cosign verify -a -key cosign.pub  gcr.io/dlorenc-vmtest2/demo
{"Critical":{"Identity":{"docker-reference":""},"Image":{"Docker-manifest-digest":"97fc222cee7991b5b061d4d4afdb5f3428fcb0c9054e1690313786befa1e4e36"},"Type":"cosign container signature"},"Optional":{"sig":"original"}}

# This works too
$ cosign verify -a sig=original -key cosign.pub  gcr.io/dlorenc-vmtest2/demo
{"Critical":{"Identity":{"docker-reference":""},"Image":{"Docker-manifest-digest":"97fc222cee7991b5b061d4d4afdb5f3428fcb0c9054e1690313786befa1e4e36"},"Type":"cosign container signature"},"Optional":{"sig":"original"}}

# This doesn't work
$ cosign verify -a sig=original -a=foo=bar -key cosign.pub  gcr.io/dlorenc-vmtest2/demo
error: no matching claims:
invalid or missing annotation in claim: map[sig:original]

Download the signatures to verify with another tool

Each signature is printed to stdout in a json format:

$ cosign download us-central1-docker.pkg.dev/dlorenc-vmtest2/test/taskrun
{"Base64Signature":"Ejy6ipGJjUzMDoQFePWixqPBYF0iSnIvpMWps3mlcYNSEcRRZelL7GzimKXaMjxfhy5bshNGvDT5QoUJ0tqUAg==","Payload":"eyJDcml0aWNhbCI6eyJJZGVudGl0eSI6eyJkb2NrZXItcmVmZXJlbmNlIjoiIn0sIkltYWdlIjp7IkRvY2tlci1tYW5pZmVzdC1kaWdlc3QiOiI4N2VmNjBmNTU4YmFkNzliZWVhNjQyNWEzYjI4OTg5ZjAxZGQ0MTcxNjQxNTBhYjNiYWFiOThkY2JmMDRkZWY4In0sIlR5cGUiOiIifSwiT3B0aW9uYWwiOm51bGx9"}

Rekor Support

Note: this is an experimental feature

To publish signed artifacts to a Rekor transparency log and verify their existence in the log, set the TLOG=1 environment variable.

TLOG=1 cosign sign -key cosign.key gcr.io/dlorenc-vmtest2/demo
TLOG=1 cosign verify -key cosign.pub gcr.io/dlorenc-vmtest2/demo

cosign defaults to using the public instance of rekor at api.rekor.dev. To configure the rekor server, set the REKOR_SERVER env variable.

Caveats

Intentionally Missing Features

cosign only generates ECDSA-P256 keys and uses SHA256 hashes. Keys are stored in PEM-encoded PKCS8 format. However, you can use cosign to store and retrieve signatures in any format, from any algorithm.

cosign does not handle key-distribution or PKI.

cosign does not handle expiry or revocation. See here for some discussion on the topic.

cosign does not handle public-key management or storage. There are no keyrings or local state.

Unintentionally Missing Features

cosign will integrate with transparency logs! See https://github.com/sigstore/cosign/issues/34 for more info.

cosign will integrate with even more transparency logs, and a PKI. See https://github.com/sigStore/fulcio for more info.

Registry Support

cosign uses go-containerregistry for registry interactions, which has excellent support, but other registries may have quirks.

Today, cosign has only been tested, barely, against GCP's Artifact Registry and Container Registry. We aim for wide registry support. Please help test! See https://github.com/sigstore/cosign/issues/40 for the tracking issue.

Things That Should Probably Change

Payload Formats

cosign only supports Red Hat's simple signing format for payloads. That looks like:

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

Note: This can be generated for an image reference using cosign generate <image>.

I'm happy to switch this format to something else if it makes sense. See [https://github.com/notaryproject/nv2/issues/40] for one option.

Registry Details

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

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

Signature Specification

cosign is inspired by tools like minisign and signify.

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 of ENCRYPTED COSIGN PRIVATE KEY:

-----BEGIN ENCRYPTED COSIGN PRIVATE KEY-----
...
-----END ENCRYPTED COSIGN PRIVATE KEY-----

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

-----BEGIN PUBLIC KEY-----
NqfC4CpZiE4OGpuYFSSMzXHJqXQ6u1W55prrZIjjZJ0=
-----END PUBLIC KEY-----

The inner (base64 encoded) data portion can be supplied directly on the command line without the PEM blocks:

$ cosign verify -key NqfC4CpZiE4OGpuYFSSMzXHJqXQ6u1W55prrZIjjZJ0= us-central1-docker.pkg.dev/dlorenc-vmtest2/test/taskrun

Storage Specification

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

reg.example.com/[email protected]:703218c0465075f4425e58fac086e09e1de5c340b12976ab9eb8ad26615c3715 has signatures located at reg.example.com/ubuntu:sha256-703218c0465075f4425e58fac086e09e1de5c340b12976ab9eb8ad26615c3715

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

See Race conditions for some caveats around this strategy.

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

Signing subjects

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

FAQ

Who is using this?

Hopefully no one yet. Stay tuned, though.

Why not use Notary v2

Why not use containers/image signing

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

Why not use TUF?

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.

Why not use Blockchain?

Just kidding. Nobody actually asked this. Don't be that person.

Why not use $FOO?

See the next section, Requirements. I designed this tool to meet a few specific requirements, and didn't find anything else that met all of these. If you're aware of another system that does meet these, please let me know!

Design Requirements

  • 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

Future Ideas

Registry API Changes

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

Other Types

cosign can sign anything in a registry. These examples show signing a single image, but you could also sign a multi-platform Index, or any other type of artifact. This includes Helm Charts, Tekton Pipelines, and anything else currently using OCI registries for 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.

Tag Signing

cosign signatures protect the digests of objects stored in a registry. The optional annotations support (via the -a flag to cosign sign) can be used to add extra data 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 can run something like:

$ TAG=sign-me
$ DGST=$(crane digest gcr.io/dlorenc-vmtest2/demo:$TAG)
$ cosign sign -key cosign.key -a tag=$TAG gcr.io/dlorenc-vmtest2/[email protected]$DGST
Enter password for private key:
Pushing signature to: gcr.io/dlorenc-vmtest2/demo:sha256-97fc222cee7991b5b061d4d4afdb5f3428fcb0c9054e1690313786befa1e4e36.cosign

Then you can verify that the tag->digest mapping is also covered in the signature, using the -a flag to cosign verify. This example verifes that the digest $TAG points to (sha256:97fc222cee7991b5b061d4d4afdb5f3428fcb0c9054e1690313786befa1e4e36) has been signed, and also that the $TAG:

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

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

Base Image/Layer Signing

Again, cosign can sign anything in a registry. You could use cosign to sign an image that is intended to be used as a base image, and inlcude 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 of layer Descriptors, which can contain annotations. See here for the specification.
  • A base image is an ordered list of layers to which other layers are appended, as well as an initial 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 to the last layer in the resulting child image.

This example manifest manifest represents an image that has been built from a base image with two layers. 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.

Counter-Signing

Cosign signatures (and their protected paylaods) 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 allows it to act as an attestation to the signature(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 gcr.io/dlorenc-vmtest2/demo
Enter password for private key:
Pushing signature to: gcr.io/dlorenc-vmtest2/demo:sha256-97fc222cee7991b5b061d4d4afdb5f3428fcb0c9054e1690313786befa1e4e36.cosign
$ cosign verify -key cosign.pub gcr.io/dlorenc-vmtest2/demo | jq .
{
  "Critical": {
    "Identity": {
      "docker-reference": ""
    },
    "Image": {
      "Docker-manifest-digest": "97fc222cee7991b5b061d4d4afdb5f3428fcb0c9054e1690313786befa1e4e36"
    },
    "Type": "cosign container signature"
  },
  "Optional": {
    "sig": "original"
  }
}

# Now give that signature a memorable name, then sign that
$ crane tag $(cosign triangulate gcr.io/dlorenc-vmtest2/demo) mysignature
2021/02/15 20:22:55 gcr.io/dlorenc-vmtest2/demo:mysignature: digest: sha256:71f70e5d29bde87f988740665257c35b1c6f52dafa20fab4ba16b3b1f4c6ba0e size: 556
$ cosign sign -key cosign.key -a sig=counter gcr.io/dlorenc-vmtest2/demo:mysignature
Enter password for private key:
Pushing signature to: gcr.io/dlorenc-vmtest2/demo:sha256-71f70e5d29bde87f988740665257c35b1c6f52dafa20fab4ba16b3b1f4c6ba0e.cosign
$ cosign verify -key cosign.pub gcr.io/dlorenc-vmtest2/demo:mysignature
{"Critical":{"Identity":{"docker-reference":""},"Image":{"Docker-manifest-digest":"71f70e5d29bde87f988740665257c35b1c6f52dafa20fab4ba16b3b1f4c6ba0e"},"Type":"cosign container signature"},"Optional":{"sig":"counter"}}

# Finally, check the original signature
$ crane manifest gcr.io/dlorenc-vmtest2/[email protected]:71f70e5d29bde87f988740665257c35b1c6f52dafa20fab4ba16b3b1f4c6ba0e
{
  "schemaVersion": 2,
  "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
  "config": {
    "mediaType": "application/vnd.docker.container.image.v1+json",
    "size": 233,
    "digest": "sha256:3b25a088710d03f39be26629d22eb68cd277a01673b9cb461c4c24fbf8c81c89"
  },
  "layers": [
    {
      "mediaType": "application/vnd.oci.descriptor.v1+json",
      "size": 217,
      "digest": "sha256:0e79a356609f038089088ec46fd95f4649d04de989487220b1a0adbcc63fadae",
      "annotations": {
        "dev.cosignproject.cosign/signature": "5uNZKEP9rm8zxAL0VVX7McMmyArzLqtxMTNPjPO2ns+5GJpBeXg+i9ILU+WjmGAKBCqiexTxzLC1/nkOzD4cDA=="
      }
    }
  ]
}
Issues
  • feat(ci): Add GoFish support

    feat(ci): Add GoFish support

    Signed-off-by: Engin Diri [email protected]

    Summary

    Hello cosign community and @cpanato,

    I added GoFish support via goreleasers (@caarlos0). The only things we need before merging this PR:

    A github repo called: fish-food similar to https://github.com/goreleaser/fish-food and and ensure access to it during the release process.

    owner: sigstore
    name: fish-food
    

    Ticket Link

    Fixes #855

    Release Note

    NONE

    
    
    opened by dirien 42
  • cosign for `git`

    cosign for `git`

    Description

    Today cosign is very oriented around OCI entities as both the thing being signed, as well as the medium for storing signatures, attestations, etc. While this is a pervasive medium for binaries, it doesn't capture another critical lifecycle stage: source, which has an even more pervasive medium: Git.

    🚨🚨 This conversation will be muddied by the existence of git commit -s, which solves one specific part of the problem, but hopefully I will motivate the ways this is insufficient here 🚨🚨

    git commit -s solves a very focused problem: authenticating commit authors (assuming publicly verifiable keys for that author). However, git commit -s encodes the signature into the Merkle DAG, which suffers similar problems with early container image signing efforts: it's presence changes the DAG, and post-facto attachment is impossible without changing the DAG. This is fine for the authentication use-case, but not for the breadth of use-cases cosign is pursuing.

    Let's look in particular at "attestations". Some of these (e.g. provenance) can be established at the point of authoring, but the vast majority of attestations will be attached post-facto, and often by a diverse set of authors. Some examples here would be:

    • "review" attestations: looking at compliance requirements and things like SLSA it is just as important to know who reviewed a change as who authored the change.
    • "validated" attestations: an example of a "robot" attestation would be the completion of various presubmit checks. You can think of this as a portable medium for encoding Github's "checks" or "commit status" information. This could include various levels of testing, style checking, or source-level vulnerability scanning.

    Fortunately, (unlike OCI) Git already has an established medium for attaching metadata to commits called git notes:

    Commit notes are blobs containing extra information about an object (usually information to supplement a commit’s message). These blobs are taken from notes refs. A notes ref is usually a branch which contains "files" whose paths are the object names for the objects they describe, with some directory separators included for performance reasons

    You can even see that the examples of how to use these encompass some of the use cases above:

    git show -s 72a144e
    [...]
        Signed-off-by: Junio C Hamano <[email protected]>
    
    Notes:
        Tested-by: Johannes Sixt <[email protected]>
    

    I would be remiss at this point if I did not h/t git-appraise and @ojarjur who taught me about Git notes! This project touches on the other use case I mention above: reviews (although more for content than attestation).


    So what am I actually proposing?

    I think that it would be interesting to start thinking about a pkg/git to match pkg/oci which enables us to use cosign to sign and attest to things using git notes post-facto. e.g. passing a remote/refspec to:

    COSIGN_EXPERIMENTAL=1 cosign attest --predicate <FILE> --type <TYPE> <REMOTE/REFSPEC>
    
    enhancement 
    opened by mattmoor 27
  • Does webhook pull images for the sidecar and/ or multiple image repos

    Does webhook pull images for the sidecar and/ or multiple image repos

    I have images deployed from multiple source in one cluster+namespace. For example I have three images:

    As you may notice I have control over first two images so I can put them in one repo and deploy. But I have no control over the third image as it is knative image. Will webhook allow all three images to be deployed? If yes, how? What config changes need to be made?

    question 
    opened by adubey8 26
  • Registry Support

    Registry Support

    Our primary goal is broad registry support. Right now we're unsure of where we are:

    • GCR (tested, mostly works)
    • Google Artifact Registry (works)
    • Quay - works in latest version, not in hosted service yet
    • Dockerhub?
    • Azure Container Registry?
    • Amazon Container Registry?
    • Others?

    We have some options we can try to increase support, but they're kind of ugly. I'd first like to understand how much support we have vs. how much we would gain by doing terrible things with media types.

    cc @jonjohnsonjr @font (slack here: https://github.com/google/go-containerregistry/blob/93228a70849651ba98cdee6f0654f623d7cdcbdb/pkg/v1/manifest.go#L27)

    pathfinding 
    opened by dlorenc 26
  • implement a new flag for sign-blob subcommand to save certificate to disk or stdout

    implement a new flag for sign-blob subcommand to save certificate to disk or stdout

    Summary

    With cosign 1.3.0 it is not possible to store the public certificate generated by the OIDC-issuer in a convenient way. To store the public key locally on disk, the user has to intercept the cosign stdout, parse it and store it. This is inconvenient and error-prone. We want to make signing and public key distribution as easy as possible, hence this PR introduces a new pubkey-output flag for the sign-blob sub-command.

    The pubkey-output flag respects the b64 flag and prints the certificate/key as file in a given file path.

    Ticket Link

    Fixes None

    Release Note

    The cosign cli is now able to store the public certificate/key during sign-blob operations via the `pubkey-output` flag.
    
    opened by shibumi 25
  • Determine attestation format for vuln scans

    Determine attestation format for vuln scans

    Description

    From a slack conversation with @developer-guy @Dentrax and @joshuagl, capturing it here so I don't forget!

    We've already discussed support for signing/verifying/storing attestations, using the In-Toto model: https://github.com/in-toto/attestation, and @developer-guy brought up a common use case around storing vulnerability scan reports for an image in the registry.

    Storing scans is slightly problematic in that the scan results are timely, a scan with no vulnerabilities a month ago doesn't mean that the image has no know vulnerabilities today. Rather than storing scan results directly, we can convert them into an attestation, by adding a timestamp and a signer.

    Rather than saying "this has no vulnerabilties", the statement becomes "this had no vulnerabilities as of $TIME, as seen by $SIGNER". Then the $SIGNER signs this, making it a formal attestation.

    Policy engines can then rely on these, and policies can be written in the form of "there must be a clean scan report within the last X days".

    I think to implement all of this in cosign, we would do something like:

    • define a new provenance predicate either here in cosign or in the in-toto repo to convey a timestamped scan report.
    • add some cosign commands:

    cosign sign-attestation -f <attestation> cosign attach attestation -f <attestation> <img>

    We can still use all of the KMS/key/ephemeral support for signing - but these are slightly different from the rest of what cosign works with, as the attestation itself is signed, not the OCI image wrapper. The scan report would be generated and timestamped, then cosign would sign the file locally (similar to sign-blob). Then the signed blob can get attached to an image.

    Does this all make sense?

    opened by dlorenc 23
  • `cosign` as a library

    `cosign` as a library

    Description

    tl;dr I propose the creation of a well-curated set of libraries for signing, that compose extremely well with and complement github.com/google/go-containerregistry for signing OCI images and indices.

    cosign has gained considerable traction as a mechanism for signing OCI artifacts as a standalone executable. I believe that to kick this into an even higher-gear, we want to encourage ecosystem tooling to natively integrate cosign as a library to naturally extend image production to include signing.

    cosign (along with a growing list of other tooling) builds around github.com/google/go-containerregistry (aka "GGCR") for interacting with OCI images and indices, so this isn't a huge reach, it is mostly refactoring the code we have today to better align with the way we do things in GGCR so that it is trivially simple for folks to adopt signing, if they've adopted GGCR.


    One of the directions I'd like to see us push the library portion of this is to align with the "philosophy" of GGCR, in part to enable a wider variety of use cases.

    For example, today cosign is very oriented around registry-based images. Despite it's name GGCR actually allows interacting with images in a wide variety of formats, including things like docker save-tarballs, OCI-layouts, and more.

    If cosign were to adhere to some of the principles of GGCR, we might see signing take the form of (v1.Image, Options) -> v1.Image, where the input image is what we want signed and the output image is the signature payload we want recorded somewhere.

    With this separation of the signing from the storage, consumers can then leverage a variety of mechanisms to publish the resulting image in different ways. They can choose to remote.Write that image to a registry following cosign's naming convention, or they can tarball.Write.


    GGCR is all about enabling cool new things thru composition, and so this is very much about making sure cosign becomes a tool compatible with that ecosystem of composition!

    I am still wrapping my head around everything that cosign does, so this picture is starting to form in my head, but if folks are receptive to this (or better willing to help) then I'd love to discuss this direction.

    cc @jonjohnsonjr @imjasonh @dekkagaijin @dlorenc

    opened by mattmoor 20
  • Cosign with AWS ECR

    Cosign with AWS ECR

    We are working on configuring Docker trust using cosign with AWS ECR. I am able to sign Docker image but getting the below error while running a Docker. Error: remote trust data does not exist for does not have trust data for awsaccno.dkr.ecr.us-west-2.amazonaws.com/testapp Please let me know if I missed anything,

    question 
    opened by mkinage 19
  • Tracking Issue: Deployment Policy

    Tracking Issue: Deployment Policy

    This probably wouldn't live here in this repo, but it's the best spot to open the issue for now.

    We should integrate with and document how to use sigstore/cosign signatures to enforce policy at deployment time. I'd really rather avoid making our own admission controller if we can avoid it, but if we do have to for POC or demo purposes I vote we call it "cosigned" :)

    Some existing ones we could try to integrate with:

    https://siegert-maximilian.medium.com/ensure-content-trust-on-kubernetes-using-notary-and-open-policy-agent-485ab3a9423c https://github.com/sse-secure-systems/connaisseur https://github.com/IBM/portieris https://kubernetes.io/blog/2019/08/06/opa-gatekeeper-policy-and-governance-for-kubernetes/ https://github.com/grafeas/kritis

    I'm sure there are more! Add them to the issue and I'll merge into this list :)

    Thanks to https://twitter.com/developerguyba for all the pointers :)

    opened by dlorenc 18
  • cosigned: create a CRD to declare signed image policies per cluster

    cosigned: create a CRD to declare signed image policies per cluster

    Description

    The idea is to create a cluster-scoped CR to specify a signed image policy on their kubernetes cluster. This policy can be configured to verify signed images from specified patterns.

    Based on our implementation of a similar admission controller, we expose a CR with several fields:

    publicKeys: defines the list of valid public keys. registries: defines the link between registries and defined keys where to apply these rules. unmatchedImagePolicy: specifies the behavior of the admission controller (Allow|Deny) whenever the policy is satisfied or not.

    An example of a Policy:

    kind: ClusterImagePolicy
    metadata:
     name: image-policy
    spec:
     unmatchedImagePolicy: <Allow/Deny>
     publicKeys:
     - name: cosign-key-1
       publicKey: <public-key>
     registries:
     - pattern: my.registry.org/library/*
       keys:
       - name: cosign-key-1
    

    I cc @stormqueen1990 and @kkavitha @elfotografo007 as creators of this approach. So they can chime in here.

    opened by hectorj2f 17
  • Local Cert verify not working for Azure KMS

    Local Cert verify not working for Azure KMS

    Description

    Using cosign with Azure KMS results in different behavior for validation with KMS and local pub cert.

    cosign verify -key azurekms://keyvault-xyz.vault.azure.net/cosign registryXYZ.azurecr.io/example-func:1.0.0
    using embedded fulcio certificate. did you run `cosign init`? error retrieving target:  missing target metadata: tuf: no root keys found in local meta store
    
    Verification for registryXYZ.azurecr.io/example-func:1.0.0 --
    The following checks were performed on each of these signatures:
      - The cosign claims were validated
      - The signatures were verified against the specified public key
      - Any certificates were verified against the Fulcio roots.
    
    [{"critical":{"identity":{"docker-reference":"registryXYZ.azurecr.io/example-func"},"image":{"docker-manifest-digest":"sha256:e231349fdf394a570e0cb84fe5109bc6980f52b84dd219fcae9922922a715d7d"},"type":"cosign container image signature"},"optional":{"tag":"1.0.0"}},{"critical":{"identity":{"docker-reference":"registryXYZ.azurecr.io/example-func"},"image":{"docker-manifest-digest":"sha256:e231349fdf394a570e0cb84fe5109bc6980f52b84dd219fcae9922922a715d7d"},"type":"cosign container image signature"},"optional":null}]
    

    But when I use the created public certificate, the result is as follows:

    cosign verify -key cosign.pub registryXYZ.azurecr.io/example-func:1.0.0
    using embedded fulcio certificate. did you run `cosign init`? error retrieving target:  missing target metadata: tuf: no root keys found in local meta store
    error: no matching signatures:
    failed to verify signature
     failed to verify signature
    

    I also exported the key again and tried to reproduce, with the same result:

    cosign public-key -key azurekms://ckeyvaultXYZ.azure.net/cosign > cosign-new.pub
    cosign verify -key cosign-new.pub registryXYZ.azurecr.io/example-func:1.0.0
    using embedded fulcio certificate. did you run `cosign init`? error retrieving target:  missing target metadata: tuf: no root keys found in local meta store
    error: no matching signatures:
    failed to verify signature
     failed to verify signature
    

    Is there anything I did wrong or is there a bug in the verification? Earlier I added also some comments to #399, when the feature was still under active development.

    cosign version
    GitVersion:    v1.1.0
    GitCommit:     67934a685ddc83aa7b0b8a55c911e299117afac5
    GitTreeState:  clean
    BuildDate:     '2021-08-25T21:51:14Z'
    GoVersion:     go1.17
    Compiler:      gc
    Platform:      darwin/arm64
    
    opened by containerpope 16
  • Why is an SBOM attestation predicate wrapped in CosignPredicate?

    Why is an SBOM attestation predicate wrapped in CosignPredicate?

    Question

    When Cosign creates an SBOM attestation, the SBOM predicate is wrapped in CosignPredicate. (spdx, cyclonedx) Therefore, SBOM locates under predicate.Data.

    The photo below is an example of spdx. sbom_attestation

    This differs from the in-toto spdx specification. It defines that the SBOM is located under the predicate.

    {
      // Standard attestation fields:
      "_type": "https://in-toto.io/Statement/v0.1",
      "subject": [{ ... }],
    
      // Predicate:
      "predicateType": "https://spdx.dev/Document",
      "predicate": {
        "SPDXID" : "SPDXRef-DOCUMENT",
        "spdxVersion" : "SPDX-2.2",
        ...
      }
    }
    

    This difference makes it difficult to tell whether the SBOM is in predicate or predicate.Data, when we get an SBOM attestation.

    So, why is an SBOM attestation predicate wrapped in CosignPredicate?

    question 
    opened by otms61 0
  • inclusion proof failure: wrong proof size 11, want 12

    inclusion proof failure: wrong proof size 11, want 12

    As part of our SLSA native GitHub verifier https://github.com/slsa-framework/slsa-verifier, we intermittently see the following error in our e2e tests:

    https://github.com/slsa-framework/slsa-verifier/blob/8c4373c533dfa2d9ec74ec042a12811a75c205de/pkg/rekor.go#L176-L179

    validating log entry: verifying inclusion proof: wrong proof size 11, want 12
    

    We have seen this error happen every once in a while. Are we doing something wrong in the code? How can we troubleshoot the problem?

    If nothing is wrong in our code, this is something that will need to be fixed before GA... but it's hard to reproduce.

    Any thoughts?

    /cc @asraa @ianlewis

    bug 
    opened by laurentsimon 7
  • failure to get Fulcio root

    failure to get Fulcio root

    As part of the native SLSA builders for GitHub https://github.com/slsa-framework/slsa-github-generator, we use cosign API to verify binaries. Recently users who user the builder to release their binaries have encountered problems:

    goroutine 1 [running]:
    github.com/sigstore/cosign/cmd/cosign/cli/fulcio/fulcioroots.Get.func1()
    	github.com/sigstore/[email protected]/cmd/cosign/cli/fulcio/fulcioroots/fulcioroots.go:48 +0x57
    sync.(*Once).doSlow(0xc000be3b30?, 0xc0008de700?)
    	sync/once.go:68 +0xc2
    sync.(*Once).Do(...)
    	sync/once.go:59
    github.com/sigstore/cosign/cmd/cosign/cli/fulcio/fulcioroots.Get()
    	github.com/sigstore/[email protected]/cmd/cosign/cli/fulcio/fulcioroots/fulcioroots.go:[44](https://github.com/ossf/scorecard/runs/7638656220?check_suite_focus=true#step:4:45) +0x31
    github.com/sigstore/cosign/cmd/cosign/cli/fulcio.GetRoots(...)
    	github.com/sigstore/[email protected]/cmd/cosign/cli/fulcio/fulcio.go:157
    

    The builder version is v1.0.0 from 2 months ago, and uses [email protected] We have a more recent builder version, but not all users update promptly.

    Is there a way to fix this?

    /cc @asraa @ianlewis

    bug 
    opened by laurentsimon 3
  • fix: adds envelope hash to in-toto entries in tlog entry creation

    fix: adds envelope hash to in-toto entries in tlog entry creation

    Signed-off-by: Noah Kreiger [email protected]

    Summary

    By not using the types.NewProposedEntry the in-toto rekor function was not assiging the hash key, which caused a downstream error when querying by the hash to find the log entry after it was added, making it appear as if it did not get added.

    This fix will add the envelope hash to in-toto entries during tlog entry creation that will allow the entries to be queried by the hash downstream.

    Release Note

    • Bugfix adds envelope hash to in-toto entries in tlog entry creation
    opened by nkreiger 16
  • Remove dependency on github.com/golang/glog

    Remove dependency on github.com/golang/glog

    Please see https://github.com/sigstore/policy-controller/pull/112 for more context.

    TLDR - without this being removed, policy-controller will crash on startup due to conflicts with the klog dependency.

    This appears to be brought in via github.com/google/certificate-transparency-go. After looking there, it led to a rabbit hole of other dependencies which also rely on glog.

    I've opened up the following PRs which may or may not be all of the locations:

    • https://github.com/google/certificate-transparency-go/pull/962
    • https://github.com/google/trillian/pull/2787
    • https://github.com/google/go-licenses/pull/138
    • https://github.com/grpc/grpc-go/pull/5547

    An alternative could be for the sigstore org to maintain a fork of glog, just for replace purposes. The required changeset would be this.

    bug 
    opened by jdolitsky 1
  • Cosign with goreleaser fail with error: Bad Request PKCE S256 is required

    Cosign with goreleaser fail with error: Bad Request PKCE S256 is required

    git fork repo https://github.com/goreleaser/supply-chain-example.git

    run following command:

    goreleaser release --snapshot --rm-dist
    

    When I try to login via GitHub getting following error Bad Request PKCE S256 is required.

    image
      • calculating checksums
      • signing artifacts
        • refreshing checksums                           file=checksums.txt
        • signing                                        artifact=checksums.txt certificate=dist/checksums.txt.pem cmd=cosign signature=dist/checksums.txt.sig
        • Using payload from: dist/checksums.txt         artifact=checksums.txt certificate=dist/checksums.txt.pem cmd=cosign signature=dist/checksums.txt.sig
        • Generating ephemeral keys...                   artifact=checksums.txt certificate=dist/checksums.txt.pem cmd=cosign signature=dist/checksums.txt.sig
        • Retrieving signed certificate...               artifact=checksums.txt certificate=dist/checksums.txt.pem cmd=cosign signature=dist/checksums.txt.sig
        •                                                artifact=checksums.txt certificate=dist/checksums.txt.pem cmd=cosign signature=dist/checksums.txt.sig
        •         Note that there may be personally identifiable information associated with this signed artifact. artifact=checksums.txt certificate=dist/checksums.txt.pem cmd=cosign signature=dist/checksums.txt.sig
        •         This may include the email address associated with the account with which you authenticate. artifact=checksums.txt certificate=dist/checksums.txt.pem cmd=cosign signature=dist/checksums.txt.sig
        •         This information will be used for signing this artifact and will be stored in public transparency logs and cannot be removed later. artifact=checksums.txt certificate=dist/checksums.txt.pem cmd=cosign signature=dist/checksums.txt.sig
        • Non-interactive mode detected, using device flow. artifact=checksums.txt certificate=dist/checksums.txt.pem cmd=cosign signature=dist/checksums.txt.sig
        • Enter the verification code AAAA-AAAA in your browser at: https://oauth2.sigstore.dev/auth/device?user_code=AAAA-AAAA artifact=checksums.txt certificate=dist/checksums.txt.pem cmd=cosign signature=dist/checksums.txt.sig
        • Code will be valid for 300 seconds             artifact=checksums.txt certificate=dist/checksums.txt.pem cmd=cosign signature=dist/checksums.txt.sig
    ^C    ⨯ release failed after 34s               error=received: interrupt
    
    
    bug 
    opened by xmlking 0
Releases(v1.10.0)
Owner
sigstore
Software supply chain transparency
sigstore
Implementations of the Coconut signing scheme, cross-compatible between Rust and Go.

Coconut Coconut [paper] is a distributed cryptographic signing scheme providing a high degree of privacy for its users. You can find an overview of ho

Nym 20 Jul 24, 2022
A RSA signing server model, allows to create valid signed certificates that cant be modified

Omega Description a RSA signing server model, allows to create valid signed certificates that cant be modified Requirements MySQL Server GoLang 1.17 I

null 0 Nov 15, 2021
DockerSlim (docker-slim): Don't change anything in your Docker container image and minify it by up to 30x (and for compiled languages even more) making it secure too! (free and open source)

Minify and Secure Docker containers (free and open source!) Don't change anything in your Docker container image and minify it by up to 30x making it

docker-slim 14.7k Aug 8, 2022
Find secrets and passwords in container images and file systems

Find secrets and passwords in container images and file systems

null 1.4k Aug 4, 2022
Agent-less vulnerability scanner for Linux, FreeBSD, Container, WordPress, Programming language libraries, Network devices

Vuls: VULnerability Scanner Vulnerability scanner for Linux/FreeBSD, agent-less, written in Go. We have a slack team. Join slack team Twitter: @vuls_e

Future Corp 9.4k Aug 6, 2022
SingularityCE is the Community Edition of Singularity, an open source container platform designed to be simple, fast, and secure.

SingularityCE Guidelines for Contributing Pull Request Template Project License Documentation Support Citation SingularityCE is the Community Edition

Sylabs Inc. 290 Jul 29, 2022
WIP. Converts Azure Container Scan Action output to SARIF, for an easier integration with GitHub Code Scanning

container-scan-to-sarif container-scan-to-sarif converts Azure Container Scan Action output to Static Analysis Results Interchange Format (SARIF), for

Armel Soro 2 Jan 25, 2022
A vulnerability scanner for container images and filesystems

A vulnerability scanner for container images and filesystems

Anchore, Inc. 4.3k Aug 6, 2022
Simple container orchestration

Metis Super simple orchestration for stateless HTTP containers. This is a personal project I developed in an attempt to understand how a container orc

Oisín Aylward 2 Dec 3, 2021
A vulnerability scanner for container images and filesystems

A vulnerability scanner for container images and filesystems. Easily install the

null 0 Dec 24, 2021
Ssh-lxd - A proof of concept for an ssh server that spawns a bash session inside a LXD container

SSH LXD A proof of concept for an ssh server that spawns a bash session inside a

Henning Dahlheim 2 Jan 14, 2022
Build & Scan - Container Image

BSImage (build&scan image) Requirements Trivy Docker BSImage (shell script version) Usage of build (shell script version) ./bsimage.sh start <image:ta

Carlos Eduardo Vieira 1 Apr 12, 2022
Prototype of signing container images in the index

Prototype for inline signing of images in the image index. When designing Notary v2 there was a strong consensus for having detached signatures. These

Justin Cormack 2 Jan 8, 2022
Moby Project - a collaborative project for the container ecosystem to assemble container-based systems

The Moby Project Moby is an open-source project created by Docker to enable and accelerate software containerization. It provides a "Lego set" of tool

Moby 63.7k Aug 4, 2022
Yeqllo 22 Nov 26, 2021
Moby Project - a collaborative project for the container ecosystem to assemble container-based systems

The Moby Project Moby is an open-source project created by Docker to enable and accelerate software containerization. It provides a "Lego set" of tool

Moby 63.7k Aug 4, 2022
top in container - Running the original top command in a container

Running the original top command in a container will not get information of the container, many metrics like uptime, users, load average, tasks, cpu, memory, are about the host in fact. topic(top in container) will retrieve those metrics from container instead, and shows the status of the container, not the host.

silenceshell 69 Jun 20, 2022
Boxygen is a container as code framework that allows you to build container images from code

Boxygen is a container as code framework that allows you to build container images from code, allowing integration of container image builds into other tooling such as servers or CLI tooling.

nitric 5 Dec 13, 2021
Amazon ECS Container Agent: a component of Amazon Elastic Container Service

Amazon ECS Container Agent The Amazon ECS Container Agent is a component of Amazon Elastic Container Service (Amazon ECS) and is responsible for manag

null 0 Dec 28, 2021
The Container Storage Interface (CSI) Driver for Fortress Block Storage This driver allows you to use Fortress Block Storage with your container orchestrator

fortress-csi The Container Storage Interface (CSI) Driver for Fortress Block Storage This driver allows you to use Fortress Block Storage with your co

Fortress 0 Jan 23, 2022
Ixia-c-one - A re-packaged (as a single-container) flavor of multi-container application ixia-c

ixia-c-one ixia-c-one is a re-packaged (as a single-container) flavor of multi-c

Open Traffic Generator 3 Apr 1, 2022
A tool for testing, building, signing, and publishing binaries.

gomason Tool for testing, building, signing and publishing binaries. Think of it as an on premesis CI/CD system- that also performs code signing and p

Nik Ogura 53 Apr 7, 2022
Simple no frills AWS S3 Golang Library using REST with V4 Signing (without AWS Go SDK)

simples3 : Simple no frills AWS S3 Library using REST with V4 Signing Overview SimpleS3 is a golang library for uploading and deleting objects on S3 b

Rohan Verma 89 Jul 31, 2022
Signing prototype

sigstore signing CLI tool ⚠️ Not ready for use yet! sigstore CLI is a generic tool to sign blobs, tarballs etc and establish a trust root using the si

sigstore 290 Jul 28, 2022
Work with remote images registries - retrieving information, images, signing content

skopeo skopeo is a command line utility that performs various operations on container images and image repositories. skopeo does not require the user

Containers 5k Aug 8, 2022
A CLI tool for leveraging IDP signing keys to impersonate users and groups

Imperson8 Disclaimer This is a security testing tool. Only use this on systems you have explicit authorization to test. This isn't an exploit and won'

null 17 Jul 23, 2022
Extended ssh-agent which supports git commit signing over ssh

ssh-agentx ssh-agentx Rationale Requirements Configuration ssh-agentx Configuration ssh-gpg-signer Linux Windows Signing commits after configuration T

Wim 10 Jun 29, 2022
kubectl plugin for signing Kubernetes manifest YAML files with sigstore

k8s-manifest-sigstore kubectl plugin for signing Kubernetes manifest YAML files with sigstore ⚠️ Still under developement, not ready for production us

sigstore 37 Jul 1, 2022
gon is a simple, no-frills tool for signing and notarizing your CLI binaries for macOS

Sign, notarize, and package macOS CLI tools and applications written in any language. Available as both a CLI and a Go library.

Mitchell Hashimoto 1.2k Aug 1, 2022