epg.el: epg--status-GET_LINE not working?

epg.el: epg--status-GET_LINE not working?

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 1758 bytes --]

I have been thinking of fixing epg.el bug #24350
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24350>.

The problem is that in tofu conflicts epg interprets GnuPG's "GET_LINE
tofu.conflict" and waits for user input on minibuffer. The user
interaction is implemented in epg--status-GET_LINE function. But as far
as I can see it can't work. I'll try explain the problem.

Gpg is called with a command-line like this:

    GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent:0:1 /usr/bin/gpg
    --no-tty --status-fd 1 --yes --use-agent --command-fd 0 --output
    /tmp/epg-output983w_C --verify -- /tmp/epg-signature9839JJ -

Note that "--command-fd 0" expects interactive commands from the file
descriptor 0 (standard input). Such commands are handled by
epg--status-GET_LINE function which is triggered when "--status-fd 1"
output contains GET_LINE command. But also note the "-" at the end of
the command line. It means that the message contents is also being
received from the file descriptor 0 (standard input). Getting both the
message's contents and --command-fd's GET_LINE input from stardard input
stream doesn't work, or so it seems in my tests.

A possible fix: Remove "--command-fd 0" from gpg's options. It looks to
me that it is not really used. Then also epg--status-GET_LINE function
can be removed.

The bug report #24350 also mentions of supporting tofu conflict
resolution. If --command-fd's GET_LINE isn't an option for epg.el what
alternatives are available? Can tofu conflict be handled after the
verifying operation if we collect enough --status-fd's TOFU_STATS
information?

-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: epg.el: epg--status-GET_LINE not working?

[Daiki Ueno]

Teemu Likonen <tlikonen@iki.fi> writes:

> I have been thinking of fixing epg.el bug #24350
> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24350>.

I had a tentative patch for this, but I decided not to include it.

At that time, the GnuPG developers didn't seem to have a consensus on
how TOFU is supposed to work: Neal suggested it should be triggered by a
key, while Werner suggested that it should be triggered by an email
address.

I am on Werner's side, and if the things are implemented in that way, we
don't need to handle the conflicts in such lower level (but in the MUA
level).

> A possible fix: Remove "--command-fd 0" from gpg's options. It looks to
> me that it is not really used. Then also epg--status-GET_LINE function
> can be removed.

It doesn't sound like a good idea.  Have you considered all the cases
where epg--status-GET_LINE is called?  It is used (and works) for many
other queries.

Regards,
-- 
Daiki Ueno

Re: epg.el: epg--status-GET_LINE not working?

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]

Daiki Ueno [2017-06-26 09:30:00+02] wrote:

> Teemu Likonen <tlikonen@iki.fi> writes:
>> A possible fix: Remove "--command-fd 0" from gpg's options. It looks to
>> me that it is not really used. Then also epg--status-GET_LINE function
>> can be removed.
>
> It doesn't sound like a good idea. Have you considered all the cases
> where epg--status-GET_LINE is called? It is used (and works) for many
> other queries.

I merely noticed that checking signatures when the message content is
sent through the standard input the "--command-fd 0" doesn't work. Gpg
doesn't wait for "GET_LINE tofu.conflict" input from stardard input; it
just proceeds and gives some "hang up" message. So I concluded that
"--command-fd 0" and GET_LINE just can't work together on epg.el. But
maybe I generalized too much. Maybe the problem is just in this
signature checking operation which goes like this:

    echo message_content | gpg --status-fd 1 --yes --command-fd 0
    --output output_file --verify -- signature_file -

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: epg.el: epg--status-GET_LINE not working?

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]

Daiki Ueno [2017-06-26 09:30:00+02] wrote:

> Teemu Likonen <tlikonen@iki.fi> writes:
>> I have been thinking of fixing epg.el bug #24350
>> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24350>.
>
> I had a tentative patch for this, but I decided not to include it.
>
> At that time, the GnuPG developers didn't seem to have a consensus on
> how TOFU is supposed to work: Neal suggested it should be triggered by a
> key, while Werner suggested that it should be triggered by an email
> address.
>
> I am on Werner's side, and if the things are implemented in that way, we
> don't need to handle the conflicts in such lower level (but in the MUA
> level).

I suggest a minimal handler so that epg wouldn't wait GET_LINE input in
tofu conflicts (which currently doesn't work anyway) and
epg-signature-to-string function would return a string like this:

    Good signature from [keyid] [user id] (tofu conflict) created at
    [date] using [algorithm]

I believe epg is mostly used with Gnus and that line alone is useful.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: epg.el: epg--status-GET_LINE not working?

[Daiki Ueno]

[-- Attachment #1: Type: text/plain, Size: 669 bytes --]

Teemu Likonen <tlikonen@iki.fi> writes:

> I suggest a minimal handler so that epg wouldn't wait GET_LINE input in
> tofu conflicts (which currently doesn't work anyway) and
> epg-signature-to-string function would return a string like this:
>
>     Good signature from [keyid] [user id] (tofu conflict) created at
>     [date] using [algorithm]
>
> I believe epg is mostly used with Gnus and that line alone is useful.

Would that work?  I mean, if there is an unresolved tofu conflict,
shouldn't signature verification fail?

Anyway, I would rather ignore "tofu.conflict" like the attached patch
(not tested), until it becomes really useful.

Regards,
-- 
Daiki Ueno

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: epg.el.diff --]
[-- Type: text/x-patch, Size: 1015 bytes --]

diff --git a/lisp/epg.el b/lisp/epg.el
index 1e24b8d..4eb51ef 100644
--- a/lisp/epg.el
+++ b/lisp/epg.el
@@ -163,6 +163,8 @@ epg-dn-type-alist
 
 (defvar epg-prompt-alist nil)
 
+(defvar epg-unsupported-prompt-list '("tofu.conflict"))
+
 (define-error 'epg-error "GPG error")
 
 (cl-defstruct (epg-data
@@ -910,11 +912,13 @@ epg--status-GET_LINE
 	inhibit-quit)
     (condition-case nil
 	(process-send-string (epg-context-process context)
-			     (concat (read-string
-				      (if entry
-					  (cdr entry)
-					(concat string ": ")))
-				     "\n"))
+                             (if (member string epg-unsupported-prompt-list)
+                                 "\n"
+                               (concat (read-string
+                                        (if entry
+                                            (cdr entry)
+                                          (concat string ": ")))
+                                       "\n")))
       (quit
        (epg-context-set-result-for
 	context 'error

Re: epg.el: epg--status-GET_LINE not working?

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 3418 bytes --]

Daiki Ueno [2017-07-05 18:25:29+02] wrote:

> Teemu Likonen <tlikonen@iki.fi> writes:
>> I suggest a minimal handler so that epg wouldn't wait GET_LINE input in
>> tofu conflicts (which currently doesn't work anyway) and
>> epg-signature-to-string function would return a string like this:
>>
>>     Good signature from [keyid] [user id] (tofu conflict) created at
>>     [date] using [algorithm]
>>
>> I believe epg is mostly used with Gnus and that line alone is useful.
>
> Would that work?  I mean, if there is an unresolved tofu conflict,
> shouldn't signature verification fail?

Yes and no. There are two different point of views in verification:

 1. Signature is "good" if message's content matches the signature hash
    (message were not altered). Otherwise the signatures is "bad". This
    part can be "good" even if there is a tofu conflict.

 2. The key that made the signature is valid (we trust that it belong to
    the person we think). Gpg returns: TRUST_ULTIMATE, TRUST_FULLY,
    TRUST_MARGINAL etc. If there is a tofu conflict we don't get that
    TRUST_* information at all from gpg.

> Anyway, I would rather ignore "tofu.conflict" like the attached patch
> (not tested), until it becomes really useful.

I agree but with a small addition. That skips the "GET_LINE
tofu.conflict" case (which I think is good) but user is left without any
information about what happened. Function epg-signature-to-string will
return a string like this:

    Good signature from [keyid] [user id] created at
    2017-07-05T21:25:57+0300 using RSA

The signature is good but the usual "(trust ...)" is missing so there is
no information about key's validity. I suggest adding just the tofu
conflict info. With a patch like below the mentioned function would
return:

    Good signature from [keyid] [user id] (trust: tofu-conflict) created
    at 2017-07-05T21:25:57+0300 using RSA


diff --git i/lisp/epg.el w/lisp/epg.el
index c701954b75..80bcea8064 100644
--- i/lisp/epg.el
+++ w/lisp/epg.el
@@ -421,7 +421,7 @@ epg-signature-to-string
 		   (epg-decode-dn user-id)))
        "")
      (if (epg-signature-validity signature)
-	 (format " (trust %s)"  (epg-signature-validity signature))
+	 (format " (trust: %s)"  (epg-signature-validity signature))
        "")
      (if (epg-signature-creation-time signature)
 	 (format-time-string " created at %Y-%m-%dT%T%z"
@@ -905,12 +905,21 @@ epg--status-GET_LINE
   (let ((entry (assoc string epg-prompt-alist))
 	inhibit-quit)
     (condition-case nil
-	(process-send-string (epg-context-process context)
-			     (concat (read-string
-				      (if entry
-					  (cdr entry)
-					(concat string ": ")))
-				     "\n"))
+	(process-send-string
+         (epg-context-process context)
+         (cond ((equal string "tofu.conflict")
+                (let ((signature
+                       (car (epg-context-result-for context 'verify))))
+                  (when (and signature
+                             (eq (epg-signature-status signature) 'good))
+                    (setf (epg-signature-validity signature)
+                          'tofu-conflict))
+                  "\n"))
+               (t (concat (read-string
+                           (if entry
+                               (cdr entry)
+                             (concat string ": ")))
+                          "\n"))))
       (quit
        (epg-context-set-result-for
 	context 'error

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: epg.el: epg--status-GET_LINE not working?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I believe epg is mostly used with Gnus and that line alone is useful.

I use epg with Rmail and with Mail mode.  I don't know whether that
affects this issue at all, but I figure I should make sure people know it.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: epg.el: epg--status-GET_LINE not working?

[Neal H. Walfield]

At Mon, 26 Jun 2017 09:58:43 +0300,
Teemu Likonen wrote:
> I have been thinking of fixing epg.el bug #24350
> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24350>.
> 
> The problem is that in tofu conflicts epg interprets GnuPG's "GET_LINE
> tofu.conflict" and waits for user input on minibuffer. The user
> interaction is implemented in epg--status-GET_LINE function. But as far
> as I can see it can't work. I'll try explain the problem.

I use Wanderlust for mail and epg-* functions directly and in both
cases, when there is a tofu conflict, I get a prompt in the
mini-buffer along the lines of "tofu.conflict?" and I'm able to
specify a resolution.  So, it does work in the sense that the user is
prompted and can respond to a promt---at least in my situation.  I'm
told this is also the case with notmuch.

What needs improvement is that when epg sees a tofu.conflict prompt,
it should describe the conflict so that the user is able to resolve it
intelligently instead of having to known what is going on, as is
currently the case.  Some details are described here:

  https://wiki.gnupg.org/EasyGpg2016/AutomatedEncryption?highlight=%28tofu%29

> 
> Gpg is called with a command-line like this:
> 
>     GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent:0:1 /usr/bin/gpg
>     --no-tty --status-fd 1 --yes --use-agent --command-fd 0 --output
>     /tmp/epg-output983w_C --verify -- /tmp/epg-signature9839JJ -
> 
> Note that "--command-fd 0" expects interactive commands from the file
> descriptor 0 (standard input). Such commands are handled by
> epg--status-GET_LINE function which is triggered when "--status-fd 1"
> output contains GET_LINE command. But also note the "-" at the end of
> the command line. It means that the message contents is also being
> received from the file descriptor 0 (standard input). Getting both the
> message's contents and --command-fd's GET_LINE input from stardard input
> stream doesn't work, or so it seems in my tests.

If you type in 'a' at the minibuffer prompt (for accept once), does
epg continue?  It does for me.

Re: epg.el: epg--status-GET_LINE not working?

[Neal H. Walfield]

At Mon, 26 Jun 2017 09:30:00 +0200,
Daiki Ueno wrote:
> Teemu Likonen <tlikonen@iki.fi> writes:
> 
> > I have been thinking of fixing epg.el bug #24350
> > <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24350>.
> 
> I had a tentative patch for this, but I decided not to include it.
> 
> At that time, the GnuPG developers didn't seem to have a consensus on
> how TOFU is supposed to work:

FWIW, the TOFU modus operandi are unlikely to change at this stage and
have been stable for nearly a year.

> Neal suggested it should be triggered by a
> key, while Werner suggested that it should be triggered by an email
> address.
> 
> I am on Werner's side, and if the things are implemented in that way, we
> don't need to handle the conflicts in such lower level (but in the MUA
> level).

My recollection is that you said: if a recipient is specified by key
id rather than by email address (e.g., gpg is called like: 'gpg -e -r
KEYID') and the key has a conflict, the conflict should be ignored.
You justified this based on the observation that the caller knows what
is going on.

1. I disagree that this is the right behavior.

2. AFAIK, there is no precedence for this behavior in gpg.  Consider
an expired or revoked key: if you try to use it, gpg will error out
with "unusable public key."

Re: epg.el: epg--status-GET_LINE not working?

[Neal H. Walfield]

At Wed, 05 Jul 2017 18:25:29 +0200,
Daiki Ueno wrote:
> Anyway, I would rather ignore "tofu.conflict" like the attached patch
> (not tested), until it becomes really useful.

IMO, the TOFU stuff is more or less finalized on the GPG side.  What's
left is for tools that interact with GPG to integrate support for
TOFU, e.g., as described in:

  https://wiki.gnupg.org/EasyGpg2016/AutomatedEncryption

What do you think needs to be done for TOFU to become useful?

Re: epg.el: epg--status-GET_LINE not working?

[Neal H. Walfield]

At Wed, 05 Jul 2017 22:03:30 +0300,
Teemu Likonen wrote:
> Daiki Ueno [2017-07-05 18:25:29+02] wrote:
> > Teemu Likonen <tlikonen@iki.fi> writes:
> > Anyway, I would rather ignore "tofu.conflict" like the attached patch
> > (not tested), until it becomes really useful.
> 
> I agree but with a small addition. That skips the "GET_LINE
> tofu.conflict" case (which I think is good) but user is left without any
> information about what happened. Function epg-signature-to-string will
> return a string like this:
> 
>     Good signature from [keyid] [user id] created at
>     2017-07-05T21:25:57+0300 using RSA
> 
> The signature is good but the usual "(trust ...)" is missing so there is
> no information about key's validity. I suggest adding just the tofu
> conflict info. With a patch like below the mentioned function would
> return:
> 
>     Good signature from [keyid] [user id] (trust: tofu-conflict) created
>     at 2017-07-05T21:25:57+0300 using RSA

Why not implement TOFU support properly by showing the conflict and
allowing the user to resolve it instead of what appears to me to be a
workaround?

Re: epg.el: epg--status-GET_LINE not working?

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 2321 bytes --]

Neal H. Walfield [2017-07-06 21:29:30+02] wrote:

> At Mon, 26 Jun 2017 09:58:43 +0300, Teemu Likonen wrote:
>> Gpg is called with a command-line like this:
>> 
>>     GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent:0:1 /usr/bin/gpg
>>     --no-tty --status-fd 1 --yes --use-agent --command-fd 0 --output
>>     /tmp/epg-output983w_C --verify -- /tmp/epg-signature9839JJ -
>> 
>> Note that "--command-fd 0" expects interactive commands from the file
>> descriptor 0 (standard input). Such commands are handled by
>> epg--status-GET_LINE function which is triggered when "--status-fd 1"
>> output contains GET_LINE command. But also note the "-" at the end of
>> the command line. It means that the message contents is also being
>> received from the file descriptor 0 (standard input). Getting both
>> the message's contents and --command-fd's GET_LINE input from
>> stardard input stream doesn't work, or so it seems in my tests.
>
> If you type in 'a' at the minibuffer prompt (for accept once), does
> epg continue?  It does for me.

Sometimes. This works:

    M-x epa-verify-file RET signature-file.asc RET

I get tofu.conflict minibuffer prompt, can answer (e.g., "a") and gpg
behaves correctly (accepts once).

But this doesn't work:

    M-x epa-verify-region RET

I get the same minibuffer prompt but my input doesn't seem to matter.
*Messages* buffer always says:

    error in process filter: epg--status-GET_LINE: Process epg not running
    error in process filter: Process epg not running

Also, verifying a message in Gnus does the same. I get the minibuffer
prompt but *Messages* buffer always says:

    error in process filter: epg--status-GET_LINE: Process epg not running
    error in process filter: Process epg not running

And *epg-debug* buffer:

    GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent:0:1 /usr/bin/gpg
    --no-tty --status-fd 1 --yes --use-agent --command-fd 0 --output
    /tmp/epg-output9534QZ --verify -- /tmp/epg-signature953Fbf -

    [...]

    [GNUPG:] GET_LINE tofu.conflict
    [GNUPG:] GOT_IT
    [GNUPG:] GET_LINE tofu.conflict
    [GNUPG:] GOT_IT
    [GNUPG:] GET_LINE tofu.conflict
    [GNUPG:] GOT_IT
    [GNUPG:] GET_LINE tofu.conflict


I'm using Gpg 2.1.18 and Emacs 25.1, both as packaged in Debian 9.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: epg.el: epg--status-GET_LINE not working?

[Daiki Ueno]

"Neal H. Walfield" <neal@walfield.org> writes:

>> At that time, the GnuPG developers didn't seem to have a consensus on
>> how TOFU is supposed to work:
>
> FWIW, the TOFU modus operandi are unlikely to change at this stage and
> have been stable for nearly a year.

I wouldn't call it "stable" just because the code has been there for a
year.  What about the deployment?  Do you have any example of MUA
implementing this feature, other than Emacs?

> My recollection is that you said: if a recipient is specified by key
> id rather than by email address (e.g., gpg is called like: 'gpg -e -r
> KEYID') and the key has a conflict, the conflict should be ignored.

No.  My concern is why GnuPG detects a conflict, even though it is _not_
given an email address to consider (i.e. signature verification).

> 2. AFAIK, there is no precedence for this behavior in gpg.  Consider
> an expired or revoked key: if you try to use it, gpg will error out
> with "unusable public key."

Erroring out and prompting user are a different behavior.

Perhaps you implemented TOFU this way (prompting user) because you use
Wanderlust (which has bee unmaintained for years)?  If I remember
correctly, Wanderlust requires user an explicit action to verify a
signature.

On the other hand, Gnus and other major MUA automatically verify
signature without user interaction.  I like this much better and
supporting your TOFU implementation would negate this this handiness.

Regards,
-- 
Daiki Ueno

Re: epg.el: epg--status-GET_LINE not working?

[Neal H. Walfield]

At Fri, 07 Jul 2017 10:37:37 +0200,
Daiki Ueno wrote:
> "Neal H. Walfield" <neal@walfield.org> writes:
> 
> >> At that time, the GnuPG developers didn't seem to have a consensus on
> >> how TOFU is supposed to work:
> >
> > FWIW, the TOFU modus operandi are unlikely to change at this stage and
> > have been stable for nearly a year.
> 
> I wouldn't call it "stable" just because the code has been there for a
> year.  What about the deployment?  Do you have any example of MUA
> implementing this feature, other than Emacs?

Well, emacs does not implement this feature.  That's the problem.

AFAIK, currently, KMail and GpgOL implement TOFU.

> > My recollection is that you said: if a recipient is specified by key
> > id rather than by email address (e.g., gpg is called like: 'gpg -e -r
> > KEYID') and the key has a conflict, the conflict should be ignored.
> 
> No.  My concern is why GnuPG detects a conflict, even though it is _not_
> given an email address to consider (i.e. signature verification).

If you have two keys that claim the same email address and aren't
cross signed, then there is a conflict.  That is orthogonal to
verification.  If there is a conflict and someone asks: is this
signature valid?  Then the right thing to do is not to say "yes," but
to e.g. raise a warning.

> > 2. AFAIK, there is no precedence for this behavior in gpg.  Consider
> > an expired or revoked key: if you try to use it, gpg will error out
> > with "unusable public key."
> 
> Erroring out and prompting user are a different behavior.
> 
> Perhaps you implemented TOFU this way (prompting user) because you use
> Wanderlust (which has bee unmaintained for years)?

> If I remember
> correctly, Wanderlust requires user an explicit action to verify a
> signature.

I don't think so.  But maybe I have some elisp magic.  I haven't
looked in a while.

> On the other hand, Gnus and other major MUA automatically verify
> signature without user interaction.  I like this much better and
> supporting your TOFU implementation would negate this this handiness.

If you don't want to support TOFU, I can't force you to.  Yes, TOFU
requires a bit more support from the MUA side than the WoT, but TOFU
is much easier for users than curating the WoT.

Re: epg.el: epg--status-GET_LINE not working?

[Daiki Ueno]

"Neal H. Walfield" <neal@walfield.org> writes:

>> I wouldn't call it "stable" just because the code has been there for a
>> year.  What about the deployment?  Do you have any example of MUA
>> implementing this feature, other than Emacs?
>
> Well, emacs does not implement this feature.  That's the problem.
>
> AFAIK, currently, KMail and GpgOL implement TOFU.

The TOFU handling code used in KMail resides in GPGME, right?  If so I
would say TOFU hasn't got any adoption outside of the GnuPG developers.

> If you have two keys that claim the same email address and aren't
> cross signed, then there is a conflict.  That is orthogonal to
> verification.  If there is a conflict and someone asks: is this
> signature valid?  Then the right thing to do is not to say "yes," but
> to e.g. raise a warning.

Again, raising a warning and prompting user with a question are
different; the latter is more distracting, especially when the user is
reading through a mail thread and doesn't care about signature validity.

> That is orthogonal to verification.

Does that mean the prompt can pop up any time when a conflict is
detected?  If so that's even worse than I expected.

> If you don't want to support TOFU, I can't force you to.  Yes, TOFU
> requires a bit more support from the MUA side than the WoT, but TOFU
> is much easier for users than curating the WoT.

I liked the original idea, setting aside the issues in the current
implementation.

By the way, what about the status of this patch?
https://lists.gnupg.org/pipermail/gnupg-devel/2016-December/032283.html

Regards,
-- 
Daiki Ueno

Re: epg.el: epg--status-GET_LINE not working?

[Neal H. Walfield]

At Mon, 10 Jul 2017 10:31:19 +0200,
Daiki Ueno wrote:
> "Neal H. Walfield" <neal@walfield.org> writes:
> 
> >> I wouldn't call it "stable" just because the code has been there for a
> >> year.  What about the deployment?  Do you have any example of MUA
> >> implementing this feature, other than Emacs?
> >
> > Well, emacs does not implement this feature.  That's the problem.
> >
> > AFAIK, currently, KMail and GpgOL implement TOFU.
> 
> The TOFU handling code used in KMail resides in GPGME, right?  If so I
> would say TOFU hasn't got any adoption outside of the GnuPG developers.

No.  All of the UI stuff is in KMail.  Andre Heinecke is the one who
implemented it and can provide more details,

> > If you have two keys that claim the same email address and aren't
> > cross signed, then there is a conflict.  That is orthogonal to
> > verification.  If there is a conflict and someone asks: is this
> > signature valid?  Then the right thing to do is not to say "yes," but
> > to e.g. raise a warning.
> 
> Again, raising a warning and prompting user with a question are
> different; the latter is more distracting, especially when the user is
> reading through a mail thread and doesn't care about signature validity.

I'm not sure that's the right answer.  Anyway, the user can always
defer any decision by choosing accept once.

> > That is orthogonal to verification.
> 
> Does that mean the prompt can pop up any time when a conflict is
> detected?  If so that's even worse than I expected.

The user is prompted during encryption and verification.  There is no
prompt when e.g., doing a key listing.  In that case, the internal
machinery defaults to "reject once".

> > If you don't want to support TOFU, I can't force you to.  Yes, TOFU
> > requires a bit more support from the MUA side than the WoT, but TOFU
> > is much easier for users than curating the WoT.
> 
> I liked the original idea, setting aside the issues in the current
> implementation.
> 
> By the way, what about the status of this patch?
> https://lists.gnupg.org/pipermail/gnupg-devel/2016-December/032283.html

It was committed as far as I recall.