In T4618#128103, @wiktor-k wrote:

I'm left wondering: are there cases where OPENPGPKEY would be preferred over WKD?

Fixed now, both in the repo and on the file server. Thanks for noticing.

I really need to automate things more for a release there is just too much copy and pasting involved where mistakes can happen.

Re-examining this now, I'm noticing the problem is not at all that it's being treated as signed, but that GnuPG is internally using a 32-bit unsigned integer for the time even though the key expiration scheme allows for expiration dates beyond 2106. Seeing dates in the past threw me off, and when I had originally tried using a zero creation time to test a broader range I ran into T4670.

I'm using Debian 10 "Buster" on x86-64, but for this ticket I used my own build of GnuPG so that I could demonstrate with the latest version. The system's GnuPG 2.2.12 has the same behaviors I showed here.

What OS are you using?

I also observe that the text in the GUI prompts is remarkably unclear on its own. setting aside the grammar, punctuation, and wording, the prompts don't expose the usage flags set for the secret keys, which is possibly the only detail that a user with a single OpenPGP certificate would care about: "am i deleting my signing-capable subkey or my decryption-capable subkey?"

I was able to avoid reported behaviour; then n not a bug.

Please update the documentation for the function in that case.

Please see my explanation on gnupg-devel about why the trailing NUL is a source of pain and difficulty for would-be adopters.

Lacking another category for such things, I dropped the priority.

Well, gpa needs to use gpgme's interface for receiving and sending keys. The use of the helper programs an old hack.

Right, master will be 2.3.

Actually all this code shall be replaced by new code from gpgrt. Most likely using estream_t for all of them.

No, it was not in mind. I introduced this only for backward compatibility. It will be extended iff we have a need for it.

Appending a nul byte is fail-safe programming and helps in debugging. It is on purpose and shall not be removed.

Actually my not-written-down plan is to use a Windows like style for tracking a process. This will also resolve the pid rollover problem. It shall all go into gpgrt of course.

My understanding is: it was introduced by rG370f841a0135: Enhanced last patch. in 2009 to give information to client (for a specific command at that time), possibly in a hope that server side would support the feature for all commands (and client could benefits).

I think the problem is the following:

False alarm. Turns out pinentry-gtk-2.exe is also not working all the time.

@bb - I've tried this, this doesn't appear to work. It looks like the Gtk2 pinentry doesn't grab focus when doing authentication, either. Interestingly enough, it also doesn't show in the taskbar.

Note:
I added:

pinentry-program "C:\Program Files (x86)\Gpg4win\bin\pinentry-gtk-2.exe"

as a workaround to my gpg-agent.conf. This pinentry is able to grab the focus.

The card was replaced by the vendor. It seems to be a problem with the specific card. All other cards so far worked well. The issue can be closed.

Does anyone has an update on this issue?

I've just uploaded pinentry 1.1.0-3 to debian unstable with this fix in it.

@aheinecke thanks for the heads-up. i'll pull this in.

Thanks. So, this is a positive report for 8E60:34C2. I'm going to add this VID:PID to support pinpad input by the internal CCID driver.

Pinpad input is not supported for Gemalto Ezio Shield, currently. OpenPGP card expects variable length pinpad input, and we don't have any positive report with the card reader.

we won't backport it to 2.2

Can you help me please to understand why you think that this is a regular use case?

Fairly typical situation: user needs to encrypt binary and text regularly

Pinpad input is not supported for Gemalto Ezio Shield, currently. OpenPGP card expects variable length pinpad input, and we don't have any positive report with the card reader.

@aheinecke , Would you consider re-opening this ticket?

I'm going to push this change to master.

Wow, thanks for the quick response! I've applied your patch to the Ubuntu package (2.2.4-1ubuntu1.2), and gpg --card-status now works fine:

I'm not really sure if "No Key" is a better string for "Ignore Recipient". But most other things are either unclear (ignore recipient) or can be misunderstood like (Do not encrypt to this recipient) as this could also mean that the recipient gets an unencrypted mail.

It now looks like this:

@dkg This patch ( rP0e2e53) might also be something for debian as it can cause crashes depending on the qt theme, which is not under our control.

Thanks!

I can confirm that the patch from the referenced commit fixes the issue. Thanks for the quick action!

@aheinecke

Due to socket forwarding we can have different versions of gpg-agent and gpg / gpgsm because they are on different machines and afaik we try to support it.

In rGfdd1567743cc1d526f92e63162d899a24c42cdf4#61654, @gniibe wrote:

As far as I know, usually, gpg/gpgsm can assume same version of gpg-agent.

fwiw, if the old gcrypt actually returned a radically different API, it should have a larger SONAME across that change, and NEED_LIBGCRYPT_VERSION should reflect a source version that forces it past that SONAME. I don't know what version of libgcrypt behaved differently -- is there a reference for that?

I don't think there's a problem to have a long explanatory message in the main repository, as i think it makes it easier to understand, and space is not an issue.

thanks for the report. I've commited a different fix 0e2e53c8987d6f236aaef515eb005e8e86397fbc which also should solve the problem.