Thanks, @gniibe. From reading this patch (i haven't tested it), it looks like it would avoid most unnecessary agent launches (and agent communication) in the (b) case, which is a win over the status quo.

Note that rGd3f5d8544fdb needs to be backported to 2.2 but we will wait until we have better tested it.

With me it happens all the time: Outlook 2013 x64 is half-maximized at
right border, and GPG asks for the passphrase on sending a mail from the
inline editor, on Windows 7 x64, then it always happens.

Thanks.

Fixed in master.

This part of code is questionable. It always comes fp!=NULL, so the part should be removed.
If fp==NULL, use of tmpfile is quite questionable because a user can't know where the trace output goes.
I'm going to remove that part.

If it makes sense to warn a user for someone's preference when keys are imported,
here is a patch:

It appears (for me) correct behavior.

This was also raised for (hopefully) wider discussion on the IETF mailing list.

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.

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.