VSD 3.3.0:

The button for "Encrypt to others" is gone:

Looks like scdaemon which I experienced today also but without having enabled scdaemon logging.

VSD 3.3.0: The buttons work as soon as the certificates are imported. (Depending on the card this will take some time)

One more change for _gcry_dsa_gen_k in rC54caef02afa9: cipher:(EC)DSA: Simply use mpi_clear_highbit in _gcry_dsa_gen_k.

One more change for mpi_invm in rCc1da86e45a6e: mpi: Avoid normalizing MPI in _gcry_mpi_invm.

Logs of a recent hang

VSD 3.3.0:

Haven't seen this in a while.

works in VSD 3.3.0:

VSD 3.3.0:

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.