For the record the Task for the fingerprint copy was T5776

I tend to disagree. The fingerprint is a very long and cryptic looking thing. Most users of Kleopatra will never share their fingerprint as they tend to work on a TOFU model, just accepting a given key and using it. For another bunch of users the long keyid, which we show, is more then enough security. And for the VS-NfD case with very high security where users compare a full fingerprint it is accessibile enough.

We use the tooling from debian buster. We do not compile any host tooling as part of the build, except for QtBase tools.

For the record, I am for the deletion as long as it is guarded by a safety check.

Have you selected an Output file in a location where you can write files with your permissions?

Could you please create a log file using the debug settings with Outlook Object Model debugging enabled?

We should give this higher priority as users need to change their e-mail through kleopatra. A customer also wishes this.

Ingo, it would be great if you could work on that. For me the most intresting use case is to fully revoke a key because it has been superseeded.

I wonder if we even should change gpgme to do a key refresh when you call it in VALIDATE mode and online? Semantically this makes sense to me as this is where CRL checks for S/MIME are done. But from a conserviative standpoint this could be considered an API change if the API then does something differently and that even does a network connection. So while I consider it I don't think this is a very good idea.

This occurs on Windows. But if a raise is really missing, it might also occur with other window managers.

Yes, makes more sense to me, too. Maybe another filter "bad" certificates, so that you can bulk delete them for example to clean up your keyring?

I think this is because we install pinentry-gtk, too. So we have that GTK dependency.

Yes, unit tests still pass. So its ok with you to commit this?

@ikloecker
If I test the resolver code from libkleo with gpg4win-tools keyresolver binary:

Thanks, I always did it differently and never saw that because I changed the read only configs.

Removing the list seems reasonable to me, we can tell users in support that they should go to settings- > Smartcard to select the reader used.

Related to this is that I was looking for a way to revoke my own key and I thought that revoking the selfsig might work. So maybe it makes sense not to fix this by forbidding this operation but instead by allowing it with the same key.

The problem is that we replace the encrypted text and attachments with the decrypted / verified parts. This would already be a modification even without such changes like the category.

For the next release T5842 (so with a higher priority) I have picked

Yes. Sorry about that. We had multiple issues where attachments were hidden and not shown as attachments because they had a content-id but that content-id was not referenced in a way that outlook shows.

For our internal tests this boils down to testing:

• with keyboard only
• for people using a screenreader
• with 400 % magnification
• with high contrast color scheme
• with inverted color scheme

I have tested it. When I try it with public keyserver it has of course problematic results when vandalized keys like werners are hit but its great that even if I abort at that point I nicely see the results of the other imports.

It should not really hurt to query the scdaemon again after an import. We can do this in the background and users wont have to notice it in the general case where imports from others happen.

Hi,
(Exec format error), read 0 bytes

From the external test and review of the test results I list the priority below. Some of the issues need to be reproduced for full understanding. We should open subtasks where appropiate. To have a better orientation I think we should keep the general prioritization in mind and work use case by use case.