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.

This is referenced from https://nvd.nist.gov/vuln/detail/CVE-2022-3219 for CVE-2022-3219. Can this please be fixed?

This is referenced from https://nvd.nist.gov/vuln/detail/CVE-2022-3219 for CVE-2022-3219. Can this please be fixed?

We check the actual used signature and the corresponding (sub)key. Whether you trust this key is a different thing and we are not able to check that. Note that the same subkey may be used with different primary keys. The whole point of gpgv is to that you pass a list of trusted keys - actually this makes this new option superfluous but in gpg it makes sense. It was easy to add it to gpgv, though.

I have the same problem too English language and Italian language

• Adapt to final name of the enum in KPaswordLineEdit