Hi, you have "compliance de-vs" in your %APPDATA%\gnupg\gpg.conf. But have installed Gpg4win. The default key pair algorithm of Gpg4win is not VS-NfD compliant, in fact the whole Gpg4win version was not approved for VS-NfD. So just remove that compliance line from your config and everything should be fine. Otherwise the forbidden indicates that you are trying to generate a non-compliant key with a version configured for compliant operation.

gpgconf -X in cdm.exe

1. I use Windows 10 Pro (19045.3996 22H2).
2. I don't use gpg-agent on a remote machine (e.g. over an ssh connection) I'm not capable!
3. I don't understand how to get "gpgconf -X" and "gpgconf -V". Can you explain the procedure better to me?

Please post the output of "gpgconf -X" and "gpgconf -V".

VS-NfD is not a standard but a classification for restricted data. Software used to convey such material needs an official approval and is bound to certain organizational requirements. That is what "VS-NfD konform" says. The community version of gpg4win does not have this approval despite that it is technically the same code as the approved GnuPG VS-Desktop.

The additional debug info are:

gpgsm: DBG: p12_parse:1998: err=0 prk=0x0000000000000000,0x0000000000000000
gpgsm: DBG: p12_parse:2006: err=0 prk=0x0000000000000000,0x0000000000000000
gpgsm: DBG: p12_parse:2021: err=0 prk=0x0000000000000000,0x0000000000000000
gpgsm: DBG: p12_parse:2054: err=0 prk=0x0000000000000000,0x0000000000000000
gpgsm: DBG: p12_parse:2061: err=0 prk=0x0000000000000000,0x0000000000000000
gpgsm: DBG: p12_parse:2069: err=0 prk=0x0000000000000000,0x0000000000000000
gpgsm: DBG: p12_parse:2081: err=0 prk=0x0000000000000000,0x0000000000000000
gpgsm: error parsing or decrypting the PKCS#12 file
gpgsm: total number processed: 4
gpgsm:              unchanged: 4

• enable again setReadOnly

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