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):

@werner My intention of rG268e435 is removing the need of --directory~ option, in our code.
With this change, we can focus on the behavior of --directory= option.

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. See new task T8182

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.
My request is for pinentry on Linux, so the task that was merged with this one is more applicable (that one was for pinentry-gtk2 on Linux, this one is for gpg4win), but that task was closed, so I am commenting on the one still open. Perhaps the task and its title should be edited to apply to all platforms, regarding the default selected button in a pinentry prompt.

https://invent.kde.org/teams/vdg/issues/-/issues/122

I still don't think that --directory~ is a good name for an option. It looks to similar to the ~USER shell pattern. What about --unsafe-directory which also avoids an option ambiguity regression on the CLI?

It is clearly not implemented for S/MIME: rKLEOPATRA9eed4a45ed93 but it should be.

It's not that simple. The user could have decrypted multiple archives. Showing an additional message box after all decrypted archives have been moved to the final destination somehow doesn't feel right. And what if an archive and a regular file were decrypted? Should the additional message box also show the final destination of the regular file? I think this needs more thought.

Please keep in mind, that for the 3.4 release, we will most likely only have the User Manual ready, not sure about the Administrator Manual.

I located the place where tests/ requires the feature of gpgtar overriding existing files.
I fixed that in: rG268e435f921a: tests:openpgp: With gpgtar, extract tarball into an empty directory.

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.

I consider again about Ben's change. It could be simply support of the detection of the cancel situation where gpgme should return GPG_ERR_CANCELED (not related to single cancellation vs. whole cancellation).

I can't remember why Ben introduced the new status. OTOH, I wish that the Qt-Pinentry also emits a button_info line for closing the window. Normal users don't notice the difference but if you have a lot of private keys and you get a mail which has only hidden recipients the full_canceled is pretty useful. Also for other tasks like allow-mark-trusted: On Windows with the qt-pinentry I am always cursing about this but on my box I only need to close the pinentry window to get a fully_canceled

Alternative suggestion:

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

added vsd34 for the resetting of the defaults part only

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.

Windows button order seems to be described, there: https://web.archive.org/web/20161013015954/https://msdn.microsoft.com/en-us/library/dn742499.aspx . I could not find a more up-to-date official reference. Likely, this still applies, though. This specifies (left to right): OK/[Do it]/Yes, [Don't do it]/No, Cancel, Apply (if present), Help (if present)

branch work/tfry/seclevel_ui