How do you approach signing git commits on many machines?

Question

Let's say I have my dot files and 2 computers

1. home computer
2. job computer

I have configured git, like this (inspired by https://dev.to/chakrit/multiple-identity-gitconfig-with-gpg-signing-8c0)

# default case
[include]
  path = config.personal

# when working with company-x
[includeIf "gitdir:**/company-x/**/.git"]
  path = config.company-x

where config files are

# home config
[user]
  name = Firstname Lastname
  email = firstname.lastname@home.example.net
  signingkey = some-key1

# job config
[user]
  name = Firstname Lastname
  email = firstname.lastname@job.example.net
  signingkey = some-key2

This is going to work on as long as I have some-key1 and some-key2 GPG keys on all machines, but I can't, can I? So what's the approach for that?

Should I separately generate all keys for all computers (like https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/#generating-a-gpg-key)?

Should I share my home key somehow or generate it on my job computer?

Should I sign my personal projects with my company key & email? I'd rather not. I'd like to have my personal email in my personal projects, regardless on which computer I did a commit.

Answer 1

Should I separately generate all keys for all computers

This is considered as a best practice, namely because:

• you can see from where you did your commits, based on the particular key used
• you can revoke a key (and update it) without invalidating all others.

If you want all your projects to:

• be on the same path company-x
• using the same global config (with different keys per machine)

You might consider, with Git 2.23+ using different branches name, one per machine (main-machine1, main-machine2, ...), each one pushing to the regular remote tracking origin/main of their respective repo.
That is because a conditional config file can also use the branch name for its includeIf directive.

Answer 2

The 2022 alternative is to... not use key!

See GitSign, announced by Sigstore

Keyless Git signing with Sigstore!

This is heavily inspired by https://github.com/github/smimesign, but uses keyless Sigstore to sign Git commits with your own GitHub / OIDC identity.

Configuration:

$ 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

Result

Using git verify-commit:

$ 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

Wqarning: there are still limitations, and those signature are not yet recognized by GitHub.

For more, see "Introducing Gitsign" from Billy Lynch:

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!

Note: on "ephemeral certificate" and "OIDC signing":

Experimental keyless signatures work in cosign.

This uses ephemeral keys and certificates, which are signed automatically by the fulcio root CA. Signatures are stored in the rekor transparency log, which automatically provides an attestation as to when the signature was created.

Information on the fulcio root CA can be found in the fulcio repository.

Keys

The root CA keys are hard-coded in cosign today. They can only be changed by recompiling the binary. This will be made more configurable in the future. OAuth Flows

For more, from Christian Rebischke:

• "Keyless signatures for blobs with cosign"
• "What are ephemeral certificates?"

OpenID Connect can be summarized as follows: If you login into Github, Github will create a number of tokens.
These tokens are then associated with your Github Action and with these tokens you can sign any artifact

This whole process is called “keyless” signature or ambient credentials via workload identities.

The word keyless can be a little bit misleading.

It does and does not refer to the existence of a cryptographic key.
Implementation-wise, there is a key. Otherwise, the whole private/public procedure would not work.

But, on the same time you do not have to provide a secret for generating this key.
The process is secretless; at least on the first look. On the second look you will realize that your Identity has become the secret.

The terms “ephemeral” or “short-lived” do not refer to the signature validation.

Instead, these terms refer to the certificate generation itself.

The goal of short-lived certificates is to eliminate the possible risks of private key leaks.

---

Such an approach is now (July 2023) support by GitLab, for instance:

See GitLab 16.2 (July 2023)

Support for Keyless Signing with Cosign

Properly storing, rotating, and managing signing keys can be difficult and typically requires the overhead of managing a separate Key Management System (KMS). GitLab now supports keyless signing through a native integration with the Sigstore Cosign tool which allows for easy, convenient, and secure signing within the GitLab CI/CD pipeline. Signing is done using a very short-lived signing key. The key is generated through a token obtained from the GitLab server using the OIDC identity of the user who ran the pipeline. This token includes unique claims that certify the token was generated by a CI/CD pipeline.

To begin using keyless signing for your build artifacts, container images, and packages, users only need to add a few lines to their CI/CD file as shown in our documentation.

See Documentation and Issue.