merged

merged

Is this issue resolved?

Oh well, it does not use the c++ binding .

I don't think that we need to show which keys are compliant or not because that is already shown by the VS-NfD compliance status. And then we only have left the case where the keys are expired / revoked so a user could sort by validity to find out which ones are those.

Yes that probably gets lost along the way, where we communicate with scdaemon to generate the key. Needs to be tracked down. Such things can be very confusing to users. Especially if that increases the PIN Retry counter!

Yes I think that some keys must match, e.g. if you filter for S/MIME you only want to see groups where at least one S/MIME certificate is part of the group. Or for expired to see if there are groups with expired certificates in them.

Ingo, I concede it might be considered a bug on Request Tracker that it does not allow to specify the key as a fingerprint (or calculates it automatically from the email instead of relying on gpg doing it), but you generally want to keep expired keys around for decryption.

Could you write a quick patch file for that? (I don't have a working source build, I am using the Fedora spec file + patches)

The old debug output is in genral okay but what I would do is to add a couple of log_debug calls like

And not using the native Windows dialog isn't an option because people are used to the Windows dialog. I absolutely hate it when some application on Linux doesn't use the KDE dialog but its own dialog because it behaves slightly differently and it doesn't have my bookmarked folders.

We cannot

Switch to gpgtar if folders are involved. In that case "Sign/Encrypt Folder" would no longer be needed.

because we don't know that folders are involved. And I don't think we can hide the folders, so that users cannot select folders and wonder why they are not encrypted, because Microsoft thought it would be a great idea to basically use the Windows Explorer as File Open/Select/Save dialog. And, of course, they won't change this because this would break all existing Windows applications if suddenly folders are returned.

Does the run-verify example (in gpgme/tests) hang when verifying a corrupted file?

@werner I managed to recover the old .p12 that has the error. And this is still replicable. Is there a debug flag that would be useful or can we setup some private live-debugging for this?

I would like to change the description of this ticket.
Which way do we want to go?

Closing this outdated ticket

Quite frankly, if a third party application calls gpg with anything other than fingerprints to specify keys it's asking for trouble. I have changed KMail from using user IDs to using fingerprints when calling gpg more than 20 years ago.

Sorry, Werner, but I have to disagree on this. Specifying them by fingerprint only works if you have a specific field for the key (including the case where you are just it on the config file).

I'm attaching a proposed patch. We should decide whether this is the correct encoding to use for SHAKE128 and SHAKE256, because they are variable-length output functions and there is an alternative encoding that has a field for the length, which is likely better suited, but currently not really well supported by libgcrypt (since this would be dynamic content in the ASN.1 encoding).