Please do not change the priority back. That is a maintainer's task. I consider this along with adding replicas of issues to a bit rude.

Please do not change the priority back without discussing this with the maintainer first. Thanks.

You are partly right. I missed that we also do clean the original keyblock while updating a key. The code is

I see. I am also mostly testing with ntbtls so I was wondering about the report. Thanks for reporting and fixing.

Current situation of *.pc: static linking is not supported (yet).
It has never supported, actually, by *-config.

While I understand incorrectness, the risk in practice is not that high. So, I put this as "normal" priority.

In the current implementation of GnuPG, multiple packets of Symmetric-Key Encrypted Session Key Packet are not handled very well.

Pushed the change to master as well as 2.2 branch.

I think dropping import-clean from the default keyserver options is the right way to go. It is not clear what additional benefit import-clean provides given that we are already using self-sigs-only. And the idea of non-additive behavior to the local keyring when pulling from a keyserver is a deeply surprising change for multiple users i've talked to.

The fact that import-clean modifies already-held certifications makes me think it is inappropriate to have as the default for keyserver access (see T4628 for more details).

Due to T4628, i no longer think that import-clean is a good idea by default.

I am proposing to backport rG33c17a8008c3ba3bb740069f9f97c7467f156b54 and rGa7a043e82555a9da984c6fb01bfec4990d904690 to STABLE-BRANCH-2-2 as they represent a significant performance improvement in several specific use cases and appear to have no downsides.

If you're on a platform that has awk available (any GNU/Linux and macOS should provide it), you can scan for the largest OpenPGP certificate in your keyring with an awk script i posted over at https://dev.gnupg.org/T3972#127356

How to find out which keys are affected?

You need to delete the flooded keys to make things go faster.

After waiting for far over an hour, Kleopatra read the keys. Now, things go faster (also in LibreOffice), but it still takes around 30 seconds, which is quite long.

gpg4win 3.1.10 did not fix this issue for me, neither in Kleopatra nor in LibreOffice.

The card frame works received a lot of changes in master but we won't backport it to 2.2. Sorry.

@gniibe, the documentation (at least on the stable branch) says that --fast-import is just a synonym for --import. is that incorrect?

Maybe GnuPG could display a prompt if it detects a pubring.gpg and no pubring.kbx. Something like:

I also tested it with Outlook 2010 and there this did not happen. So it's probably save to assume that this was a behavioral change in some more recent Outlook Version.

This was released 2019-06-15

Has been released and confirmed to be working.

Fix is in, will be released with 3.1.10

Fix is in. Will be released with 3.1.10

This is resolved

It turned out to be a downstream issue and the change in message class was enough from our side.

This is fixed.

This was fixed with 3.1.9

This should be fixed.

Testing with the DGN certificate showed that GPGSM returns a signature verification error (invalid digest algorithm) in this case. So the signature summary is not even checked.

Thanks for all the fixes! I can confirm commit dad35d65f05eb1c15589a7e4755dcae6aed2d6cf works just fine on all my machines (Linux & macOS).

About importing, there are two other works: repairing and trustdb update. We can figure out the difference by the --import-options of no-repair-keys and fast-import (to skip those works).
I think that both can be O(N^2) for number of signatures.

A linked list of 100000 items is not a usable data structure. The problem however is not the linked list but the DoS due to the number of signatures being well beyond the design limit. 1000 key signatures is already a large number and only few people have them. We need to put a limit on them.

with @gniibe's patches applied, i profiled the --import, since that is where the largest CPU cost remains. I tried two different times:

I disabled the dependency rules for the figures (it's only enabled for maintainers).

@gniibe: We move this issue over to mail. I'll forward it to you.

Okay, for 100000 signature this is clearly a win if no key lookup is needed.

Fixed.