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" <address@hidden> 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.