Handling a TOFU conflict

[Andre Heinecke]

Hi,

On Tuesday 06 December 2016 15:09:13 Neal H. Walfield wrote:
> Currently, when a TOFU conflict is encountered, the --status-fd
> transcript looks like the following:

 ...

> The MUA has to manually figure out what the conflicting keys are and
> gather the statistics.  In addition to the extra work for the
> programmer and the minor computational overhead, this introduces a
> small race.  Further, it means that the MUA has to know that conflicts
> are based on the email address (and not whole user id) as well as any
> normalization rules that we use.  Currently, we only lowercase the
> email address, but one could imagine adding support for google's
> aliases ('.'s don't mean anything) and puny code.

I don't think this is a problem, gpgme exposes the mail normalsation as API 
and I don't see a security problem with a race for the additional keylisting.
Do you have concerns there?

A mua needs the E-Mail normalisation anyway to provide the argument for
--sender.

> I think that we should change this to print the stats for each
> conflicting binding before the tofu.conflict prompt is emitted.  For
> this, I propose either using pairs of TOFU_USER/TOFU_STATS lines or
> just using the TOFU_STATS line, but extending it to include the
> required context (i.e., the fingerprint and the mbox).  Thus, the
> --status-fd output could look like this:
> 
>   [GNUPG:] KEY_CONSIDERED 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 0
>   [GNUPG:] TOFU_USER <fingerprint> <mbox>
>   [GNUPG:] TOFU_STATS ...
>   [GNUPG:] TOFU_USER <fingerprint2> <mbox>
>   [GNUPG:] TOFU_STATS ...
>   [GNUPG:] GET_LINE tofu.conflict
> 
> I'm confident that this would at least simplify the TOFU integration
> in EPG.  Other thoughts?

I think this complicates things and creates work as we have to add this to 
GpgME, too and is not neccessary.
Altough I have no strong objection if you impement this. It would be 
additional information and it may help others.

I currently don't think that I need information about an old key at all in 
case of a conflict in the user interface. But that's a different discussion. :-)


Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20161207/6489b474/attachment.sig>