Introducing Gitsign

Sigstore aims to protect software supply chains by providing tools to make signing easy and transparent. So far, Sigstore has released components such as Fulcio — a certificate authority for issuing signing certificates using OIDC credentials, Rekor — a transparency log for recording supply chain metadata in a tamper-proof ledger, and Cosign — a CLI tool that makes container and blob signing simple.

But securing software supply chains means more than just signing containers! Ideally, every step in our release pipeline should be signed — from the artifacts we produce tracing back all the way to the source they originated from.

To help support this goal, the Sigstore project has created a new tool called Gitsign! With Gitsign, we aim to bring the best of Sigstore to Git with “keyless” signing and transparency log support — making it easy to get started with signing without the need to generate and manage long-term keys.

Photo by Signature Pro on Unsplash

A brief history of Git commit signing

Signing Git commits is not a new concept: Git has supported GPG based signing for years, and more recently has even added support for SSH keys and x509 certificates! However, these approaches suffer from the same problems as container signing as key creation and management makes it hard to get started and adds yet another secret to protect.

That made us think: what if we could apply the same ideas that made Cosign so popular to other tools like Git?

In the early days of Cosign, we imagined what it would look like to sign Git commits with ephemeral keys to give a “keyless” experience, but this wasn’t perfect. Signing this way relied on storing signatures either completely outside the repository or in a different reference space that was not typically used for signing commits and tags. While this approach is still useful for storing additional metadata related to commits, it doesn’t hook into existing Git signature verification flows.

However, Git itself allows for customizing the tools that are used to sign, letting you hook into the Git commit lifecycle to provide custom signing behavior! With this, we were able to write our own tool to bridge this gap to bring Git and Sigstore together.

How to get started with Gitsign

Getting started with Gitsign only requires a few short steps as a one-time setup:

$ go install github.com/sigstore/gitsign@latest  # Install Gitsign
$ git config --global gpg.format x509  # Use Gitsign for signing
$ git config --global gpg.x509.program gitsign
$ git config --global commit.gpgsign true  # Sign all commits

For more installation options check out our installation docs.

From there, signing and verifying commits is as easy as:

$ git commit --message="Signed commit"
[main ca682d9] Signed commit
$ git verify-commit HEAD
tlog index: 123456
smimesign: Signature made using certificate ID 0x6f66f1a03875d7b1cefc4e5ddae7c365178eb015 | CN=sigstore,O=sigstore.dev
smimesign: Good signature from [alice@example.com]
Parsed Git signature: true
Validated Git signature: true
Located Rekor entry: true
Validated Rekor entry: true

Gitsign leverages the same ephemeral certificate flow as Cosign, utilizing user OIDC credentials (either through OAuth or an existing OIDC environment like GCP Workload Identity or GitHub Actions) to authenticate and tie user identities to signatures. That means with Gitsign you can use your existing GitHub account to sign commits (and other providers coming soon)! Commits that are signed are added to the Rekor transparency log, ensuring that signatures can be verified even after the certificate has expired, and allowing you to search the transparency log by the specific commit hash!

Gitsign is another example of how Sigstore tooling can help secure your code and deployments, and we’d love for you to get involved! The Gitsign project can be found at https://github.com/sigstore/gitsign, and be sure to join the #gitsign channel on the Sigstore community slack to interact with the community!

Happy (git)signing!