Fixed.

Here is a PAM module, which interact a spawned process using authproto protocol of xsecurelock.

For Gpg4win we will soon release a 4.0.4 Version that will contain the latest Kleopatra updates and GnuPG 2.3.x, but the 3.1.x series of Gpg4win is something that we only release in binary form as part of our Product GnuPG VS-Desktop.
The reason for this is that for VS-NfD there are some responsibilities for the supplier, and so the VS-NfD user needs a responsible supplier. We do not promise that for Gpg4win, which is the free community version anyone can download. If we would provide Gpg4win-3.1.24 also in binary form we would make it harder for us to argue that VS-NfD users have to purchase GnuPG VS-Desktop with the required support.

Checking musl internal, it seems that we can detect a single threaded application by:
https://git.musl-libc.org/cgit/musl/tree/src/internal/libc.h#n22

Thanks for your help @gniibe and apologies for wasting your time. It looks like this is an issue with ncurses on musl systems and I'll pursue it there. I have a patch to their configure which works & fixes building pinentry.

I've reported it on bug-ncurses@ to get some insight: https://marc.info/?l=ncurses-bug&m=166268018624805&w=2.

Mysteriously, I get nothing:

$ pkg-config --cflags nurses

To debug this you can enable logging of the dirmngr (which does actually talk to the keyservers). To do so open GnuPG System/Network in Kleopatra's configuration dialog and set the debugging level to 4 - All and enter a filename for the log file.

Ah OK I'm following now, I had took that as maybe another lookup at that time was failing. The keyserver that we have configured is hkps://keys.openpgp.org. Is there any misconfiguration here with that setting?

In T6014#163001, @ebeiersdorfer wrote:

OK, so this warning should just be ignored then?

OK, so this warning should just be ignored then?

I have implemented this a bit differently in particular with usability (e.g. discoverability of the import possibility) and accessibility in mind:

• Add a separate Import button instead of re-using the Sign/Encrypt button.

For one, this allows the user to encrypt a public key block. Moreover,
buttons that magically change their meaning are bad for accessibility.

• Update the three crypto operation buttons in one place.
• Disable the Verify/Decrypt button if the notepad is empty.

Could you please check what pkg-config --cflags ncurses returns?
In my environment (of Debian), it returns:

It looks like there was a problem similar to this a while ago: https://dev.gnupg.org/T2320 where it turned out for unicode ncurses builds, a specific header had to be included, but that workaround seems to have been removed from pinentry since.

bernhard added a comment.Mon, Sep 5, 6:05 PM

If it is was broken for you and works now, let us know here.
if "lists." still is there in email addresses somewhere, please also list.

Kleopatra does searches in parallel. What you see in the second dialog might be a response from a Web Key Directory (i.e. search by mail address with lookup at the mail domain).

Here is a list of possible issues:

BTW, gnupg/doc/DETAILS tells that the fingerprint is optional:

Pushed the fix for GPG_ERR_INV_ENGINE.

gpgsm may emit S IMPORT_PROBLEM 1 (with no fingerprint information) when it cannot find valid fingerprint.
I think that this case should be handled correctly by GPGME, not returning GPG_ERR_INV_ENGINE.

It's not yet pushed, because it requires new release of libgpg-error (for T6112: libgpg-error,w32: bidirectional Pipe support for estream).

In T6085#162918, @ebo wrote:

well, when creating openPGP keys with kleopatra I did not see any hints. I do not think that the issue would be vaild for password based encryption. There the common usecase is autogeneration, anyway

In T6085#162921, @aheinecke wrote:

@ikloecker yes as mentioned in my response the current hints are only for symmetric.

@ikloecker yes as mentioned in my response the current hints are only for symmetric.

well, when creating openPGP keys with kleopatra I did not see any hints. I do not think that the issue would be vaild for password based encryption. There the common usecase is autogeneration, anyway

After some discussion with Andre we decided:

1. We keep both buttons always enabled. Reasoning: We do not want to disallow a valid operation just because our heuristic says that attempting a decryption makes no sense.
2. Instead of the Encrypt button we switch the Decrypt button to Import if we detect a key block. This way the users can encrypt key blocks (which does make sense; in particular, for protecting exported secret keys), but attempting to decrypt a key block will always fail.

The long hint is "hidden" in the tooltip of the short hint.

Well it is good that we have it now and we should not remove it. But when asked I would probably have said that this dialog / page should be removed altogether. I would bet that if we did a user survey this dialog is not used at all. Or very very rarely.

And the issue for which @ebo opened this ticket is in my opinion that you have to fail first before you see the hint.