i've just pushed rGc4b9eba1d6a63b73238dcbb644b365dc53563f3d to the dkg-fix-T4682 branch resolve this.

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

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.

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.

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.

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

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

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.

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?