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.

Or this (don't allow anon keys for different usage):

diff --git a/g10/pubkey-enc.c b/g10/pubkey-enc.c
index 14cbdbb0f..b8d4059cd 100644
--- a/g10/pubkey-enc.c
+++ b/g10/pubkey-enc.c
@@ -91,9 +91,6 @@ get_session_key (ctrl_t ctrl, struct pubkey_enc_list *list, DEK *dek)
       if (err)
         break;

Do you mean something like this?

It's in master (to be gnupg 2.3).
Enjoy.

The qualitybar has now been removed from 2.2 and master.

Shall we backport this to 2.2 which is our LTS release?

With the recent change the --sender option has an effect on the selection of the User ID used for the key validity check and the TRUST_ status lines:

We already have the option --sender which does what @mgorny requests but only in the TOFU case. I need to revisit the system to see whether we can extend it to WoT and direct key signatures.

GnuTLS seems to have some CMS support; see https://gitlab.com/gnutls/gnutls/-/issues/227 .

I had assumed that GnuPG prioritized the safety of its users over strict adherence to a particular view of a cryptographic protocol

See rG6dc3846d78192e393be73c16c72750734a9174d1 for examples on how to create a cert

Signing using ECDSA does now also work. Tested with 3 in disk keys: nistp256, nistp384 and RSA and verified using gpgsm and Governikus Signer.

Done for master

We do this now always if --auto-issuer-key-retrieve is set. Also backported to 2.2

I back ported @jukivili's changes back to 2.2 which gives a CFB decryption speedup of 25%. I also implemented AEAD _decryption_ in 2.2 to be prepared for mixed 2.2 and 2.3 version use. And AEAD is really fast compared to CFB. Willbe in 2.2.21.

Nope, I was wrong.