With Gpg4win 5.0.0 the LISTKEYS after the server lookup lists the (ephemeral?) ca@gnupg.test certificate and (!) the bob@gnupg.test certificate (and some other certificates, but I guess those are from other tests).

1. VSD 3.3.4

1. Gpg4win 5.0.0

gpgme logs (also of vsd-3.3.4) will be useful.

Fixed and backported for VSD 3.4

The gpgme logs show that the information for revoked keys should be there. We just need to check for it (and somehow visualize it).

pub:o:3072:1:3DA05D6B0A5998AF:1768822823:1863514800::::::::
fpr:::::::::C70F6D8F32DFE96F5C47C40B3DA05D6B0A5998AF:
uid:o::::::::search (valid) <search@gnupg.test>\r:

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.

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

Fixed.

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.

I don't know how I'm supposed to change/fix this. Not even gpg does what the ticket wants (see the sub ticket). And gpg doesn't report sufficient information to Kleopatra via gpgme. In fact, gpg doesn't emit a STATUS_TRUST_* message if the signing key is expired. Hence, gpgme reports "unknown" validity for the signing key, so that Kleopatra would always print "The used key is not certified by you or any trusted person." for expired keys even if the key was fully certified before it expired.

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

Screenshots how Kleopatra currently shows the result of the verifications:

I think this has been resolved in Gpg4win 5.

I think this has been resolved in Gpg4win 5.

I think this has been resolved in Gpg4win 5.

The suffixes _ENCRYPT_SIGN and _ENCRYPT are used to differentiate the two export results.

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

In T7455#211465, @timegrid wrote:

Notes:

• The "Encrypt..." and "Sign..." operations might not be needed anymore now, that "Sign/Encrypt ..." is available?

I've changed this now to "GnuPG VS-Desktop" (and "GnuPG Desktop").

We set the following organization names for the different products:

• Gpg4win: Gpg4win
• GnuPG Desktop: GnuPG Desktop
• GnuPG VS-Desktop: GnuPG VS-Desktop

i.e. the registry path for Kleopatra settings will be for example
SOFTWARE\Gpg4win\Kleopatra\<config group>\<config entry>

@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

Backported for VSD 3.4

Done. I've used the following script to create clear-signed test messages with good/bad signature signed with certificates with different validity and status (expired, revoked).

All sub tickets are done.

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

Should be ready for testing. This is available in 5.0.0-beta479.

This has finally been merged.

In the meantime we don't show the imported certificates anymore in the main window as tabs but in a separate window, i.e. import tabs are no longer an issue. Please retest.

I'm pretty sure that this is done. For gpd5 the changes have been merged upstream and kconfig reads the config keys in the desired order.

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