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

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

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.

I tried to implement this but this is troublesome for other programs using the interface because a common patter is to use --search-keys to get a listing and then use --recv-key to import the keys - That won't work and will require changes to --recv-key too. Thus this change will not go into 2.2. Anyway, it is not dangerous to have --search-keys because the new default for import from keyservers will be to strip all key-signatures.

Well, I mixed this up. On sending a a new key to the server export-minimal is used. Receiving a key uses keep-uid=REQUESTED and a 64k limit.

Because we use dot-locking in GnuPG and copy-update-write for keyrings. Granted: For gpgv this is not required but the code is identical to the gpg code and adding new code does not make much sense. After all gpgv is a stripped down version of gpg I once wrote for Debian. I see your use case but tehre are other ways to do this and thus anthing here has low priority.

We need random access and the name of the file. Thus a file descriptor is not sufficient.

Indeed we are in urgent need for a timestamping service. I was already pondering with the idea to integrate existing X.509 stamping services into OpenPGP signatures. Please write to gnupg-devel if you want to reach a wider audience. Unfortunately I need to abstain for getting involved in your project; there are too many other things to do.

One reason is that you may want to look at older key- or self-signatures which import-clean removes. I can imgine use cases where this has been used for something. People are ofteh doing inetresting things with standard tools.

I agree for keyserver imports. For all other imports this would be a severe regression and thus the wrong thing to do.