Current state in gpg4win-5.0.0:

It seems this broke the self tests (and gpgme, and notmuch) on NetBSD: https://dev.gnupg.org/T8065

This is a security update

@werner I added an implementation https://dev.gnupg.org/D622
that matches Linux behavior and avoids the message about secure memory not being supported on Windows. The change is scoped to the pinentry tool and intentionally follows Linux behavior. Does this approach look reasonable to you?

I think "O" is a better key:

We need to change the accelerator. Right now gpg-agent uses

I don't think that we will implement that any time soon. Today we too often require more mlock-able memory than available and in this case Libgcrypt resorts to allocating new memory arenas which are not locked. This is not as worse as one might think: the majro advantage with secmem is that a free() on secmem allocated memory will also wipe that memory. A better solution has always been to use an encrypted swap/paging file. 25 years ago, it was not easy to configure but today there should be no problem and hopefully already the default.

While key generation works now with an expiry date up to 2106-02-04, the representation on the command line is a bit ugly.

On 2026-01-20, I found the message to security@gnupg.org of:
Message-ID: 4e708880-04ac-45bc-8d16-6b585f2652a1n@aisle.com
in may spam folder. It has a 10MB long attachment. That might be one of reasons to be identified as a spam.

Considering the current implementation (tpm2d doesn't support keyinfo like scdaemon), it would be good to check the buffer size.
(If key information is accessible easily, we can check with a specific key.)

Looks good to me on gpg4win-5.0.0 @ win11. Tested with 20 starts of each combination:

• with / without keyboxd
• quitting kleopatra / killing all processes

I think this has been resolved in Gpg4win 5.

Will be in the next release.

it does not make sense to have a workboard item for this parent ticket.

Looks good to me on gpg4win-5.0.0-beta479 @ win11:

This does not happen any more, tested with Gpg4win-5.0.0-beta479

Tested with Gpg4win-5.0.0-beta479

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

Given that the 2.2 fix has been tested and resolved and we don't have another ticket for 2.6, we can close this one.

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.

So why are there different grades of failure? Why is "invalid packet" a less scary error message than "WARNING: message was not integrity protected" when both are equally bad things?

Right. And the MDC detects this and only if says okay you get a good decryption status back.

This warning shall only show up if a message was really modified and not in case of

a simple truncation.

(Testing for now for better visibility. Real or Semi-real bugs with fixes are already set to Resolved)

The described attack is not easy to understand and as of today the
gpg.fail website seems to have the same content as the draft we
received on 2025-10-23. There it states:

Fixed in 2.5.16

Also fixed in the other active branches.

man gpg has a WARNING section right below the RETURN Value section. The 3rd paragraph gives hints on how to use gpg with scripts etc:

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 :-(

Note using the output of --decrypt directly on the tty is a Bad Idea(tm). You won't cat arbitrary files to your tty for the same reason.

https://gnupg.org/blog/20251226-cleartext-signatures.html explains why we have cleartext signatures and how you properly use them. The suggestion of the reporters to remove them entirely is a no-go because there are too many systems (open source or in-house) which rely on that format. If properly used (i.e. using --output to get the signed text) there is no problem. Anyway the suggestion has always been to use detached signatures using two files or PGP/MIME).

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

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: