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.

I can confirm the fix.

Should be fixed.

This is most likely a regression of switching to the gpgme-based secret key export.

I was looking for this when writing the update NEWS for the latest release and noticed that this has not been pushed yet. I really think that it would be nice to have that. Especially for Smartcard use cases.

Ok. That is about the Invalid Crypto Engine. But this does not explain why a .p12 export via Kleopatra leads to this error when we export a valid certificate. The same thing I do with Kleopatra on the Command Line works:

The error is generated in parse_import in gpgme/src/import.c:

if (errno || args == tail || *tail != ' ')
  {
    /* The crypto backend does not behave.  */
    free (import);
    return trace_gpg_error (GPG_ERR_INV_ENGINE);
  }

Added now

Or better:

• 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.

Thanks!

https://lists.gnupg.org/mailman/listinfo/gnupg-devel has `To post a message to all the list members, send email to gnupg-devel@gnupg.org." now, which seems fine, it was wrong before.

Fixed for 3 lists. I can't remember the details but quite some time ago someone requested some changes and while applying them the host_name must have changed / I changed it. The problem with Mailman is that it does not use plain config files to keep under etckeeper. At least not with some effort.

I think there was a misunderstanding here. We already set .pinentry.constraints.hint.long and .pinentry.constraints.hint.short in GnuPG-VSD but firstly they are only about symmetric.
And the issue for which @ebo opened this ticket is in my opinion that you have to fail first before you see the hint.

@werner also I suggest to check the default setting for this, see https://www.list.org/mailman-install/customizing.html and you can use the scripts mentioned there to check the configuration of several mailinglists at once and change it, if you know, which one is to blame, e.g. the host_name value.

@werner
Can you take a look at the host_name setting at the [General Options] configuration page for the lists in question,
e.g. https://lists.gnupg.org/mailman/admin/gnupg-devel

I think this issue is not resolved completely:
Currently I can see the same behaviour as descrived in T5330 (https://dev.gnupg.org/T5350) in all current versions of Kleopatra.

Does the problem even occur if the secret key stubs have already been created?

I agree that this will be less important when T5836 is done. But on the other end, someone personalized a smartcard for you. Ideally when inserting the smartcard it will fetch the public key from LDAP but if that is not configured or available you will have the same case of a smartcard that creates the secret key stubs and then importing the public key. As I think that in the case of exactly one key imported a keylisting through the agent of this one key won't be that expensive we should fix this as a minor issue.