In T8048#211860, @ikloecker wrote:

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

It also happens on CLI:

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

• gpg4win 5.0.0 @ win11

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

I have not checked but I guess that the certificate is marked as ephemeal and kleopatra either lists ephemeral certificates or the ephemeral flag got removed to to a validation process,

Note: This does not happen on vsd-3.3.4

Fixed and backported for VSD 3.4

None of these certificates are for qualified signatures.

Try compare with a gpg4win 3.latest.

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:

gpgme.log (vsd 3.3.4):

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.

Fixed.

Another possibility would be to just add a revoked column (expiration date is already shown) to keep closer to the ldap schema.

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.

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

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

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

On gpg4win-5.0.0 @ win11 I created a bunch of smime certs:

• For each keyusage
  • keyEncipherment, dataEncipherment
  • digitalSignature
  • nonRepudiation
  • digitalSignature, nonRepudiation
• Alice's certs with different names, Bob's certs with same name for each key

Is this is good enough or should the import cert list also inherit the layout (with or without additional columns) from the currently active tab?

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

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

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

Another correction: I'm quite sure, that changing the width worked for a while (until i created that new tab), but I can't reproduce this anymore (even after deleting kleopatrastaterc). Now the import list again seems to have it's own memory (changing width in the import list will be kept on the next import)

Correction: On import, the width of the last created tab (not the current one) will be used, but additional columns won't be added.

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 gpg4win-5.0.0-beta479 @ win11

• I can confirm, that a new tab will inherit the layout from the currently active tab
• On import
  • The layout of the main tab is kept
  • The import cert table has it's own layout though (default columns/widths) - should this be different?
    

In T7455#211465, @timegrid wrote:

Notes:

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

Mostly looks good to me on gpg4win-5.0.0-beta479 @ win11.

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

Was anything changed? What to test here?

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

Am I right that for VSD we use:

We set the following organization names for the different products:

• Gpg4win: Gpg4win
• GnuPG-Desktop: GPD
• GnuPG-VS-Desktop: VSD

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

Thanks, looks good to me:

• Saving to c:\windows
  
• Saving with removed signing key
  

On gpg4win-5.0.0-beta479 @ win11 the registry settings are not read due to the organization name not set.

A way to trigger some errors could be trying to save to c:\windows or some other place you can't do.
Or while you have the key list open in okular, remove the key underneath everything and then continue.

We now have a filter for qualified signatures if there is any in the list

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: