VSD 3.3.0: OK.

ok in VSD 3.3.0, too

I don't see a bug here and any change in this domain disks a regression with existing data. BTW, the mode byte was not even part of the signed data before signature version 5.

My comment from a year ago still holds true; you may want to fix your testing framework and re-openig this bug iff you can show that there will be no regression with PGP 7 and later.

Thank you @werner ! I can confirm that the patches that have landed on STABLE-BRANCH-2-4 do clear up the DoS i was seeing for signature verification.

The patch below fixes the master branch to be compliant with the standards for CSF message generation and verification.

New Situation
Once I started testing in logging mode the problem had gone away already. There were some hints to HTTPS certificate issues, but nothing really to blame. Neither with nor without logging the problem could be reproduced after two days of questioning me.

Also fixed for 2.4

This has been fixed in master with rG48978ccb4e:

Finally removed with gpgme 2.0

Closed after the release of 2.5.4

Right when you use a different homedir you also need to pass --homedir to gpgconf or set GNUPGHOME before invoking gpgconf. If you call gpgconf via GPGME the --homedir option is passed; afaics we don't have a kill option gpgme.

This even happens with native Windows applications thus normal priority. Users need to watch the taskbar for blinking items.

The caching works on the base of the requested domain, that is example.org and not openpgpkey.example.org - thus it should not make a difference when you change your setup. There is an initial test for a cached domain status before the resolving process starts. If you want to look yourself: gnupg/dirmngr/server.c:cmd_wkd_get() and domainfo.c.

Reproducibility
The problem cannot be confirmed generic on domain level. I can reproduce the effect with keys shipped from my domain, i.e. email addresses @shimps.de, but the issue vanishes when I try to reproduce it with email addresses @gnupg.org as e.g. Werner's address.

You have imported a certificate with secret key.

You have imported a certificate with secret key.

Fingerprint: XXX
User ID: ABC

Here are some ideas:

Well, the different outcome depends on the order of the certificates or the string comparision in keyboxd. So it is not a keyboxd vs. pubring.kbx thing.

Okay, I can reproduce it when not using keyboxd.

Also, we should not forget the context of the whole dialog in the window. So we get the wording right, especially regarding key / certificate.

Removed in https://invent.kde.org/pim/kleopatra/-/merge_requests/369

In T5780#195277, @ikloecker wrote:

For me the change fixes the problem on Windows. (I haven't checked if there was a problem on Linux/X11, but I have verified that the change also works on Linux/X11.)

This is very similar to T5780 except that it concerns a different operation and thus a different window. The fix is likely the same as for T5780.

We do support "Decrypt & Verify" for multiple files (including the presentation of the status) so that it would be easy to do the same for all files in a folder (question is if this should even be recursive). Digging into the history I found that the desktop file was added shortly before Kleopatra 2.0.0-rc1, but that there wasn't any code for iterating a folder, i.e. this can never have worked.

I can't remember that we ever had support this. It is also not easy to come up with the good way to present the status for all files in a folder. We would need to define a format similar to what sha1sum uses: A list of file with they signature file or so. Note that kleopatra has support for running sha256sum in such a way.

Sorry. I can't reproduce this. Neither with master nor with the 2.4 repo version.

We don't have this exact action on windows, but the normal "Decrypt & Verify" action shows up for folders there (and doesn't work either).

All changes are pushed to master.

Pushed the changes by the commit rC2039d93289db: mpi: Add MPI helper modular exponentiation, Least Leak Intended.