-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support smimesign program for signing git commits using S/MIME #59
Comments
EGit supports S/MIME (X.509) signatures using an external GPG since 7.0. This was tested with I suppose the problem is that EGit first calls
EGit also includes the So there seem to be three things to do:
There is of course a third alternative: get |
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? |
@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. |
@tomaswolf Is there any chance of adding an "External S/MIME Sign" option to this drop-down? Otherwise, is there a possibility of probing the External GPG program to determine if it is The release notes for 7.0 mention |
"External GPG" uses the configured Supporting
The third point (listing keys) is a non-issue for x509 signing. The user has configured at least Plus on signature verification, |
@eric-milles : I don't quite understand "This latest requirement for X.509 signed commits"... which requirement? Openpgp signatures are still possible, and EGit can now also do SSH signatures. EGit does not require x509 signatures. If you have been using EGit previously, there is nothing new in that area. That said, I've pushed Gerrit change 1206209. It makes EGit use only the same command-line options as C git. With that, smimesign should then just work, if configured in the git config. I hope that a large organization such as yours can thoroughly test this on different platforms (Mac OS, Windows, Linux) with both smimesign and gpgsm. (We have no automated integration tests with gpg/smimesign, and I don't have smimesign in my development environment, so I cannot test manually.)
Please use the new temporary update site instead. |
To clarify, I think he's referring to the requirements of internal corporate policies.
I gave it a try, and it works if I select I'm still getting the same error as in my original report when I have When using
I'm on Mac OS X, and it looks like I might have some $PATH issues to debug to get this working a bit more smoothly (the Eclipse Terminal also starts up with a different $PATH than my typical terminal shell, until I add I'll work on testing this a little more after the holidays. Thank you for your help! |
You probably have defined
Try
EGit uses the program as specified in the git config. The executable defined in the UI is taken only as fallback if no program is defined in the git config. I could try improving this a bit. One idea might be to call the program not directly but via the shell (with --login). |
Or wait -- you wrote you already had the full path in the git config. Hmmm. Then I don't see why the exception message says |
I've pushed a follow-up commit that explicitly looks up the program on $PATH. Use the new temporary update site for testing, please. |
I was able to set the External GPG Executable to an adapter batch script: @ECHO OFF
java %USERPROFILE%\SigningAdapter.java %*
REM -Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=y import java.io.*;
import java.util.*;
public class SigningAdapter {
public static void main(String[] args) {
if (Arrays.asList(args).contains("--list-secret-keys")) {
System.out.println("crs:a:b:c:d:e:f:g:h:i:j:ks");
} else { // -bsau, <ID>, --batch, --no-tty, --status-fd, 2, --output, -
try { // TODO: put args into list and drop "--batch", etc. with remove
var b = new ProcessBuilder("smimesign.exe", args[0], args[1], args[4], args[5]);
var p = b.inheritIO().start();
System.exit(p.waitFor());
} catch (Exception e) {
System.err.println(e.getMessage());
}
}
}
} Given this and no "gpg.x509.program" property, a commit can be signed via NOTE: This is vanilla Eclipse 4.33 (2024-09). I did not see the update site you posted before trying this. |
Try the update site; you should not need this wrapper. It should just work out of the box with the following two git configs:
(Plus the user.signingKey, if needed.) |
On Windows, it would be
|
Yes, in the history view. The lower left pane shows the commit, which includes the signature info if the preference at Preferences->Version Control->Git->History ("Verify Signatures") is switched on. |
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:
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:The configuration works without issue with command-line git on my machine. Only Eclipse has issues with it.
Alternatives considered
Additional context
No response
The text was updated successfully, but these errors were encountered: