Pushed the last change: rG2239f687bb14: scd:openpgp: UI improvement for use of PIN-entry.

Setting to low because this has never been a problem in the last 30 or 35 years. A check to help pinpointing bad keys is however a good idea.

Backported for VSD 3.4

Should be backported to VSD 3.4 because these changes amend T7212: Problems with certificate colors / styles.

Backported for VSD 3.4

The remaining open points of this ticket will be "won't fix" for now. When we plan to change something here, we should open new tickets, this one got confusing.

That change is too complex for just getting a proper error message. The original patch covers the most common case.

This should also be fixed in 2.2 and 2.4 (if neccessary)

Just a quick note: For any operation that imports something I would expect an import result (gpgme_import_result_t) listing the keys that were imported. op_keylist in locate mode is a strange duck because it can list and import at the same time.

It seems that pinentry-curses defaults to "OK".
(my branch for GTK-4, same.)

This is a bit larger change (of UI improvement):

Cancel (in pinentry-qt) was made default with rP291089ed476d75c71ef1984a7c081d27e357437d. Marc's ChangeLog entry was

• qt4/main.cpp: (qt_cmd_handler) make Cancel the default button for CONFIRM

I guess no. But yes, am also annoyed by the default for "insert card" - sometimes several times a day. We should really fix that.

Does this relate to which button is selected by default by a pinentry prompt for inserting a card? I am very annoyed by the default for it being "Cancel" as I can't just press enter after inserting the card, but have to tab to or use the mouse to press the OK button.
It would be great if the default for the card insertion prompt would be OK.

I sent a patch to gcrypt-devel mailing list for the preparation of the change of RSA secret key checking.
If enabled, wrong RSA secret key (wrong means: under the Libre/OpenPGP specification) is rejected at import when gpg-agent calls gcry_pk_test_key.

BTW, LibrePGP also demands p < q in "Algorithm-Specific Part for RSA Keys".

added vsd34 for the resetting of the defaults

I investigated the introduction of STATUS_CANCELED_BY_USER and GPGME_STATUS_CANCELED_BY_USER:
rG31e47dfad0f4: gpg: Add canceled status message.
rM35ca460019ea: Parse STATUS_CANCELED_BY_USER.

For OpenSSH, ssh-agent spec. defines p, q, and qInv.
FIPS has: FIPS 186-5 and SP 800-56Br2.

existing standards

Filter 16 is the new filter for valid certificates. The problem could be that the version you tested did not yet have this filter.

CRT is used with GnuPG. In libgcrypt, pk_sign and pk_decrypt don't require P, Q, and U in a key (it's optional), but pk_test_key does.

@ikloecker I'd like it if we could backport the resetting of the preferences to vsd34.

Font selection dialog lets the user choose a font size, which is then not respected - can we disable selecting the font size?

On gpg4win-5.0.2-beta-2 @ win11 i can reproduce:

• drag&drop does work
• move via context menu
  • works for selected mails
  • does not work for unselected mails

Du we have any information on whether the CRT is used and whether u et al. is also wrong? For example due to an OpenSSL generated key?

I cannot reproduce this on gpg4win-5.0.2-beta-2 @ win11 either, so I set this to resolved.

Please briefly try to reproduce on Windows with Gpg4win 5.0.2. At lot has changed since this ticket was created so that it might be fixed already.

I cannot reproduce the empty dialog on Linux with the current build. I always see a correct result dialog for the readable file.

Note: This isn't included in Gpg4win 5.0(.2).

I stand partially corrected. Apparently, pinentry-efl also sets close_button. For Gpg4win that's irrelevant because we ship pinentry-qt (and pinentry-w32) which doesn't have this IMHO contra-intuitive behavior.

pinentry-tty and pinentry-curses support GPG_ERR_FULLY_CANCELED by Ctrl-C. But other pinentry implementations have no support (only GPG_ERR_CANCELED).

I'd also like to point out that changing the error code from GPG_ERR_CANCELED to GPG_ERR_FULLY_CANCELED could cause regressions in applications.

How do you want to decide whether to show two "Cancel" buttons? How would you call those two "Cancel" buttons? For decryption I can imagine that for example "Try Next Key" and "Cancel Decryption" (or even just "Cancel") would make clear what happens.

If this definition is OK

@bernhard Thank you for the link.

In T8076#215372, @werner wrote:

If you specify a primary key the primary key shall be deleted. If there is only an offline or token based primary it can't be deleted. This is what the user requested. We can't change this because otherwise subkeys might be unintentionally deleted.

What is an "incomplete team key" - a standard offline secret key (i.e. one with only secret subkeys)?

If you specify a primary key the primary key shall be deleted. If there is only an offline or token based primary it can't be deleted. This is what the user requested. We can't change this because otherwise subkeys might be unintentionally deleted.

I guess the behavior changed with gpg 2.4, i.e. "With gpg 2.4 (or later), ..."

why gpg 2.4? Don't you mean 2.6? I'll add the proper 2.6 tag for avoiding confusion

Hi @gniibe,
thanks for making progress on the issue.

I was wrong. gpg (scdaemon) needed to be fixed with more changes for the interaction with pinentry.

I pushed my patch for gpg, since it does not break anything, just allow empty passphrase input (to skip).
I also pushed my patch for gpgme. I believe that it's correct.

gpg 2.2 does: when it sees PKT_PUBKEY_ENC it asks a user to try decrypting the session key. when it sees PKT_SYMKEY_ENC it asks a user to try decrypting the encrypted session key by passphrase. When one of tries successes, it use the result (the session key) to decrypt PKT_ENCRYPTED_* packet. When there are multiple PKT_PUBKEY_ENC and PKT_SYMKEY_ENC, gpg 2.2 handles sequentially.

From the support angle, the worst of these issues is that the default will not be restored for VS-NfD. But then: nobody has inquired about that yet…

What is fixed, what needs still needs to be done and should go into another ticket?

I cannot reproduce this problem anymore with Gpg4win 5.0.1. The bug seems to have been fixed in the meantime by changes made upstream.

I thought Gniibe's comment meant that gpg does report the errors now correctly…
So what is still to be done in gpg?

I don't think that anything of this can be changed in Kleopatra or even gpgme. Kleopatra relies on proper error codes by gpg.

It is not (easily) possible to check for available keys first, before asking for a passphrase? (Like it is with gpg 2.2.)

I was too optimistic. GPGME is required the following change, too:

diff --git a/src/passphrase.c b/src/passphrase.c
index 140cd03a..d07afa91 100644
--- a/src/passphrase.c
+++ b/src/passphrase.c
@@ -114,6 +114,11 @@ _gpgme_passphrase_status_handler (void *priv, gpgme_status_code_t code,
     case GPGME_STATUS_CANCELED_BY_USER:
       return gpg_error (GPG_ERR_CANCELED);

I'd propose applying the patch of mine above to gpg, and suggest users to input empty pass phrase to skip (instead of cancelling).
This could be a minimum change (only gpg). Or else, gpgme needs to change to ignore CANCEL status; I think that it's not easy change.

Afaict neither QT nor FLTK offer an equivalent to gtk-2's gtk_init_check() so there is no trivial change to get the same functionality.

I guess those things need to be changed in Kleopatra after @gniibe made the changes in scd. I'll add a Kleo tag for discussion, as we should probably make several tickets from this.

Gpg4win-5.0.1 still shows case 1. (just reproduced.)

Looks good to me on gpg4win-5.0.2-beta2 @ win11.

• local conf after 2 saves (additional entry in local conf):
  
• local conf after 2 saves (additional entry in global conf):
  

It doesn't look like much was improved on Kleopatra side in gpg4win-5.0.2-beta-2 @ win11.

Looks good to me on gpg4win-5.0.2-beta2 @ win11:

gpg4win-5.0.2-beta-2 @ win11:

Additionally, the action is no longer offered for keys with an encryption-capable secret primary key without secret encryption subkey.
And sharing the secret signing subkey isn't offered anymore if this is a card key.

Looks good to me on gpg4win-5.0.2-beta2 @ win11 (no de-vs-compliance filter):