Are you using pcscd (is that process running) or the internal driver.? Please try the latter if you are not already using it.

The code has comments why we do a first clean_key on the imported keyblock.

I wonder why the flags can't go into CC_FOR_BUILD.

The problem here is that trial decryption may cost a lot of time because of the passphrase KDF function which, on purpose, takes long. There is one exception: A simple S2K (algo 0) takes no time and its use makes sense iff the passphrase has been created directly as a random string. However, I do not see the use cases for of a set of many passphrases compared to just use public key crypto.

In fact this specific scheme of indirect access to pthread objects is there to minimize dependencies of libgpg-error. It makes cross-compiling a bit harder but that is anyway the case because you need to check a lot of things for a new platform.

Please STOP adding such bug reports or feature requests. They are not helpful and such discussion are better done at the mailing list. In case you want to spend money to speed up things you may contact gnupg.com for a quote.

It is on on my private todo list but thanks for opening a puplic issue for tracking.

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.

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

Last week:

• Office work
• GnuPG 2.2.17 release

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

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.

@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.

Check out the mailing list gcrypt-devel@

Sure it is not validated. Standard clients do not provide the system features to do that. That is one of the problems with DNSSEC adoption - it works only for servers in practice.

@gniibe: I doubt that your fix really makes a difference. The majority of time is spend on searching the keyring for keys. This is why I have the gpgk thing in the works.

Release done.

I did this already on July 3 with commit 458973f502b9a43ecf29e804a2c0c86e78f5927a

You probably have one of the spammed keys in your keyring. This is a problem with the keyserver networks. Do not use --auto-key-retrieve and avoid using the keyservers until we provide a mitigation with the next gpg4win/gnupg release. See also T4591

Using several python versions?

Sorry for that

Last week:

• Changes to mitigate the SKS server DoS
• RC for 2.2.17

Because this is a GPGME bug.

That is a limit for the web key service to publish a certificate. IIRC, Debian developers do not use this but Debian creates the WKD from a database.

I think we should not backport this to 2.2 - okay?

Quiet tricky to get right; needs some rework.

Done for master and 2.2.

Not sending the user id packet, is just a bad idea because that user id exists and from my understanding they are sending the self-signatures anyway. They should not try to argue with the GDPR here, that is privacy theater. The key itself is a personal data and due to technical reasons this data is required. What they can do is to accept only user ids which carry just only mail address and no comments or name. posteo.de for example requires this for years and the WKD drafts has a feature to support this.

You are right. I again mixed this up with gpg-wks-client. Over there we have a limit implemented unsing --max-output to avoid compression based attacks.

Given the recent problems with the keyservers, I expect that the keyserver feature will go away anyway and thus I do not think we will put any more effort into this. Thus I re-tag this as gpg 2.3.

And of course, thanks for your fix.

Applied to both branches. I have run no tests myself, though.

Fix will be in 2.2.17

Fix will be in 2.2.17.
See T4612 for the revocation case.

Re 1.: I don't view this as a bug. gpg prints stats on what it has been done and clearly it has processed a key. If it would have imported the key you would see another stat line telling about this. There was however a bug in the stats output which has been fixed.