gpg --version?
gpg -K?

In T7639#202620, @timegrid wrote:

If this should also work in gpg4win-5.0.0-beta336 @ win10 (beta compliance mode), it does not:

In T7610#202487, @timegrid wrote:

• compliance note in sign/encrypt next to sign/encrypt button (both for file and clipboard) unreadable in black/nr1/nr2 and also in dark mode:

In T7610#202487, @timegrid wrote:

• compliance note in sign/encrypt next to sign/encrypt button (both for file and clipboard) unreadable in black/nr1/nr2 and also in dark mode:

In T7594#202471, @timegrid wrote:

Shouldn't the enabled close button in win10 / disabled text / nr2 have green color? (it's the "search certs on server" dialog).

In T7232#202509, @timegrid wrote:

With above configuration it seems to work on gpg4win-5.0.0-beta336 @ win10.
Any way to verify in kleopatra, that the setting was applied?

In T7394#202514, @timegrid wrote:

• Kyber algorithms display only their ecc part

I guess that the missing formatting of fingerprint or key ID isn't restricted to v5 keys. -> separate ticket

In T7345#202503, @timegrid wrote:

• Some/Most "Not VS-NfD compliant" notes do not have the (beta) suffix (probably fine?)

This also happens on Linux. And even with the Fusion style.

Thanks for the Windows 11 screen shots.

Regarding the "unsure" findings:

• invalid state in cert list tooltip (red on black)

This will never happen on stock Linux.

This is more a technical ticket. There's not really something to test. Setting to Resolved/Done as discussed with ebo.

Most issues with icons in high contrast modes (of Windows 10) should have been fixed. Needs to be verified especially with the high contrast modes of Windows 11.

Setting to Testing.

Moving to QA. All changes should be in the latest beta.

Many issues have been fixed. Setting to Testing to check what I have missed.

The problem with the invalid certificates seems to be unrelated. Isn't there already a ticket for Okular for certificates which expire after 2038?

And in the first case, about 6 seconds are lost starting keyboxd:

2025-06-23 13:16:55 gpgsm[3252] DBG: chan_0x000000000000022c <- VERIFY
2025-06-23 13:16:57 gpgsm[3252] Kein aktiver keyboxd - `C:\\Program Files\\GnuPG\\bin\\keyboxd.exe' wird gestartet
2025-06-23 13:16:59 gpgsm[3252] Warte bis der Keyboxd bereit ist ... (8s)
2025-06-23 13:17:01 gpgsm[3252] DBG: chan_0x0000000000000260 <- # Home: C:\Users\g10\AppData\Roaming\gnupg
2025-06-23 13:17:01 gpgsm[3252] DBG: chan_0x0000000000000260 <- # Config: [none]
2025-06-23 13:17:01 gpgsm[3252] DBG: chan_0x0000000000000260 <- OK Keyboxd 2.5.6 at your service, process 4748

The keylisting hangs ticket for Kleopatra: T6623

In T7658#202206, @svuorela wrote:

@ikloecker is https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commitdiff;h=f23cef6f66a44c5c1cc8717f74b658d14fde04e5 needed to be forward ported to split gpgmepp ?

Can be tested with next VSD 3.3.x build.

In T7212#201964, @ebo wrote:

Why are there 2 buttons for (probably) the same thing: "Default Appearance" and "Defaults"?

I have added the changes/patches to the vsd-3.3-branch of gpg4win

If Kleopatra is already running then running

• kleopatra --help shows the help in a window
• kleopatra --help-all shows an error
• kleopatra --version, kleopatra --author, and kleopatra --license open the About window

Parts of the changes made for T7183: Kleopatra: Reduce certificates offered in Sign/Enyrypt dialog have been reverted. The drop downs for selecting the signing key and the "encrypt to self" key now offer the primary user IDs of usable keys again (instead of all user IDs of usable keys) and there's no button to open a certificate selection dialog anymore.

I started Process Monitor only after Kleopatra hang so that I cannot find out which process started gpg-connect-agent.

Log files for above deadlock

I just had another hang.

In Kleopatra we explicitly trigger a re-reading of the smart card after each operation involving a smart card to ensure that Kleopatra doesn't show wrong information. There's so much that can go wrong with physical smart cards that this is the only way to make sure you don't tell the user lies. I think gpg --edit-card also re-reads the smart card after each operation.

There is no bug in the contexts and there's nothing to document anywhere. If anything then it's a bug in gpg's generate command or a more general issue (in gpg-agent) with keeping track of the storage location of private keys as I have already explained in T7620#200613. I'm removing the gpgme tag because there's nothing wrong in gpgme and there's nothing we can do in gpgme. It needs to be addressed in gnupg.

Let's have a look at the section of RFC4880 linked by the reporter:

A User ID packet consists of UTF-8 text that is intended to represent
the name and email address of the key holder.  By convention, it
includes an RFC 2822 [RFC2822] mail name-addr, but there are no
restrictions on its content.  [...]