FWIW: It does works when using GNUPGHOME instead.

There are three (or more) remaining things:
(1) ec_addm can be improved by adding U and V with mpih_add_lli , subtracting P with mpih_sub_n, and adding back P with mpih_add_n_cond
(2) Places with mpi_const for the argument when calling ec_mulm, ec_add or ec_subm should be fixed (it may modify the const MPI)
(3) make sure mpi_resize within ec_addm, ec_mulm, or ec_subm if needed

This seems to be the case on 2.2.46 as well, fwiw. i don't think it's new in 2.4.7.

similarly, gpgconf --homedir /tmp/gg --kill all does not terminate keyboxd, despite the fact that gpgconf(1) says:

Done

Re-opening because I think rGaa36f6ae8bae needs to be backported to GnuPG 2.4 (see T7568). The fix for T7309 which introduced the regression has been backported to GnuPG 2.4.

Duplicate of T7457. Sorry for the noise.

I've offered https://github.com/bestpractical/gnupg-interface/pull/16 to GnuPG::Interface, and am testing it out in debian unstable.

I'll work on making a patch to offer a flexible test suite.

Alternately, i suppose we could ask GnuPG::Interface to drop the variant parts of that test entirely. @werner, If you have a preference for what they test, it would be good to know. I suspect your opinion would carry weight with the maintainer there.

Well, we also have the gpgme test suite which tests a couple of other things and for obvious reasons we need to keep this stable. Granted, sometimes we had to change the gpgme test suite as well. My personal preference would be your second choice.

Thanks for the fix for the double-free on --no-sig-cache, that appears to be an issue on all released gpg versions, as i can crash them directly when i --no-sig-cache.

I think it's not exposed in the user interface. You can manually set it by adding

CMS disabled? Where can this be set?

Here is update (replacing ecc-no-normalize-2025-03-07.patch).
ec_subm and ec_mulm are modified to be less leaky.

Hello Eva,

The beta145 Werner talks about can be found here: https://www.gpg4win.org/version5.html
It is from our master branch which is not de-vs capable at this time.

Interestingly, from this i'm learning that the patch actually *normalizes* the output so that we see the same thing regardless of ordering. the different output based on certificate order happens only in the unpatched version.

Please test without the --import keys.pgp -- just import filtered.pgp or filtered2.pgp.

I can't replicate your findings here . In a test directory w/o a gpg.conf:

Hello Werner,
thank you for your support ...

Uihhh

with --no-sig-cache --check-sigs i get the following error with the patch applied:

We investigated this a bit and it only happens when trying to sign with a non VSD key when gnupg is in VSD mode

Something went wrong during signing - the question is what.

Did you also tried with --no-sig-cache ? That could help to get a better insight into the reason for that difference.

OK, now i really don't know what the issue is on the 2.4 branch. trying to replicate it with and without this patch, the --with-colons output of --check-sigs appears to depend on the order in which the certificates were ingested.

hm, digging a bit further, i think the above changes have to do with third-party signatures using SHA1, *not* with expired certifiers. in 2.4.7, i see a change from % to ! for these certifications. (2.2.x, which i know is EOL) shows the difference between ? and !. I'm trying to make a simpler replicator now.

Please test using the latest gpg4win installer (beta145).

Backported for VSD 3.3.x / Gpg4win 4.4.x

With the patch "gpg: Fix regression for the recent malicious subkey DoS fix", there is a change in how gpg --check-sigs reports certifications from expired keys.

it would be great to include a test in the test suite that ensures that the --status output behaves as expected in the face of expired or revoked keys.

tested with version 4.0.0.250370 (Gpg4win-5.0.0-beta125): no pop-ups

After testing the feature again with Beta 5.0.0-125 I repeat myself: this works.
There is the action "Unblock card" for unblocking the card with the rest code / PUK.

I think that major signal sources for K have been killed so far.

rG25d48663f9 seems to fix this for me. However in my test cases I got a hang in dirmngr simply by running several gpgsm instances to get the details of an X.509 key. I had different logging options enabled, though.

Please use "unbreak now" only for *released* software with a criticial bug.

Thanks for the report! That's indeed a regression introduced by the changes for T7527: Keyring/keybox denial of service. Commenting/Removing line https://dev.gnupg.org/source/gnupg/browse/master/g10/getkey.c$343 seems to fix the regression, but (very likely) this would reintroduce the issues reported in T7527: Keyring/keybox denial of service.

whether you use --pinentry-mode=loopback or --pinentry-mode=cancel or --pinentry-mode=error, if gpg-agent has cached the password already, the decryption will work; otherwise, it will fail with an error like that describe above.

here's an example of no prompting at all using --pinentry-mode=loopback:

This is also causing problems with ostree, see https://bugs.debian.org/1098951 and https://github.com/ostreedev/ostree/issues/3386

I remove the milestone tag, as that one means "fixed in version 2.2.46" and added the general gnupg tag

The same effect seems to be happening on signatures made from expired keys.

works as described.

The certificate can also be downloaded from https://www.bsi.bund.de/DE/Service-Navi/Kontakt/smime.html

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.

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.