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.

All my keys are RSA 4096. It worked fine with OpenPGP smart cards and with two Yubikey 5. On all devices a set of RSA 4096 keys were geneated on the device itself. Only one card failed. But even the card which failed, generated at least the signature key in RSA 4096.

Please let us know what kind of key and how large, like RSA-4096 or ECC Brainpool.
For RSA 2048 or larger, yes, it takes too long.

Thanks.
Merged (with line break in the Makefile.am and formatting of commit message.

I mean, if all SKESK packets should be tried, we need some larger surgery of current implementation.

Is it possible for your application (DOTS), to specify the packet number for SKESKP, not trying all SKESK packets?

i've merged a variant of rGbe99eec2b105eb5f8e3759147ae351dcc40560ad into the GnuPG packaging in debian unstable as of version 2.2.17-3 to avoid the risks of data loss and signature verification failures. I'll revert it if i see the concern addressed upstream.

@gniibe, thank you for backporting this to STABLE-BRANCH-2-2!

I don't know why dkg-fix-T4641 is not showing up here on the assuan git repo.

@dkg You are right. The term "issuer" was too ambiguous.
I like your proposal and would try to implement it. However, "export" of dkg-keycheck and other programs from DKGPG are very limited.

But that's exactly my use case in DOTS: an easily to create 'decryption puzzle' (including the hardness of iterated and salted S2K) for the serving party in order to make DoS harder. I don't see how public-key crypto can help here. Moreover, I would keep the user interaction as cheap as possible, i.e., copy'n'paste an ASCII-armored message and passwort to GnuPG without importing public keys etc.

I've just pushed rA45f01593d4ce794ae3562359aee2ff80c97e368e to the dkg-fix-T4641 branch that resolves this.

Thanks for the feedback. I'll go ahead and close any tickets that come in via debian that expect to be able to cross compile without having at least once had a native compiler on the platform to generate the appropriate lock-obj-pub-*.h.

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.

I should may add, that on the card which failed, only the signature key was generated and written to the card. The authentication and encryption keys could not be generated..

@gniibe Thanks for explaining the background. Are there any ideas for fixing? (e.g. the decrypted content could be checked for a valid packet structure or at least for starting with a valid packet header)

@stm it kind of is a last-resort already, given that it's only in the event where the signature creation dates are equal, but sure, i wouldn't mind adjusting the proposal to say that (sigs) means "sort by date, then issuer, then binary content" -- but what do we think "sort by issuer" means?

does the removal of the gpg22 tag mean that it will not be possible to rely on colon-delimited output for the gpg 2.2 series?

Just a note that we're now shipping this patch in debian unstable. It would be great if it was merged upstream.

that pseudocode is strange to me -- it looks like you have (two) duplicate calls to clean_key (imported_keyblock) (though maybe i just don't know what .... means in this pseudocode).

It was rG07250279e7ec: * keyedit.c (keyedit_menu): Invisible alias "passwd" as "password". in 2004, which set default to rfc2440-text behavior.
And in 2007, the commit rGb550330067b6: * gpg.c (main): Disable --rfc2440-text and --force-v3-sigs by default. Enable… changed the default to no-rfc2440-text.

Thanks, fixed in master.

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.