Houston, we have a problem

[Andrew Gallagher]

On 26/09/17 20:39, Werner Koch wrote:
> On Tue, 26 Sep 2017 13:07, andrewg at andrewg.com said:
> 
>> The gpg command itself should cryptographically verify signatures when
>> performing --list-sigs, so that at least it can throw a warning when an
> 
> Actually --list-sigs is more of a debug command than a command users
> should use to verify a key.  The real command is --check-sigs and it
> does what you suggested. 

I've been using gpg for decades, and I was unaware of the distinction.
Thanks!

But a follow-on question arises: is Enigmail using --list-sigs rather
than --check-sigs? Its output appears to be derived from --list-sigs,
which undermines somewhat the rationale behind only displaying sigs from
known keys.

> Unfortunately the man pages describes --list-sigs in detail and only in
> the next paragraph --check-sigs is explained in terms of --list-sigs.
> it might be better to merge them into one description with a focus on
> --check-sigs.

Or just describe --check-sigs and have --list-sigs tucked away in an
"experts only, beware" section.

This is the sort of thing I was thinking of when I talked about
"railroading the user" earlier. There are two ways of doing something,
one is more secure than the other but it's not immediately clear which,
and the casual user therefore has *too much* choice. This has two
effects: 1. the user may choose the less secure option by accident; 2.
the user is frightened of using the software for fear of choosing the
less secure option by accident.

And if you do choose the less secure option by accident, there's no
feedback to tell you that you're off the reservation. I've been using
--list-sigs forever and I thought I was getting --check-sigs. At no time
did gpg disabuse me of that. I hear the arguments about users becoming
reliant on warnings, but warnings in this case aren't about telling
people that something unexpected has happened - they're about telling
users that they're doing it wrong. Once they learn how to do things
right, they become *less* reliant on the warnings, not more.

> Anyway, it is easy to create keys just for signatures and --check-sigs
> would not make a difference.  Look at my key for all those vanity
> signature.

Yes, but unless a collision is found (in which case we're all screwed),
a signature made by a fake key will have a distinct fingerprint, and
we've reduced the problem space back to fake keys, which at least have
the advantage of being well-known. An option such as Enigmail's "don't
display unknown sigs" can handle that. Furthermore, if "don't display
unknown sigs" was default behaviour everywhere, it would remove the
incentive to make wasteful vanity sigs in the first place.

-- 
Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170927/c74fbb5b/attachment.sig>