Thank you for the report. There was a problem in: rG845d5e61d8e1: dirmngr: Cleanup the http module.
Pushed the fix in: rG04cbc3074aa9: dirmngr: Fix proxy with TLS.

In master, I applied changes for include files which don't harm current target of MinGW-64.

It's true that under $GNUPGHOME (~/.gnupg/), there are multiple things: configuration files, user-specific data files (private keys, public keys, the trust database, and revocation certificates), user-specific state files (like the lock files and random seed), possibly runtime sockets, and executable/script for card reader. Some careful handling might be needed for making backup and doing version control for that.

Yeah I also signed all the binaries for the last Gpg4win release (4.2.0). I think we should support the case that only signed binaries are allowed on a system.

I guess that's what it is called. A person in the forum told that GpgOL could not be loaded in Outlook and saw that the signature is missing in the new version. But it was there in version 4.2.0. With the command Get-AuthenticodeSignature I could confirm that this is the case.

You mean the Authenticode signature? Afaics, only the gnupg files come with such signatures.

I have disabled update notifications for now. We can reenable them with the next Gpg4win release when we fix Kleopatra to again query for the Gpg4win version and not for the Kleopatra version. I am leaving this open to fix just that in Kleopatra. If you now go under help -> check for updates it won't show you an update anymore.

Will do. Thank you very much.

I give this low priority because in my view users should not initiate file encryption by launching Kleopatra. I still hope that most users should not even realize Kleopatra exists and only interact with it through the dialogs. Putting the action in the toolbar is also already possible through configure toolbars. I rather would find it more confusing to have two encryption buttons next to each other.

It works in 2.4.4 if you add

Giving this the same priority as the parent task.

@Jakuje, you are right. This is a plain error and we should do a new release to avoid false errors.

Thank you, applied.

Ah, sure that also makes total sense, I thought you wanted it disabled if it did not extend all subkeys.

So I cherry-picked this onto 2.4.4 and I ended up with a failing build due to failed tests (it built fine without the patch)

There is no Enigmail for TB anymore.

It seems I did not express myself clearly.
I would prefer it if the "with subkeys" checkbox could not be enabled in case it won't extend any subkeys anyway.
With a bonus tooltip.

You have to restart once. Then it goes away. We can't do much about this since we load the icons etc. at startup and don't have dynamic color changing. It might be better with the next Version which will update our UI Framework but no promises. I leave it open for now so that is a known issue.

Ikloeker is our resident accessibility expert and Kleopatra has a certificate for accessible software so I agree that we should not change it. Or is there a specific issue / condition for you that makes this extra hard to read?

For accessibility the contrast between text and background must be high. Therefore, I don't think we should change the color. In any case, you get what you asked for: A dark (green) background color.

In the Certificate Selection Dialog where the user controls the filter it makes sense to apply them also to key groups. The only question is how, i.e. with all_of or with any_of? I'm leaning towards any_of, e.g. if "OpenPGP Certificates" is selected then all key groups are shown that contain at least one OpenPGP certificate. This would also address my concern that key groups could be hidden if they contain an unsuitable key because they would only be hidden if all keys are unsuitable.

I need to investigate why this happens. Maybe we can as a workaround fix it on our server side without the need for a new update.

If things start unexpectedly you already went to the console to change it or already changed it in the subkey view. Otherwise it is too intelligent for my tase since I have subkeys for example with different expiry dates. But nearly all users won't have that. I think the current solution is good. But @ikloecker can you change it please to +/-1 one hour you are right that the time window is too short.