i'm aware of the filters you're using, but they are not a principled response to this kind of certificate flooding attack. An attacker who wants to be really abusive can easily create certifications that bypass any import-filter gpg is capable of.

Confirmed; that looks like a regression.

We know that. The problem is that we can't simply switch to sqlite for key storage because it is common that dozens of gpg processes are accessing the key data base. At least at some points we need proper transactional behaviour and Sqlite implements that by talking a temporary copy of the database - not an option for large keyrings.

I know this problem very well and it let to the introduction the import filters. For example I can update my own key only using filters like

sorry to keep pinging this, but given the ongoing flooding attacks (e.g. T4591) and how SKS and similar keyservers are unable to safely transmit flooded certificates, i think this kind of fix is urgent if we expect gpg to be able to retrieve revocations safely. What's the status here?

Please see T4592 where i've reported this particular performance concern in more detail, including profiling data.

For folks who encounter this problem in the future, i recommend that you first check whether you have a pubring.gpg instead of (or in addition to) your pubring.kbx. If you do have pubring.gpg, you should be able to run the pipeline to the awk script described above with just the pubring directly, which omits the time-consuming gpg --export step above. so i think that would look like:

wow, 46MiB, that's even worse than mine. :( thanks for sharing the update, @jackalope. I'm glad you've worked around it for now, but sadly this kind of certificate flooding could happen at any time if you're using the SKS keyserver network :(

By golly, you were right, @dkg! I ran that "gross hack" (thanks so much for writing it) and after nearly 10 minutes got the output I needed. Last 5 lines:

Let me explain some technical detail for the record.

Because my fix was incomplete, I pushed another change to GnuPG master: rG374a0775546b: agent: Close a dialog cleanly when gpg/ssh is killed for CONFIRM.
I also pushed my changes to pinentry master: rPf6e84ce0a34c: tty: Confirmation is not by line edit mode., rP531b92300c58: tty: Support line editing by system., rPb176a8ac0dcd: Exit the loop on an error with GPG_ERR_FULLY_CANCELED.

That's a great question, @jackalope. I found this in a different misbehaving keyring recently by basically deleting keys by hand until only one was left. surprise, it was mine (ugh)! But that process is pretty slow and manual and tedious. Let me see if i can do better.

Good to see you here @dkg, thanks for the response, and whoa, that's quite something!

@jackalope, the place where the output is hanging is likely due to output buffering (i have been able to replicate the same problem, and the output hangs at intervals of 8192 octets). So while it is giving you a clue about where the hang is, it's not a very precise clue.

Thanks for the feedback, @werner. I think I understand the reasons that we've gotten to this place -- but that doesn't mean i think it's ok to stay here. In this bug report, i'm pointing out that the documentation and the feedback/error reporting is misleading, which leads to difficulty in debugging. We need to do something about it.

pinentry-gnome has no grab support. However, it needs to accept that option so that gpg-agent does not error out. We want to have the same global options for all pinentries. Whether they work depends on the pinentry and other parameters. For example when falling back to curses grab won't work in any pinentry.

Great :-)

Thanks a lot. I was not careful when I updated.
Along with the error you addressed in the patch, I also found another.
All fixed in rGf05fd37266f5: po: Update Japanese Translation..

I've encountered the same problems that the original poster has described; the problems started suddenly on June 24, not prompted by any related updates as far as I can tell. The problems occur with both gpg 2.1.18 installed from the official Debian Stretch package and 2.2.12 installed from stretch-backports.

I note that this is likely happening because we are using gcr's system-modal prompter. I haven't looked into whether it's even possible to use gcr in a non-system-modal way, but i'd welcome pointers.

It looks like this commit breaks the build by me

Although sometimes useful, reports about recent changes to the repo should not be filed as a bug report. You may comment on the commit itself, though.

For the record in my original message I asked about adding self-signatures.

I meant, GnuPG side was fixed in master, it sends SIGINT to pinentry process when gpg exits.

Ah, yes, that signal thing should be handled correctly, when we support line edit by tty.

Thank you. I just downloaded the source for pinentry-1.1.0 and changed this line:

(What you see as the link addressed in 2015 is for pinentry-curses, which is irrelevant.)

Whoops, looks like it, sorry for the noise.

i think this might be a duplicate of T4496

I see. Thanks for your explanation.

I'm unlikely to put a windows-specific patch into the debian source, as
i have no good way of testing it, and it wouldn't affect any binary that
we ship.

I see. Thus the problem is that IPWorksOpenPGP does not create proper OpenPGP private keys. I guess they use OpenSSL with their different CRT parameter style and do not convert them correctly. RFC-4880 says this in 5.5.3:

The secret key is this series of multiprecision integers:
o  MPI of RSA secret exponent d;
o  MPI of RSA secret prime value p;
o  MPI of RSA secret prime value q (p < q);
o  MPI of u, the multiplicative inverse of p, mod q.

It's been a while, any word on this? I sent the DCO as requested. Are there any technical concerns left to address?

I just received answer that this is still a problem in the current release.

@dkg: Please keep using slashes. The problem was that slashes are not allowed in git config keys. We use the branch name in some git config keys and thus they need to be mapped to soemthing different (ie. '-').

Thanks for your review.

It works for me.

@dkg, for your patch, it can be improved for Windows by using its event mechanism. You can see gnupg/scd/scdaemon.c.

Hm, T4521 suggests that the two different cases should not be treated differently. If you think that they *should* cause distinct behavior, please do mention it over there!

There are two different cases: (1) By SIGTERM and (2) By KILLAGENT. It's true that the agent stops accepting on the listening socket for (1), but it's not the case for (2).
This particular problem is for the case (2).

Werner, I interpreted jwilik's patch as admission of a problem from upstream, and reported it as such to CVE. I felt that since this does not effect the main platforms (ARM and x86_64) it would not be a big deal. If I interpreted wrong, I am sorry.

I assigned the CVE, but yes it needs more facts.

Andreas, I wonder on which grounds you assigned a CVE for this claimed side-channel attack. The mentioned paper is about an old RSA side-channel and not on AES. I would like to see more facts than the reference to a guy who knows PPC pretty well.

The gpg --version shows:

Which Libgcrypt version is used (gpg --version shows it).

This bug has been assigned CVE-2019-12904. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12904

I will work on OCB mode, eventually. Perhaps you could review what I have, but leave T4529 open until OCB mode is completed.

@gniibe, thanks for the diagnosis! I agree that restarting or shutting down the backends should be done in the reverse order as a simple workaround.