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

["Neal H. Walfield" <neal@walfield.org>]

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.