They can't agree on a common ciphersuite. The reason is that the server does not support any CBC mode. Which is a bad idea because CBC is still a very common cipher mode.

Ping?

Okay, so the open task is to build gpgme with MSVC in a way that different libnames are used and that we can distribute them along our standard DLLs? Given the easy we can now ssh into Windows there won't be a need to Wine things.

Well in my browser (Firefox) the dialogs are not rendered correctly. Here are the two dialogs in the terminal:

That is probably not what you want but at least it allows to import your key

One issue with this is that Qt Webengine (chrome) cannot be built with mingw. Fixing that would be a major project.

High priority and half a year no action....

back from vacation so apologies for the delay. @werner This is reproducible on the command line without Kleopatra. So maybe something for you our Gniibe to look into?

GnuPG invokes its components always with their absolute file name. We want to mitigate attacks where malware creates a pinentry wrapper somewhere in an improper set PATH.

I have mentioned it several times in the past that I would like to see the search by user id feature be removed from keyservers so that there is less incentive to use them as a perpetual and searchable database for maybe illegitimate data.

I see no need for this.

Keyserver issues are always hard to analyze because the state of the servers and which server you get is always a factor.

Sorry for the delay, I was on my summer vacation ;-)

Werner: I'm assigning this to you. Because the underlying reason is a missing status from gpg. I think we should add that for 2.3 as any new status line tends to break things.

can you please open the console (cmd.exe) and do a "gpg -K" and "gpgsm -K"

@joaociocca Can you please try to update to Gpg4win-3.1.9 and try again.

To be clear, this would allow the least competent CA in the system root trust anchor list to certify an arbitrary server as a member of hkps.pool.sks-keyservers.net. So it is in some sense a security vulnerability -- it allows for a bypass of the correct authority.

I've just pushed 1c9cc97e9d47d73763810dcb4a36b6cdf31a2254 to the branch dkg-fix-T4593

Note also that some keyservers like keys.openpgp.org will distribute only verified self-sigs (including revocations and subkey updates) without distributing the floodable third-party certifications. We can and should distinguish "updates-only" keyservers from discovery-by-address mecahnisms.

Just importing a ~666KiB certificate when this monster certificate is in the keyring consumes over 10m of CPU time:

Verifying a git tag from the "clean" version of this certificate takes ~225ms of CPU time. Verifying the same git tag from a keyring that contains the flooded version of the certificate takes ~145s. This is factor of more than 600×. Any automated git tag verification system can probably be DoSed by this behavior.

I didn't mean to suggest that switching to sqlite was the only way to fix this, but if it is a promising way to fix it, that would be great. I'm sure there are other ways.

I recognize that adding network activity to the test suite can be complicated (not all test suites are run with functional network access), but if it is possible to have a unit test or something (that doesn't do network access, but just looks at what the dirmngr *would* have tried somehow?), that would be great. Thanks for looking into this!

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