testing with 2.5/2.6 will wait for special build

I am using that version and key daily. No problems seen.

with Gpg4win-5.0.0-beta479 the listing after creating the new key with ADSK looks ok now:

That was also fixed in gnupg 2.2.50 and thus vsd 3.3.3

That was fixed with 2.2.52 which fixed a bug in the fix done in 2.2.50 (see rG31fef13df1). Note that 2.2.48 to 2.2.50 had only internal releases.

Okay, let's backport this.

Note that for exploiting this bug a second preimage attack for SHA-1 is required. This kind of attack on SHA1 is not yet possible.

In Gpg4win-5.0.0-beta479 the dialog no longer exists. Problem solved ;-)

works, with Gpg4win-5.0.0-beta479 on Win11.
Now after hitting "save" a dialog is shown asking under which name the file shall be saved. Saving works with both options.

It looks similar if the key is in a WKD: First search fails without error, only "no certificates found" is shown. Clicking "Search" again results then in the expected key being found and shown.

Looks good to me on gpg4win-5.0.0-beta479 @ win11.
I can't reproduce ebo's nor pl13's issue.

That'd be great if possible, thank you!

Thanks, I'll use even-numbered minor checks against the tags "gnupgXX_ver" in https://versions.gnupg.org/swdb.lst

Please use the the swdb.lst which has all the version info. The website is actually build using this info. Well, except for the README file in the FTP section. I will update that too.

new export option keep-expired?

Thanks for reporting. Will be fixed in a few minutes.

You mean ask ldv to renew it? Sure, can do, but we often want to check sigs that were valid at the time but are now expired (sometimes upstreams are not reachable anymore).

Fixed in 2.5.16

What about prolonging the expired key?

Also fixed in the other active branches.

The int-truncation change breaks other things. I noticed this by chance in the interactive mode due to warning noticed. Before we ever do such things again we need to have regression tests for setting preferences. Or manually check everything. Need to do a 2.5.16 tomorrow :-(

We need to explain and debunk this attack after its publication,

Regarding the cleartext signature please see this piece: https://gnupg.org/blog/20251226-cleartext-signatures.html

works in Gpg4win-5.0.0-beta476

This has likely a similar cause as T1794

I have been able to reproduce this on linux with gnupg 2.5.14.
I had two users (named Alice and Bob in the example), each generating a key pair.
These are the steps:

• Both users have the "use-keyboxd" option in their common.conf (i could not reproduce the bug without this option)

Yesterday I was able to reproduce it once. But despite more than a dozen more tries yesterday and this morning, I could not anymore replicate it. I tested on Unix and one oddity was that I forgot to kill the keyboxd for a clean new test and thus it could serve old keys despite that the pubring.db was already deleted (but the inode still open by keyboxd).

This relates to T7917: Check for revocation of the ADSK's original subkey

The expected behavior is that only "Ted" (the key from where the ADSK originates) is listed, regardless of ADSKs, on every listing.
Because for regular keys there can only ever be one, "gpg -k" shows always only one key.
Subkeys which are ADSKs shall therefore never be listed with this command.

Tested with Gpg4win-5.0.0-beta446, identically to the procedure from the description:

It's mostly obsolete. With T7874, GetThreadUILanguage is used instead of GetThreadLocale if no locale/language related environment variables are set. GetThreadUILanguage returns the configured display language.

This was resolved some at time in the past

Is this ticket obsolete with T7874: Kleopatra: GnuPG System configuration not translated?

Is this testable?

should be fixed/tested for v5 release

This should better be fixed in the v5 release

we haven't seen this in a while…

gpgrt 1.57 will come with gpgrt_fconcat. This can be used to get the sysconfig in a portable way: