A GPG key for commit signing comes with its own problem. You have to generate it, back it up, keep it available on every machine, and eventually rotate it before it expires or gets compromised. Sigstore gitsign replaces the long-lived key with a short-lived certificate that you get fresh through an OIDC login every time you sign. How the Rekor transparency log works in the background, which records every signing operation, is already covered in detail in “Merkle-Trees und Transparenz-Logs” (in German, digital-business.blog, July 8) and “Signierte Commits und Artefakte” (in German, digital-business.blog, June 17). You may already know the principle from the article “Container-Images signieren mit cosign” (in German, June 24) on this blog. cosign signs artifacts and images keyless through the same Fulcio/Rekor infrastructure, and gitsign carries the same principle over to Git commits. This article covers only the practical side: switching Git over, signing your first commit, and verifying the signature locally and in CI.

Prerequisites

You need Git, a browser for the first interactive login, and an account with one of the OIDC providers supported by Sigstore (GitHub, Google or Microsoft work through the public Sigstore instance).

Step 1: Install gitsign

Via Homebrew:

brew install gitsign

Or via Go:

go install github.com/sigstore/gitsign@latest

Step 2: Switch Git to gitsign

For a single repository:

git config --local gpg.x509.program gitsign
git config --local gpg.format x509
git config --local commit.gpgsign true
git config --local tag.gpgsign true

For all repositories on the machine, replace –local with –global. The gitsign docs explicitly point out that commit.gpgsign true makes every git commit depend on a working internet connection, because signing needs the OIDC flow and the Rekor entry. If you work offline, leave commit.gpgsign off and sign selectively with git commit -S.

Step 3: Sign your first commit keyless

A plain git commit is enough now:

git commit --allow-empty --message="Signed commit"

On the first run, your browser opens with a URL under oauth2.sigstore.dev. You sign in with your GitHub, Google or Microsoft account, and Sigstore Fulcio then issues a short-lived signing certificate. In the example from the gitsign docs, the validity between notBefore and notAfter is about ten minutes, so long after signing the certificate is no longer valid. The commit is recorded automatically in the public Rekor log, which is the part explained in the articles linked above.

You sign tags the same way, with git tag -s or tag.gpgsign true.

Step 4: Verify the signature locally

On a fresh machine or a CI runner, it is worth running this once first:

gitsign initialize

This downloads the Sigstore trust root for certificate validation, instead of fetching it again on every single verify. After that:

gitsign verify \
  --certificate-identity=you@example.com \
  --certificate-oidc-issuer=https://accounts.google.com \
  HEAD

–certificate-identity and –certificate-oidc-issuer together check that the commit is not only cryptographically intact, but was signed by exactly the expected identity through exactly the expected provider. The output shows, among other things, Validated Git signature: true, Validated Rekor entry: true and Validated Certificate claims: true. That is why gitsign verify is preferable to the built-in git verify-commit. Git itself only checks the cryptographic integrity and that the Rekor entry exists, not who created it.

For tags, the matching command is gitsign verify-tag.

Step 5: gitsign verify in the CI pipeline

On every pull request, the pipeline should check that all new commits are signed by expected identities. A GitHub Actions job for that:

name: verify-commit-signatures
on:
  pull_request:
jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Install gitsign
        run: go install github.com/sigstore/gitsign@latest
      - name: Initialize trust root
        run: gitsign initialize
      - name: Verify commit signatures
        run: |
          for sha in $(git rev-list origin/${{ github.base_ref }}..HEAD); do
            gitsign verify \
              --certificate-identity-regexp="@your-domain\.com$" \
              --certificate-oidc-issuer-regexp="https://(accounts\.google\.com|github\.com/login/oauth)" \
              "$sha"
          done

–certificate-identity-regexp and –certificate-oidc-issuer-regexp are the regex variants of the two flags from step 4, so you do not have to write a separate call for every person on the team. If the loop finds a commit that does not match, gitsign verify exits with an error and the job turns red.

Alternatively, there are ready-made community actions such as gitsign-verify in the GitHub Marketplace that wrap the same loop. These are not official Sigstore projects, so check for yourself what they do in detail before you put them into a protected pipeline.

Step 6: When the pipeline commits itself

Some workflows let CI commit automatically, for example for generated manifests. This commit can also be signed keyless, without a human confirming a login in the browser. In GitHub Actions, gitsign automatically detects the runner’s ambient OIDC credentials when you enable this explicitly with:

export GITSIGN_TOKEN_PROVIDER=github-actions

For that, the workflow needs the permission to issue itself an OIDC token:

permissions:
  id-token: write

Because there is no human user.email here, you verify automated commits through the URI SAN in the certificate instead of the email SAN. Enable it with:

git config gitsign.matchCommitter true

And set the Git identity so that it matches the workflow identity in the Fulcio certificate, for example:

git config user.name "https://myorg/myrepo/path/to/workflow"
git config user.email "1234567890+github-actions@users.noreply.github.com"

The first line is the identity that gitsign verifies against later, and the second makes GitHub recognize the commit as automated in the interface.

The range of services is tiered and builds on delivery transparency. It depends on your situation and runs across three fields: Implementation (adding delivery/evidence to the pipeline module by module), AI Governance (traceability for AI-assisted build and deployment steps), Maintenance (ongoing operation of the evidence). A firm offer only comes out of this once it is clear what you actually need.

Questions or comments on this setup: mm@mhm-dl.de.