@dkg, I changed the title and adjusted the description to more accurately describe the situation.

Well, gpg-error is special. For other libraries, adding -I and -L is enough and good.
Fixed in master.

Thank you. I only tested a configuration where installation of libassuan has same prefix as libgpg-error. That's the reason why this bug exists.

It was fixed in GnuPG master by rGc395f8315362: agent: Terminate pinentry process gracefully, by watching socket. and rG374a0775546b: agent: Close a dialog cleanly when gpg/ssh is killed for CONFIRM..
Those will be in GnuPG 2.3.

@skeeto can you edit the summary/title of this ticket to better reflect what you think the underlying issue is?

This appears to be https://bugs.debian.org/850946 and it does not appear to be fixed to me.

reviewing this, i think the situation is:

Fixing t-lock is indeed a better solution however having an option to disable tests could be used in another context than fixing this issue.
For example, in the context of buildroot (which goal is to build a custom embedded linux system), this option could be used to save time during compilation as well as to save space on the embedded system.

Thanks for your report.
I think that adding an option for disabling tests is too much.
If it were AC_SUBST, we could use HAVE_PTHREAD in tests/Makefile.am.
In the current situation, just modifining t-lock is easier.

I think that I located the cause of this bug:

Those changes make the script work for me, specifically passing the input as an argument and not through standard input. Digging more, it looks like the underlying issue is related to using pinentry-tty (my case) or pinentry-curses when passing the OpenPGP input via standard input. This causes pinentry to give up before prompting. For pinentry-tty it fails with "ERR 83886340 Invalid IPC response" and pinentty-curses fails with "ERR 83918950 Inappropriate ioctl for device".

For my environment (Debian buster's 2.2.12 and another one from GnuPG master), both (no argument and foo) work well.
The invocation with argument let pinentry pop up to ask passphrase.

I am in charge of editing the current OpenPGP draft, so I will for sure keep an eye on that issue. If would appreciate if you can post your report also to openpgp at ietf org.

Considering that early interop testing, you're probably right that this is a bug in the spec, not GnuPG. Otherwise this would have been pretty obvious long ago. The wording in RFC4880bis hasn't been corrected to match practice, so I should probably report this issue there.

Re-reading the original report from 2001 it seems that PGP and PGP do the same. Back then these were the only OpenPGP implementations (except for that book with the OpenPGP tool based implementation). We did quite some interop testing in the early years by passing OpenPGP data back and forth. So one could assume this is a bug in the specs becuase the specs are for large parts derived from the PGP 5 code base.

Sounds interesting @stm! Are there technical documents or specifications I could read to dig into details?

@dkg First step toward the canonical OpenPGP certificate export: http://git.savannah.nongnu.org/cgit/libtmcg.git/commit/?id=75372cac01501ae427dec1ae18805449bf28d087

Problem no longer exists. It has solved itself in the meantime. In addition, I ask for deletion of this account via the responsible administrator.

@wiktor-k Thanks for your interest.

Are you seeing mixed-up MIME parts? or a different problem?

WKD and DANE/OPENPGPKEY offer rather distinct properties. I'd be hard-pressed to say that one is "better" than the other without understanding the threat model and concerns of the evaluator:

No problem, I'm glad i could help, accented letters are always a pain between encoding.

Thanks for reporting.

Please explain in more detail what does not work. Outlook 365 is actually part of our test environment.

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