Community
Participate
Working Groups
I'm trying to sign a commit using the Git integration for Eclipse, version 5.4.0.201905260637. But every time a dialog with title "Missing Signing Key" appears. I can't see any logged error. I tried setting a user.signingkey property pointing to 16 char key and also without it. My ubuntu has a /home/myuser/.gnupg/ directory (drwxr-xr-x) and it has pubring.kbx file.
I also have the error message when I try to commit signed. Using signed commit on the git command line works. I use Git integration for Eclipse 5.10.0.202012080955-r org.eclipse.egit.feature.group Eclipse EGit Error message is: " Missing Signing key Unable to find a GPG key for signing. Configure GPG key with commiter email address, set user.signingKey or disable commit signing. " eclipse shows the gpg key section from the global git config in the preferences of eclipse-git. Signing tkey is configured. Fresh eclipse install with fresh workspace and fresh clone of the repository does not help.
I work on Debian buster.
Is there an error logged? If so, what's the stack trace? Where is your public key? In pubring.kbx or in pubring.gpg? Where is your secret key? Under directory private-keys-v1.d or in secring.gpg? How exactly did you specify the signing key? What's the value of user.signingKey in the git config?
And what GPG version do you use?
New Gerrit change created: https://git.eclipse.org/r/c/egit/egit/+/174134
New Gerrit change created: https://git.eclipse.org/r/c/jgit/jgit/+/174135
Gerrit change https://git.eclipse.org/r/c/jgit/jgit/+/174135 was merged to [master]. Commit: http://git.eclipse.org/c/jgit/jgit.git/commit/?id=8caaaf956a070864b8e700afc76b5ab9e8c12f36
Gerrit change https://git.eclipse.org/r/c/egit/egit/+/174134 was merged to [master]. Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=d4207273102d4c65e6742c86e8b0fd2c5778ccca
(In reply to Thomas Wolf from comment #3) > Is there an error logged? If so, what's the stack trace? Forget about this. There won't be any log entry. But: what is the GPG user ID (name & e-mail) of the key, and what exactly is the git committer ID (name & e-mail)?
@Tobias, one possible cause might be bug 570501. Can you check whether your key is encrypted with AES-OCB? To do so: * Run gpg --list-keys --with-keygrip Copy the keygrip shown for your key. * Run grep 'openpgp-s2k3-ocb-aes' ~/.gnupg/private-keys-v1.d/<keygrip>.key with <keygrip> being the copied keygrip from above. If that finds something, your key is AES-OCB encrypted, which JGit cannot handle yet.
New Gerrit change created: https://git.eclipse.org/r/c/egit/egit/+/175336
(In reply to Thomas Wolf from comment #10) > @Tobias, one possible cause might be bug 570501. Can you check whether your > key is encrypted with AES-OCB? > > To do so: > > * Run gpg --list-keys --with-keygrip > > Copy the keygrip shown for your key. > > * Run grep 'openpgp-s2k3-ocb-aes' ~/.gnupg/private-keys-v1.d/<keygrip>.key > with <keygrip> being the copied keygrip from above. > > If that finds something, your key is AES-OCB encrypted, which JGit cannot > handle yet. Sorry, grep does not find anything. When I open that file the encoding seems unknown to the used editor(s). I'm sure you know why :-). When I look closer I find something close to what you were searching for and that is: openpgp-s2k3-sha1-aes-cbc I hope that helps. Thanks for investigation.
(In reply to Tobias Boesch from comment #12) > When I open that file the encoding seems unknown to the used editor(s). I'm > sure you know why :-). > When I look closer I find something close to what you were searching for and > that is: > > openpgp-s2k3-sha1-aes-cbc > > I hope that helps. Thanks for investigation. Yes, it helps. A little, at least. Old-style files are binary, so xxd might have been better than an editor. New-style files are text files. Anyway, openpgp-s2k3-sha1-aes-cbc is AES/CBC encryption, not AES/OCB, so that's not the problem. What about the other questions from comment 3 and comment 9?
(In reply to Thomas Wolf from comment #3) > Is there an error logged? If so, what's the stack trace? > > Where is your public key? In pubring.kbx or in pubring.gpg? gpg -k /home/tobias/.gnupg/pubring.kbx > Where is your secret key? Under directory private-keys-v1.d or in > secring.gpg? I don't know how to find out. Can you help me? gpg -K /home/tobias/.gnupg/pubring.kbx > How exactly did you specify the signing key? What's the value of > user.signingKey in the git config? I followed the signing instructions on https://git-scm.com/book/id/v2/Git-Tools-Signing-Your-Work - gpg --gen-key - git config --global user.signingkey 0A46826A (Example key) My user git config shows [...] [user] name = Tobias Boesch email = tobias.boesch@googlemail.com signingkey = A1FB7D9E543E834FE0996DD02D8179D609148CFA [...]
(In reply to Thomas Wolf from comment #9) > (In reply to Thomas Wolf from comment #3) > > Is there an error logged? If so, what's the stack trace? > > Forget about this. There won't be any log entry. > > But: what is the GPG user ID (name & e-mail) of the key, and what exactly is > the git committer ID (name & e-mail)? GPG user ID (name & e-mail): gpg -K /home/tobias/.gnupg/pubring.kbx ------------------------------- [...] A1FB7D9E543E834FE0996DD02D8179D609148CFA uid [ultimate] Tobias Boesch <tobias.boesch@googlemail.com> [...] git commiter id (name & e-mail) is shown in comment 14.
So by now we know that * it's not a problem with AES/OCB. * it's not a problem with some unsupported value for user.signingkey. * it's not a problem with case sensitivity between matching user.email from the git config against the key's user id (uid). If you have a file ~/.gnupg/private-keys-v1.d/<keygrip>.key (with <keygrip> being the value shown by gpg --list-keys --with-keygrip for key A1FB7D9E543E834FE0996DD02D8179D609148CFA), then the secret key comes from the gpg-agent's private-keys-v1.d, otherwise from secring.gpg. If you have such a file, what's the first character (first byte) of that file? Maybe it's stored in a format JGit can't read. Which gpg version are you using? But anyway I plan to change signing in EGit completely and just call out to the gpg executable for signing instead of using JGit's Java re-implementation. See https://git.eclipse.org/r/c/egit/egit/+/175336 . That should resolve such problems for good.
(In reply to Thomas Wolf from comment #16) > So by now we know that > > * it's not a problem with AES/OCB. > * it's not a problem with some unsupported value for user.signingkey. > * it's not a problem with case sensitivity between matching user.email from > the git config against the key's user id (uid). > > If you have a file ~/.gnupg/private-keys-v1.d/<keygrip>.key (with <keygrip> > being the value shown by gpg --list-keys --with-keygrip for key > A1FB7D9E543E834FE0996DD02D8179D609148CFA), then the secret key comes from > the gpg-agent's private-keys-v1.d, otherwise from secring.gpg. In ~/.gnupg/private-keys-v1.d/ there are two <keygrip>.key files. One has the keygrip of the pub key and the other is the keygrip of a sub key entry in "gpg --list-keys --with-keygrip". So, the secret key comes from the gpg-agent's private-keys-v1.d. > If you have such a file, what's the first character (first byte) of that > file? > Maybe it's stored in a format JGit can't read. The first 27 characters of the file for the pub key: "(21:protected-private-key(" > Which gpg version are you using? gpg (GnuPG) 2.2.12 libgcrypt 1.8.4 > But anyway I plan to change signing in EGit completely and just call out to > the gpg executable for signing instead of using JGit's Java > re-implementation. See https://git.eclipse.org/r/c/egit/egit/+/175336 . That > should resolve such problems for good. I'm also happy to wait for that. I opened this issue to help. I don't really need this often. Only one repo requires signing and I contribute really rare to it. I can use the git command line for that until egit signing is rewritten. If we plan to wait - do we leave this open? It is your choice - should we go on finding the cause? I can help if you would like to - otherwise I can wait as explained.
(In reply to Tobias Boesch from comment #17) > So, the secret key comes from the gpg-agent's private-keys-v1.d. > > > If you have such a file, what's the first character (first byte) of that > > file? > > The first 27 characters of the file for the pub key: > "(21:protected-private-key(" > > > Which gpg version are you using? > > gpg (GnuPG) 2.2.12 > libgcrypt 1.8.4 I'm a bit out of ideas. Current JGit doesn't know about the keygrip yet; it scans all files in private-keys-v1.d. Maybe that's the problem. There's a change in review to improve that in JGit, too: https://git.eclipse.org/r/c/jgit/jgit/+/174955 . I'd prefer to keep this issue open for now. We could re-try once change 174955 is merged in JGit, or once change 175336 is merged in EGit. Until then I'm afraid my only suggestion for tracking this down would be that you debug this live on your system. But that may be time consuming and may not be worth your time if it's not a big issue for you. (In case you want to try: I'd start with a breakpoint at org.eclipse.jgit.gpg.bc.internal.BouncyCastleGpgKeyLocator.findSecretKey().)
Gerrit change https://git.eclipse.org/r/c/egit/egit/+/175336 was merged to [master]. Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=2b66e9b8baa2104c320c301daea9147227ef39fe
@Tobias: both changes are in now. Would be interested to know if it works now if you install EGit nightly from https://download.eclipse.org/egit/updates-nightly . If it still doesn't work: try changing the setting in the Git->Committing preferences from "Bouncy Castle library" to "External GPG". (It should not be necessary to set the path to the external GPG executable.) Does it work then for you?
(In reply to Thomas Wolf from comment #20) > If it still doesn't work: try changing the setting in the Git->Committing > preferences from "Bouncy Castle library" to "External GPG". (It should not > be necessary to set the path to the external GPG executable.) Does it work > then for you? Initial "New & Noteworthy" entry for using "External GPG" is at [1]. [1] https://wiki.eclipse.org/EGit/New_and_Noteworthy/5.11#Using_GPG_to_Sign_Commits_and_Tags
Closing this now; the BouncyCastle signing implementation has been improved substantially, and additionally there's now the option to use a gpg executable instead.
