I suspect there's also a bug somewhere between qt and windows involved here: The overlay is supposed to be modal to the composer window, so it shouldn't be possible to move the overlay behind the compositor. This is probably the reason why the overlay is forced to stay on top in the first place...

there are no display warnings

Thank you for the concrete test case, it helps me.

NIST has an initial public draft for KEM: https://csrc.nist.gov/pubs/sp/800/227/ipd

Added the additional parenthesis and I merged it

looks good to me on gpg4win-5.0.0-beta190@win10

looks good to me on gpg4win-5.0.0-beta190@win10

on gpg4win-5.0.0-beta190@win10 (high contrast):

looks good to me on gpg4win-5.0.0-beta190@win10

looks good to me on gpg4win-5.0.0-beta190@win10

looks good to me on gpg4win-5.0.0-beta190@win10

It's in 1.11.1.

Included in 1.11.1.

In T3362#177192, @werner wrote:

Well, see my very first comment.

• We should make card-timeout work again
• For OpenPGP cards we could extend our magic login data (scd/app-openpgp:parse_login_data) to introduce the timeout @gniibe suggested.

I guess

alwaysTrust ? Context::AlwaysTrust : Context::None | (encryptionFlags() & ~Context::EncryptFile)

is identical to

(alwaysTrust ? Context::AlwaysTrust : Context::None) | (encryptionFlags() & ~Context::EncryptFile)

Well it kind of works but it is a bit ugly and the encoding in the "Encrypt" message is broken:

(2) Update the documentation of default-cache-ttl zero value disabling caching.

Propagate encryption flags in other places

I don't understand why we need to remove the Context::EncryptFile flag. It seems wrong/error-prone to propagate all but one flag. The caller shouldn't have set this flag in the first place. In other words: Remove the & ~Context::EncryptFile.

There are two other methods that also take alwaysTrust as input and that should likely also propagate the other encryption flags.

I think we have another report on this in the tracker. The problem is indeed the ugly Windows time functions to print a string. Let me only remeber that untile a few years, Windows had the opinion that Germany is the the Westeuropäische Zeit, i.e. Portugal or the UK.

That is quite possible because we do not have a test system for RISC-V and the make release tarbegt is not abale to verify this.

I am going to do:
(1) Recover old behavior with max-cache-ttl = 0
(2) Update the documentation of default-cache-ttl zero value disabling caching.

In T7620#200845, @Saturneric wrote:

I think it would be much better if GnuPG automatically performed a key listing immediately after key generation when a smartcard is involved. This would allow GnuPG to detect the presence of the subkey on the card right away, rather than leaving it marked as a stub until the user manually lists keys.

I see that you generated the secret encryption subkey with backup. This means that the secret subkey is generated on your computer, then copied to the card, and then deleted from your computer. The deletion is the reason why the subkey is marked as stub. Only after listing the keys on the card gpg notices that the secret key is actually on the card.

I found more issues with the success, warning, and error icons we show in various places.