In T8048#211860, @ikloecker wrote:

some other certificates, but I guess those are from other tests

Fixed and backported for VSD 3.4

I have this fix committed to my working directory:

We have no CVE yet. However, CVE is also a good tag for security bugs,

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.)

Fixed. The problem was that the selected sections were stored in the 64-bit registry (unless browser integration was installed; see T8038), but they were read from the 32-bit registry.

Fixed.

Let's give this Normal priority.

Meh! The installation of the browser integration explicitly enables the 32-bit registry. Obviously a leftover from gpg4win 4.

In T8039#211727, @timegrid wrote:

I wonder where the information of the previously installed components comes from, if not from the MementoSection_SEC_kleopatra fields.

Thanks for checking! So now we know why the line is missing. Looks like installing browser integration causes a broken installation (at least with respect to registry keys).

I searched the whole registry and found, that if browser integration is installed, this key still lives in WOW6432Node: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Gpg4win

Oh, surpisingly it's the other way around: if the information is given in the registry key, all components are preselected. If the key is missing (browser integration installed), only the installed components are preselected. I wonder where the information of the previously installed components comes from, if not from the MementoSection_SEC_kleopatra fields.

Without browser integrations installed, the preselection works fine though.
Probably this happens, because the info in the registry is missing as soon as browser integration is installed, see T8038: NSIS: Updating line omitted if browser integration is installed

should properly uninstall the existing installation.

Regarding 32-bit and 64-bit installers: The installer looks in both registry trees for the relevant registry keys, i.e. 64-bit over 32-bit and vice versa should properly uninstall the existing installation.

I understood that this is done on purpose, i.e. all other components are explicitly always preselected.

gpg4win-5 has no idea that gpg4win-4 is installed because the former is a 64-bit installer/application and the latter a 32-bit installer/application, i.e. they use different registry trees. More important that the missing "Updating line" is very likely that the gpg4win-5 installer does not uninstall gpg4win-4. I haven't checked if NSIS is capable of detecting/uninstalling a 32-bit application from a 64-bit installer.

Backports have been done in both (1.10/1.11) branches.

see also T8039: NSIS: Preselection of installed components on reinstall only works with browser integration installed

See the gnupg-devel mailing list for more discussions. Subject: libgcrypt P256 signature malleability via weak DER enforcement"

Fixed. Some examples for the improved texts which are based on the texts that gpg prints.

• good signature with expired key

• good signature with revoked key

• good signature with uncertified key

• expired signature with certified key

• expired signature with uncertified key

Indeed, it looks this way. Thanks so much! Windows 10 and 11 in my case.

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.

If only the secret encryption subkey is exported and there is a signing subkey then, additionally, to the secret subkey export a public export is added to the created file, i.e. in the created file there's a PUBLIC KEY BLOCK and a PRIVATE KEY BLOCK. (With the next version of gpgme the public key block only contains the primary key and the signing subkey. Currently, it's a full public key export of the team key.)

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

Some historic integer encoding glitches from Peter Gutmann's style guide:

Fixed upstream with https://invent.kde.org/graphics/okular/-/merge_requests/1301 - not yet in our packaging

@werner: gpg fails to batch import secret Kyber keys:

$ GNUPGHOME=/home/ingo/dev/g10/.gnupghomes/empty gpg --batch --import --verbose ~/dev/g10/testdata/exported/Kyber768_0xDD89C34EF2B69576_SECRET.asc 
gpg: WARNING: unsafe permissions on homedir '/home/ingo/dev/g10/.gnupghomes/empty'
gpg: enabled compatibility flags:
gpg: sec  brainpoolP256r1/DD89C34EF2B69576 2024-11-14  Kyber768 <kyber768@example.net>
gpg: using pgp trust model
gpg: key DD89C34EF2B69576: public key "Kyber768 <kyber768@example.net>" imported
gpg: key DD89C34EF2B69576/DD89C34EF2B69576: secret key imported
gpg: key DD89C34EF2B69576/D07DD3BF9F1AAF4F: error sending to agent: IPC parameter error
gpg: error reading '/home/ingo/dev/g10/testdata/exported/Kyber768_0xDD89C34EF2B69576_SECRET.asc': IPC parameter error
gpg: import from '/home/ingo/dev/g10/testdata/exported/Kyber768_0xDD89C34EF2B69576_SECRET.asc' failed: IPC parameter error
gpg: Total number processed: 0
gpg:               imported: 1
gpg:       secret keys read: 1

Importing the same files via cli does work:

Screenshots of different imports:

gpgme.log (import of kyber team key with signing key):

gpgme.log (import of normal non team key kyber cert):

Setting to resolved, as I think it should be

This is ready for testing and available in 5.0.0-betaX since about a year.

Thanks Eva and Ingo. It seems 2.5.17 is not too far away.

I can reproduce this on the command line:

C:\Users\g10code>"c:\Program Files\GnuPG\bin\gpgsm.exe" --export --armor 579BAF3DF16AD462457BCC0897ADBC143D76EA7B 5A2B80F98F518D50891B1F0C7C6131AD107F9938 DB625D2BBBB5A3FD985C0233249B03090E85D402
Issuer ...: /CN=CA IVBB Deutsche Telekom AG 20/OU=Bund/O=PKI-1-Verwaltung/C=DE
Serial ...: 02195D190EBE34
Subject ..: /CN=iOS Test-Smartcard iostest01.sc/OU=BSI/O=Bund/C=DE/SerialNumber=2
    aka ..: iostest01.sc@bsi.bund.de
Keygrip ..: 527CE32FD0552D18479442EF90DD5E434C036329

I can reproduce the issue only (!!!) with keyboxd (on Windows).