Support smimesign program for signing git commits using S/MIME

JBlaufussTR commented 2 weeks ago

Description

Support smimesign program for signing commits using S/MIME. The smimesign tool was developed by GitHub itself to support S/MIME commit signing, and works with command-line git with something like this .gitconfig:

[user]
    name = My Name
    email = my.name@employer.com
    signingkey = 00000000000000000000000000000000000dummy
[commit]
    gpgsign = true
[gpg]
    format = x509
[gpg "x509"]
    program = smimesign

Motivation

My workplace is in the process of implementing mandatory git commit signing using corporate-issued S/MIME certificates. They have automatically rolled this out to workstations by automatically updating our .gitconfig files to use the smimesign program. Even the latest Eclipse 2024-09 (4.33.0) using EGit 7.0.0.202409031743-r org.eclipse.egit gets errors with this configuration when making a commit (which works with command-line git). Here is the error popup:

Missing Signing Key

Unable to find a GPG key for signing with key ID `00000000000000000000000000000000000dummy`. Configure the GPG key with committer email address, set git config user.signingKey, or disable commit signing.

The configuration works without issue with command-line git on my machine. Only Eclipse has issues with it.

Alternatives considered

Leave Eclipse and use command-line git for any operation that makes a commit.
Use IntelliJ, which leverages command-line git instead of its own implementaiton

Additional context

No response

tomaswolf commented 2 weeks ago

EGit supports S/MIME (X.509) signatures using an external GPG since 7.0. This was tested with gpgsm.

I suppose the problem is that EGit first calls <program> --list-secret-keys --with-colons --batch --no-tty <key_spec> to figure out whether there is a key at all, and if so, whether it is a signing key, and smimesign doesn't understand that.

smimesign has the simpler --list-keys option to list available signing keys. Apparently the assumption with smimesign is that any key returned by --list-keys is a signing key. Unfortunately, the command line is different. It also produces output for a human (not easily machine-readable).

EGit also includes the --batch --no-tty options in the call for actually signing to ensure that the program does not prompt for passphrases in a terminal (that would never get to the user when invoked from Eclipse). EGit also includes --output - to force output of the signature to stdout, which might be redundant.

So there seem to be three things to do:

Check whether --batch --no-tty is really necessary with gpg/gpgsm. If it is, use it only for gpg/gpgsm.
Check whether --output - is really necessary (probably not).
Figure out a better way to list keys to determine whether there is a signing key. (In GPG, not all keys are signing keys).

There is of course a third alternative: get smimesign updated to understand --list-secret-keys --with-colons --batch --no-tty and to understand -bsau <keySpec> --batch --no-tty --status-fd 2 --output -. :-)

tomaswolf commented 2 weeks ago

smimesign --verify also doesn't seem to be fully gpgsm-compatible in the status lines it produces. gpgsm gives me a VALIDSIG line; I don't see that being generated in the smimesign code. VALIDSIG is kind of important because it would report the signature creation time.

So there we have another thing to check: how to deal with a missing signature creation time in validation. Just fill in the git commit/tag timestamp?

JBlaufussTR commented 2 weeks ago

@tomaswolf Thank you for looking into this. I just created an issue in their repo as well, in case they have the ability to add support for the command line options you said are missing, though EGit looks a lot more active.

eclipse-egit / egit