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:

Hi All,
Have you got chance to look into this issue.

@werner For rCd5e3cbfd , my mingw (GCC version 14) complains about the function-return-type difference of the prototype with GetProcAddress.

That RFC is Experimental anyway

Fixed and backported for VSD 3.4.

Ranking as discussed with @ebo

The root cause is that opening the details reloads the certificate. This triggers a change of the key cache. And that triggers are reload of the group.

This also happens in vsd 3.3.2 and gpg4win-5.0.0-beta413 @ win11

Scute fixed in rSc3dc9c581631: w32: Use CSIDL_COMMON_APPDATA if available.

Additionally to the fix Andre cited years ago, we also did some more changes recently in regard to how signed/encrypted mails are shown. Which are relevant for the inbox, too.
This issue should be fixed.

Here is my proposal:

It would be possible as a workaround in Kleopatra to show any identical entries only once. Saving after that will not add any more entries.

Okay, forward porting that patch is the easiest solution. Actually this is not enough: Users of Libgcrypt also need to make sure that the new sysconfig dir has the right permissions. That's a part for the installer and concrete ACLs may differ.

Good catch. My guess is that get_uid_for_sender returns the last matching UID without checking for revocations. The matching was done on the mailbox part only. For reference:

Here is my analysis.

I can't reproduce this on gpg4win-5.0.0-beta413 @ win11.