Thanks for the reports. IIRC, we had similar reports in the past either here or on a ML.

The code has been reworked to also support the updated schema which also stores the fingerprints and a parsed down mail address. See gnupg/doc/ldap/ . These changes are in master and 2.2.26. Sorry for taking so long to fix that.

I wrote https://github.com/rupor-github/win-gpg-agent to simplify usage on Windows until this issue is resolved - it handles various edge cases on Windows.

Reading the code again, I think that some configuration of NKS card doesn't work well, when it has no certificates but keys (e.g. IDLM config).
I'm going to fix do_readkey as well (the approach #1).

In T5150#140039, @gniibe wrote:

With little (mostly no) knowledge of NKS card, I think I fixed this issue.

Thanks a lot for your time to locate the problem. I took the approach of #2.

I'm not sure why I thought that it would work now. With current master I get

$ gpg-connect-agent "SCD READKEY --info-only -- 39400430E38BB96F105B740A7119FE113578B59D" /bye
ERR 100663414 Invalid ID <SCD>

And I also did a backport to 2.2 :-) See rGa028f24136a062f55408a5fec84c6d31201b2143

Go ahead (but w/o the /*if (keytime*)*/ line ;-)

The following (probably not entirely correct) patch fixes the problem because it marks the PIV card key as pCARDKEY even though keytime is 0.

diff --git a/g10/keygen.c b/g10/keygen.c
index b510525e3..03c929c0b 100644
--- a/g10/keygen.c
+++ b/g10/keygen.c
@@ -4720,7 +4720,8 @@ quick_generate_keypair (ctrl_t ctrl, const char *uid, const char *algostr,

The error comes form using READKEY which is processed by gpg-agent. At this time the agent does not yet know the stub key and thus returns ENOENT. At the places before we used "SCD READKEY" which works directly with scdameon and does not need a stub file. We need to review the new(?) way of creating stub files, describe that and then fix this by either making sure tha the stub key is created first or that we use SCD READKEY there too.

Seems to work now. I'm not sure whether I should close this issue because it's marked for backport.

Works now. Thanks.

Regarding a backport I think that I will eventually backport all app-*c to stable by source copying them. We have a quite stable internal API and thus it is easier to keep at least the card specific code in sync. I did some local work in this directory some time ago.

Applied and push the change above in rG920154370834: scd,nks: Fix caching keygrip..

For the first issue, I pushed the change in rGc3a20c88fb30: scd: Fix an error return for READKEY..

Fixed in rG006944b856ee: scd,nks: Fix SEGV for learn for older card..

The same problem occurs for NKS (v3) cards where the keys also do not have a keytime.

Output of (unpatched) gpg with --debug ipc:

$ GNUPGHOME=$HOME/.cache/gnupg-master-home gpg --debug ipc --quick-gen-key --yes piv@example.net card
gpg: reading options from '[cmdline]'
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: enabled debug flags: ipc
gpg: DBG: chan_3 <- OK Pleased to meet you, process 7588
gpg: DBG: connection to the gpg-agent established
gpg: DBG: chan_3 -> RESET
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> OPTION ttyname=/dev/pts/7
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> OPTION ttytype=xterm-256color
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> OPTION display=:0
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> OPTION xauthority=/home/ingo/.Xauthority
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> OPTION putenv=XMODIFIERS=@im=local
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> OPTION putenv=GTK_IM_MODULE=cedilla
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> OPTION putenv=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> OPTION putenv=QT_IM_MODULE=xim
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> OPTION lc-ctype=de_DE.UTF-8
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> OPTION lc-messages=de_DE.UTF-8
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> GETINFO version
gpg: DBG: chan_3 <- D 2.3.0-beta1481
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> OPTION allow-pinentry-notify
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> OPTION agent-awareness=2.1.0
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> SCD SERIALNO
gpg: DBG: chan_3 <- S SERIALNO FF020001008A7796
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> SCD SERIALNO
gpg: DBG: chan_3 <- S SERIALNO FF020001008A7796
gpg: DBG: chan_3 <- OK
gpg: Serial number of the card: FF020001008A7796
gpg: DBG: chan_3 -> SCD LEARN --keypairinfo
gpg: DBG: chan_3 <- S CHV-USAGE 40 00
gpg: DBG: chan_3 <- S CHV-STATUS -2 3 -2
gpg: DBG: chan_3 <- S KEYPAIRINFO EB6A99D61EF3BC7C7934173CD9833376D773E65D PIV.9A a
gpg: DBG: chan_3 <- S KEYPAIRINFO 482BD076054B6950A6FC476C356AF029A5115BBD PIV.9E a
gpg: DBG: chan_3 <- S KEYPAIRINFO 0773CFCB90C043F3A6151B3F2FBF23726F10A48A PIV.9C sc
gpg: DBG: chan_3 <- S KEYPAIRINFO ED6579C1360100BE92C46ECB1A1826A63614D5AB PIV.9D e
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> SCD GETATTR $SIGNKEYID
gpg: DBG: chan_3 <- S $SIGNKEYID PIV.9C
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> SCD READKEY --info -- PIV.9C
gpg: DBG: chan_3 <- S KEYPAIRINFO 0773CFCB90C043F3A6151B3F2FBF23726F10A48A PIV.9C sc - nistp256
gpg: DBG: chan_3 <- [ 44 20 28 31 30 3a 70 75 62 6c 69 63 2d 6b 65 79 ...(118 byte(s) skipped) ]
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> SCD SERIALNO
gpg: DBG: chan_3 <- S SERIALNO FF020001008A7796
gpg: DBG: chan_3 <- OK
gpg: Serial number of the card: FF020001008A7796
gpg: DBG: chan_3 -> SCD LEARN --keypairinfo
gpg: DBG: chan_3 <- S CHV-USAGE 40 00
gpg: DBG: chan_3 <- S CHV-STATUS -2 3 -2
gpg: DBG: chan_3 <- S KEYPAIRINFO EB6A99D61EF3BC7C7934173CD9833376D773E65D PIV.9A a
gpg: DBG: chan_3 <- S KEYPAIRINFO 482BD076054B6950A6FC476C356AF029A5115BBD PIV.9E a
gpg: DBG: chan_3 <- S KEYPAIRINFO 0773CFCB90C043F3A6151B3F2FBF23726F10A48A PIV.9C sc
gpg: DBG: chan_3 <- S KEYPAIRINFO ED6579C1360100BE92C46ECB1A1826A63614D5AB PIV.9D e
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> SCD GETATTR $ENCRKEYID
gpg: DBG: chan_3 <- S $ENCRKEYID PIV.9D
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> SCD READKEY --info -- PIV.9D
gpg: DBG: chan_3 <- S KEYPAIRINFO ED6579C1360100BE92C46ECB1A1826A63614D5AB PIV.9D e - rsa2048
gpg: DBG: chan_3 <- [ 44 20 28 31 30 3a 70 75 62 6c 69 63 2d 6b 65 79 ...(286 byte(s) skipped) ]
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> RESET
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> READKEY -- 0773CFCB90C043F3A6151B3F2FBF23726F10A48A
gpg: DBG: chan_3 <- ERR 67141713 No such file or directory <GPG Agent>
Key generation failed: No such file or directory
gpg: secmem usage: 0/32768 bytes in 0 blocks

Yes sure. --debug ipc should give you some insight why gpg does not thing the key is on the card.

After patching the above mentioned if-clause the command fails on the first try, but it succeeds on the second try

$ gpgconf --kill all

Works for me. Also with a gpg.conf-2 file. Do you use a /etc/gnupg/gpg.conf ?

Fixed in master.
(confirmation interaction is also fixed.)

With Debian's GnuPG 2.2.12, I got an error:

With bata1449, I cannot reproduce it.
I can import by gpg --import key-uids-sec.pgp
I tested with Debian's libgcrypt, as well as libgcrypt master (4a50c6b8).

What can be done is to use gpgconf --list-dirs bindir as a fallback for pinentry.

@werner can you confirm if the environment I provided will work with OpenSSH support fully implemented?

Using a not yet existing directory is a security feature. The directory is created at a time the signature has not yet been verified and thus it would be too easy to trick a user into overwriting important data.

I will consider a -p option for gpgtar.

So, if there's no support for native OpenSSH yet, I'll wait for it. After it's supported, I should be able to get the scenery I described working, right?

Unfortunately you can't pass extra arguments.

@bvieira You need to set pinentry-mode=loopback for gpg program used in git.

I'm actually trying to do the following:

In the meantime you can use [0]. I have tested with ssh key on yubikey and AuthenticationMethods publickey, win32-ssh (or ssh-portable, which is the new repository name) correctly works with gpg and pinentry is called. Despite it being called wsl, wsl environment is not required.

I still don't think that it is correct. We would also need to turn fd from an int to a gnupg_fd_t (ie. a HANDLE under Windows) which requires other changes and should be done in the other parts of the code as well. assuan_sock_close also delegates to the system specific function and on Windows removes the fd also from the cygwin table. This may trigger other bugs so I'd like to keep it as it is to go with the code which has been in active use for a long time - at least for 2.2

I implemented subkey collapsing in 2.3. It is enabled by default but you can disable it it with

Hello,
just reading the issue in detail.

We won't do that for 2.2.

Applied and pushed.

No, it didn't work, but we need more change:

diff --git a/g10/tdbio.c b/g10/tdbio.c
index bfeede991..9f01667b4 100644
--- a/g10/tdbio.c
+++ b/g10/tdbio.c
@@ -1909,12 +1909,9 @@ tdbio_search_trust_byfpr (ctrl_t ctrl, const byte *fingerprint, TRUSTREC *rec)
 gpg_error_t
 tdbio_search_trust_bypk (ctrl_t ctrl, PKT_public_key *pk, TRUSTREC *rec)
 {
-  byte fingerprint[MAX_FINGERPRINT_LEN];
-  size_t fingerlen;
+  byte fingerprint[20];

I revise the change, using different approach, so that we can keep better existing implementation compatibility.

Since it was handled in T4908, this task is merged into that.

I realized that it fails with GPG_ERR_INV_ID (with gpg master) when it's on smartcard.
It can't be decrypted if it's on smartcard, that's true, but more relevant error would be good for this case.

I deferred this thing because I hoped to implement this in the keyboxd. Another option is to use a truncated fingerprint - for displaying purposes we anyway truncate to 25 byte and 20 byte should also be okay until we can move this to keyboxd. But okay, if you want to add support please go ahead but make sure that there are no fatal conditions if a gpg 2.2 accesses the v5 enabled trustdb.

Here is the patch for trustdb and keybox. Not introduced new record structure, but RECTYPE_TRUST_SHA2 saving only 20-byte.

Something like:

• 1-byte: TYPE
• 1-byte: Reserved
• 32-byte: fingerprint
• 1-byte; ownertrust / min_ownertrust
• 1-byte: depth
• 4-byte: validlist recnum

Any news on this?

@mbrinkers : I think that it was fixed in GnuPG 2.2.21 by T4908: ECDH with AES-128 decryption failure when fully padded.
It was unfortunate that this bug report didn't work to solve problem, with malformed data and discussion went to unrelated thing.

I have run into an interoperability issue between BouncyCastle PGP (Java) library and gpg which seems to caused by key obfuscation.

Duplicate - see T4702 instead

The first, I guess. The problem is that you are technical capable of _decryption_ but gpg does not allow this because for some reasons the key is arbitrary limited to signing. A warning message should be printed in thus a case but decryption should succeed.