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

I tried the same:

A workaround which (currently) works for flagging and categories both is:

I think I haven't been clear enough about the issue for this ticket, sorry about that. My main concern here is that in Kleopatra's Certificate Selection Dialog, the key filters don't filter the keygroups at all, i.e., if i select the "OpenPGP Certificates" filter, a group containing only SMIME keys is still visible.

Applied the change. I write the ChangeLog entry by commit message.

I'm wondering whether we didn't do this for a reason. Currently, groups are only used in the certificate line edit. Didn't we want to show all groups to give the user the chance to notice a group containing an unsuitable key? If we filter out the group then the user will have a much harder time to find out why the group isn't offered. Things may be different for the key selection combo box which is primarily (or exclusively?) used for the user's own keys without even offering groups.

Checking if the file already exists doesn't help. In fact, typically the file (containing the shadow key for the card key) will already exist. But one could check if there is already a private key with this keygrip. Then restoring could be refused, so that the worst that can happen is that the shadow key (which can be recovered from the smart card) is overwritten with a corrupt file.

We provide the examples for a reason. Actually, two reasons: To test our changes ourselves. And to provide working examples for others. If your code doesn't work then you'll have to figure out where the example and your code differ. If the example doesn't work then we'll have a look.

Looks like
https://bugs.kde.org/buglist.cgi?component=it&product=i18n&resolution=---
is the bug tracker for Italian translations.

@Karam, please test as suggested by @ikloecker.

Setting the priority to low because that is the task for the KDE translation team. I am not sure how we can interact with the translation team, bug tracker wise. Do they have their own tracker?

@werner I 'm not passing nullptr to gpgme_data_release.
@ikloecker Honestly I didn't test it.
Is there anything wrong with code ? have anyone encountered such behavior ?
I was trying adding a timeout as a workaround for gpgme_op_verify to avoid hanging but it depends on the file size and how much it will take to verify it signature...

As a change in behavior is not possible, we continue with the button solution here: T6984: Kleopatra: Add icon for folder encryption