Bug 2005714

I think we should build gnupg with `--disable-ccid-driver` as described in the bug. When we have two competing ccid daemons in the system, it can not end well.

Do you have Fedora 35 at hand to verify that this solves your issue?

https://koji.fedoraproject.org/koji/taskinfo?taskID=75988245

I tested with this build on Fedora 34 and the basic operations seems to work fine.

Here is a PR with changes I used to build the above scratch build:

https://src.fedoraproject.org/rpms/gnupg2/pull-request/11

(In reply to Jakub Jelen from comment #1)
> I think we should build gnupg with `--disable-ccid-driver` as described in
> the bug. When we have two competing ccid daemons in the system, it can not
> end well.
> 
> Do you have Fedora 35 at hand to verify that this solves your issue?
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=75988245
> 
> I tested with this build on Fedora 34 and the basic operations seems to work
> fine.

Tested the build found following the link, and it works on F35 with an empty scdaemon.conf.

GnuPG 2.3.x is still broken when using a Yubikey 5 to sign git commits with GPG. It keeps complaining about not being able to find the secret key. My Yubikey 5 NFC was setup with my keys following this guide: https://github.com/drduh/YubiKey-Guide

Steps to reproduce:

$ rpm -qa |grep gnupg
gnupg2-smime-2.3.2-2.fc36.x86_64
gnupg2-2.3.2-2.fc36.x86_64

$ mkdir testing
$ cd testing
$ git init .
$ touch README.md
$ git add .

$ GIT_TRACE=1 git commit -m "GPG Signing on Fedora 35 and a Yubikey is broken with 2.3.2-2.fc35"
16:52:42.625390 git.c:455               trace: built-in: git commit -m ''
16:52:42.625904 run-command.c:667       trace: run_command: /usr/bin/gpg --status-fd=2 -bsau 0x00000000000000
error: gpg failed to sign the data
fatal: failed to write commit object

$ /usr/bin/gpg --status-fd=2 -bsau 0x00000000000000
[GNUPG:] KEY_CONSIDERED snip 0
[GNUPG:] BEGIN_SIGNING H10
Testing
gpg: signing failed: No secret key
[GNUPG:] FAILURE sign 67108881
gpg: signing failed: No secret key

Downgrading to 2.2.27-4.fc35 fixes the issue.

$ sudo dnf install https://kojipkgs.fedoraproject.org//packages/gnupg2/2.2.27/4.fc35/x86_64/gnupg2-2.2.27-4.fc35.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/gnupg2/2.2.27/4.fc35/x86_64/gnupg2-smime-2.2.27-4.fc35.x86_64.rpm

$ rpm -qa |grep gnupg
gnupg2-2.2.27-4.fc35.x86_64
gnupg2-smime-2.2.27-4.fc35.x86_64

$ GIT_TRACE=1 git commit -m "GPG Signing on Fedora 35 and a Yubikey is broken with 2.3.2-2.fc35"
17:01:16.864536 git.c:447               trace: built-in: git commit -m 'GPG Signing on Fedora 35 and a Yubikey is broken with 2.3.2-2.fc35'
17:01:16.865087 run-command.c:667       trace: run_command: /usr/bin/gpg --status-fd=2 -bsau 0x00000000000000
17:01:48.385805 run-command.c:667       trace: run_command: git maintenance run --auto --no-quiet
17:01:48.387070 git.c:447               trace: built-in: git maintenance run --auto --no-quiet
[main (root-commit) 7eae7e9] GPG Signing on Fedora 35 and a Yubikey is broken with 2.3.2-2.fc35
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 README.md

$ /usr/bin/gpg --status-fd=2 -bsau 0x00000000000000
[GNUPG:] KEY_CONSIDERED snip 0
[GNUPG:] BEGIN_SIGNING H10
Testing
[GNUPG:] SIG_CREATED D 1 10 00 1632175995 snip
-----BEGIN PGP SIGNATURE-----
snip
-----END PGP SIGNATURE-----

Hi Joe, did you try to restart the scdeamon and gpg-agents running in the background after the update?

The `u 0x00000000000000` looks suspicious. I think it should be configured as user.signingkey in your ~/.gitconfig

Hey Jakub,

Yeah, I restarted them a lot with no change in behavior. Also, sorry, I just redacted my key in my example with `0x00000000000000` I have my real key configured in ~/.gitconfig.

Hmm... no problem here doing a detached sign with 2.3.2-2:

$ gpg2 -bsa somedata.svg 
gpg: using "..." as default secret key for signing

$ gpg2 --verify somedata.svg.asc 
gpg: assuming signed data in 'somedata.svg'
gpg: Signature made Tue 21 Sep 2021 15:20:18 BST
gpg:                using RSA key ...
gpg: Good signature from "James

etc. Tried exporting keys, reloading into a fresh ~/.gnupg and doing a gpg2 --card-status?

Try doing this:

/usr/bin/gpg --status-fd=2 -bsau <your key>

type `testing` and then ctrl+d to sign it with 2.3.2-2

I copied my `~/.gnupg` to this Fedora 35 from my Fedora 34 laptop that is running gnupg2-2.2.27 where it works perfectly fine.

(In reply to Joe Doss from comment #8)
> /usr/bin/gpg --status-fd=2 -bsau <your key>
> 
> type `testing` and then ctrl+d to sign it with 2.3.2-2

From what I can tell, that worked OK for me: I pressed Ctrl+D, answered the PIN prompt, and it printed out an ascii-armoured signature.

Can you get more debug information from the gpg, gpg-agent or scdaemon?

Created attachment 1825338 [details]
debug output of gpg 2.3.1

See attached txt file for debug output from the following command:

/usr/bin/gpg  --debug-level guru --status-fd=2 -bsau <my key id>

It looks like it is prompting for the PIN here:

gpg: DBG: chan_4 -> SETKEYDESC Please+enter+the+passphrase+to+unlock+the+OpenPGP+secret+key:%0A%22Joe+Doss+<joe>%22%0A4096-bit+RSA+key,+ID+0xsnip,%0Acreated+2019-12-19.%0A

but it never prompts pinentry-gnome3 so I can enter in the pin. 2.2.27 prompts just fine.

Setting pinentry-program /usr/bin/pinentry-curses in gpg-agent.conf results in the same issue with 2.3.x

Thanks for the logs.

This does not look like a communication with the pinentry, but with the gpg-agent or scdaemon. Pinentry version is on 1.1.1

gpg: DBG: chan_4 -> GETINFO version
gpg: DBG: chan_4 <- D 2.3.1

This is also not the latest one. Can you check with the gnupg2-2.3.2-2 posted before? It should be now in updates-testing.

Using `debug-pinentry` in gpg-agent.conf might also show more information how it is communicated with pinentry if this would be a problem.

If the issue should be in the scdaemon, you might also turn log level of the scdeamon in scdaemon.conf, but I am not sure where the logs would go.

Looks like gnupg2-2.3.2-2 fixes things! I thought I had tried that version from the previous posts but installing it from updates-testing seems to have sorted things out. I had to unmask and enable pcscd.socket and pcscd.service because having those enabled prevented my yubikey from being recognized without restarting pcscd over and over again. Which makes sense since this version disabled the ccid driver. 

Thanks Jakub!

FEDORA-2021-c4e724a2ba has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-c4e724a2ba

Thanks for checking. I added this bug to the update so it should be closed once the update will land in stable.

FEDORA-2021-c4e724a2ba has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.