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

@TobiasFella Since werner, ebo and ingo will be only talking about the smartcard related issues next week, I think there are plenty of nice jobs here :)

Feel free to fix this

I think the attack ingo talks about would mostly be covered by checking if the file already exists before moving it into the private directory.

But like it is now one would only go into the subkey view after things start behaving unexpectedly. After all, "I told the program to extend the subkeys", why should I verify if it really did this?
If the box "extend validity for subkeys" could not be checked in case no keys will be extended, I would then go to the subkey details, if I wanted to extend them, too.

In E1020 @TobiasFella wrote about this: Sizehint is correct, but only at a later point in time; also, apparently some cache invalidation problem? Since the current version works fine with a fixed size, might not be worth the effort to fix.

I think this currently is fine. You can always go into the subkey view and the the expiry date there for corner cases.

I think we can close this issue. Ikloecker explained why. The hint comes from the help files and I think at the time I opened the issue I did not use the help messages.

Check https://community.kde.org/Get_Involved/translation for information how to contact the translators and/or become active in translation.