/hex is just a diagnostic helper and not expected to be used to retrieve data.

DNSSEC is a centralized CA system. Just different than the TLS one. Given that Certificate Transparency exists I'd say DNSSEC is less transparent than TLS. For example if you happen to have a .ly domain then the Libyan can silently control your signed zone. Given that there is no CT for DNSSEC they can do so selectively, for any connection they want. It wouldn't be the first problem with them.

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