Was reported to me again in the context of paperkey export / print secret key in Kleopatra.

I pushed two fixes. One which hopefully avoids the corrupted trustdbs and a second one to repair a version-record-only trustdb (the example file).

My test case is to import my pubkey and then run:

We don't support v3 keys at all.

I just tested changing passphrases and indeed this is very ugly. Especially as this opens up a wide range of error states where you have different passphrases for different subkeys etc.

I experienced this issue today while cleaning up my keychain. I recently switched from pgp to tofu+pgp trustmodel and this caused me the above error when doing:

I give this high priority as I would love to have this fixed for the next release.

I looked into it a bit. As bulk import is highly inefficient copying the keyring lots and lots of times the migration of a keyring with 1000keys takes around 6 Minutes.

Thanks, Werner.
With the latest data everything works fine.
I also a problem with incorrect cipher state resetting if last chunk is 0-size.

I found another encoding error which renders the test data uploaded yesterday useless: Here is a bogus AEAD packet:

00000040  d4 84 01 07 01 00 6c 34  7c 37 83 24 2a 11 bc 1c  
00000050  bd 1a 76 da 93 8a
              [start chunk] 32 cd  80 a5 8e db 3a 7d 4a 40  
00000060  c5 0d 82 01 8d 64 7f 65  cd ca 58 d0 e7 db 3b 5e  
00000070  89 d9 1b c8 d9 93 1a 37  3c 0e a5 8f 4b 0d 9f db  
00000080  34 56 c8 f1 e9 b7 f5 0b  d2 53 4f 6c fd f8 e9 16  
00000090  cd a4 ae f6 7f 65
                      [tag] ef 5f  96 af 62 70 f4 30 27 37  
000000a0  68 61 95 0a fb 23
                [extra tag] a6 66  75 7a 47 bb 57 d3 da 5a  
000000b0  4d d1 c2 2f 43 39
                [final tag] cd 22  91 16 1d 92 17 1f f2 cf  
000000c0  0f c9 11 56 d0 a9

password is "abc". I have some comments in the commit logs.

Hi Werner, thanks.
Looks like our tests against GnuPG are passing now.
Can you please provide the password for this file as well? 'password' doesn't seem to fit.

Here is a file

I found another issue in current master of GnuPG. Probably you already noticed it - when GnuPG AEAD-encrypts input which is a multiple of chunk size, then incorrect chunk number is used in the last block (+1)
The same happens for decryption.
Here is debug output of 128-byte input decryption with 64-byte chunk len:

gpg: DBG: nonce: D0 33 CD AC B5 54 07 66 2C 5C 55 7F A9 F2 EF
gpg: DBG: authdata: D4 01 07 02 00 00 00 00 00 00 00 00 00
gpg: DBG: nonce: D0 33 CD AC B5 54 07 66 2C 5C 55 7F A9 F2 EE
gpg: DBG: authdata: D4 01 07 02 00 00 00 00 00 00 00 00 01
gpg: DBG: nonce: D0 33 CD AC B5 54 07 66 2C 5C 55 7F A9 F2 ED
gpg: DBG: authdata: D4 01 07 02 00 00 00 00 00 00 00 00 02
gpg: DBG: eof seen: holdback buffer has the tags.
gpg: DBG: nonce: D0 33 CD AC B5 54 07 66 2C 5C 55 7F A9 F2 EC
gpg: DBG: authdata: D4 01 07 02 00 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 80

Hi Werner,
Looks like there is a problem on my side, I miscalculated data length (0x240 while it should be 0x280).
Other then this values are the same:

Can you help me and tell me the AD for the last and the final chunk?
My current values are:

With AEAD we can immediately check whether the correct passphrase is used. With CFB we can't do that and thus the checking is delayed until we can do the bulk encryption using the session key. At that point it is too late to check for other keys - well we could record that all and try again but that would make the code pretty complicate.

I also struggled to get two cards running at the same time. Host system is Fedora 26 with gnupg 2.2.4.

Please see the original file (hello.txt), CFB-encrypted to two passwords (hello.txt.cfb), and AEAD-encrypted (hello.txt.aead).
Passwords used are '1' and '2'.

Ahh, yes you're right, in fact it is. Although after a bit of testing, Arch is both setting XDG_RUNTIME_DIR and respecting the XDG spec, and so is deleting that directory whenever any given user logs out. Given that, I'm not certain how any features of gnupg that expect /run/user/$UID to persist would work.

That is just coincidence, ie. XDG_RUNTIME_DIR must be set to /run/user/$UID on you box.

Thanks for this research. Two weeks ago I also did some testing and started to implement a fast track way for simple encryption(for example without signing and filters). But your path to improve iobuf is probably the more general solution.

Rather surprised that it doesn't know about XDG_RUNTIME_DIR, as a stock install of gnupg on Arch will build its sockets in $XDG_RUNTIME_DIR/gnupg by default.

The --create-socketdir is not not anymore needed because the socket directory is meanwhile always created. We would need to handle the --dry-run in a special way here.

HAVE_PSELECT_NO_EINTR is introduced for systems which pselect cannot be interrupted.

When disabling CRL checks, you expose the user to drawbacks by outdated or revoked certificates. While I agree that improving implementations to not check the validation information too often or even build proxies is a good idea, I have a tendency to keep crl checking enabled for CMS crypto operations because it seems to be a lesser drawback.

Here's patches I used for testing. First is hack for disabing SHA1+RMD160 'old GPG LITERAL+SIG case' and second is 'iobuf_get to iobuf_read' optimization.

I also think that when calling sign from the --edit-key interactive menu the experience should be a bit different. Instead of listing all the UIDs (even the revoked one) and then warning about the impossibility to sign some of them, it would be better to re-list only the UIDs that are going to be signed. In case --only-sign-text-ids is specified, the non-text UIDs should be stripped from this list too.

I think that it's the kernel problem in NetBSD, where signal to self cannot result EINTR for pselect.
Well, something like rG031e3fa7b9a6: scd: Wake up the select when new USB scan. can be applied, I suppose.
Let's see for configure.ac and HAVE_PSELECT_EINTR.

Originally dirmngr was designed to be a system service for the reason that CRLs are not user specific. However, the majority of systems today are used by a single user and thus we dropped that feature when integrating dirmngr into gnupg.

--use-tor does not avoid it because the CRL-DP can be made unique for each certificate. Depending on the verification model a CRL or OCSP lookup is necessary for correct evalution of a signature (shell model as used for qualified signature). This is why we in gpg honor-keyserver-url is not enabled by default; the keyserver URL take from the key is the OpenPGP counterpart of the CRL-DP.

it is the decision of the user to use such a certificate.

The implemented X.509 profiles require that the status of a certificate is to be checked. CRLs are also not looked up for each verification but only once during their lifetime. Some CA have unreasonable short lifetimes for their CRL but it is the decision of the user to use such a certificate.

Additionally, we might want some sort of delayed or batched CRL-checking that doesn't block signature verification with another network interaction, but would protect the user against future problems.

I just thought that going by your comment on Sat, Jan 27, 5:29 PM that you would use libdns, instead of resolv.conf directly. Maybe I understood that comment wrong.

dirmngr looks into /.etc/resolv.conf and does not know anything about systemd specific things (nor do I). Thus having a symlink seems to be an appropriate solution.

Note that it works as expected if I symlink /run/systemd/resolve/stub-resolv.conf to /etc/resolv.conf. Other programs appear to not require this change.

I can reproduce this issue with gpg 2.2.4, systemd-resolved and Arch Linux. Unlike the original reporter, I do not have 127.0.0.1 in my /etc/resolv.conf. I do however have it in /etc/hosts.

Oh. T1447 only referenced SRV records, which is why the CNAME case wasn't handled. So T1447 was fixed completely but T1447 did not cover the full extent of the underlying problem.

In T3714#109752, @werner wrote:

I have not checked whether we make this available in the GPGME API

There can't be an MDC warning if MDC is not used ;-)

As far as I can see GnuPG does not emit appropriate status lines:

Indeed with debug dns I can see that what takes so long is the resolve_dns_name. After the debug output prints that line the key comes nearly instant.

I can't replicate it here. With my key it takes
real 0m0.346s
user 0m0.080s
sys 0m0.004s
and for your key it takes a few 10ms longer (more hops). Is one of your DNS responder failing? Can you please run dirmngr with --debug dns ?

@gniibe just checking – any news for 2.2 support? Should I reopen this bug or report a new one against 2.2?

Duplicate of T3576

This is not with 2.0 but with 2.2.3 / current master.

gnupg 2.0 reached EOL - there won't be any fixes.

The install location does not have anything to do with that. I just always have my development installations directly under C: so that I can modify them without admin rights.

ok,
well I run "it" on Power Shell ( Debuggable Package Manager ) and I got ..

Do you mean that GnuPG installed to c:/gnupg/bin/ crashed if that mentioned --homedir is given but it does work if it is installed at the standard place? Please run "gpgconf --version" in both ways.

my <output> was the following...

All fixed (or marked fuzzy) except for master which will be done with the next merge from 2.2.

OK. I realized that msgfmt -c only works when #, c-format exist.
To check all problems, I did something like following for 1.4, 2.0, 2.2, and master:

Thanks for the report. It seems there has been this bug for four years.
I don't know the reason why msgfmt -c doen't show us the error.
Fixed in repos of GnuPG 1.4, 2.2, 2.0 and master.

1. exit gnupg software;
2. ctrl+shift+esc: end the process that starts with the 'GnuPG's ...' character~；
3. windows + r : %appdata%, delete ‘gnupg’ directory；

Debian has this with migrate-pubring-from-classic-gpg ( https://sources.debian.org/src/gnupg2/2.2.3-1/debian/migrate-pubring-from-classic-gpg/ )

Please open another report, not reusing similar. I don't think it's same bug.
Please note that GnuPG's ssh is not fast enough (intentionally), its rate is usually ten connections per second.

I'm seeing something quite similar - same setup, osx and it only shows when using ansible. I'm on gnupg 2.2.3, also saw same using "GPG Suite 2017.2".