Re: package.el + DVCS for security and convenience

["Stephen J. Turnbull" <stephen@xemacs.org>]

Ted Zlatanov writes:

 > The problem then is how to verify GPG signatures, especially if GnuPG is
 > not installed.  OTOH verifying signed tags in Git and signed commits in
 > Bazaar is part of the base packages, so it requires no more than having
 > them installed.

Regarding the social side, sure, Windows users and perhaps proprietary
*nix users are less likely to have GPG or (oh, the horrors) PGP
installed, but it's not like they're unavailable.  Even for Mac OS X
(Hurray! er, I mean "Hiss, boo!"), GPG2 is available in all the popular
add-on distributions.

People who for reasons of corporate policy can't install those tools
themselves aren't going to have free access to ELPA, either (and
anyway their security bureaucracy has taken that responsibility on
itself).  People who won't install GPG, won't use the feature anyway
(by which I mean, they will ignore security warnings which are often
false alarms, disable them entirely on the third false alarm, won't go
to the effort of getting updated public keys for when they're offline,
etc), and if key distribution is implemented automatically they're at
great risk from man-in-the-middle and phishing-type attacks.

The GPG documentation is full of warnings about doing it yourself, and
recommends using the GUI or the command-line interface.  ISTR at one
time they didn't even provide libraries (do they now?) for that reason.

I'm sure we've all seen some of the horror stories of what sometimes
happens to competent programmers who implement the protocols
themselves on RISKS (not to mention really terrifying stories like
"The 16,384 Keys of Debian").  Remember, as soon as Emacs distributes
something, hordes of users are potential users of the feature.  That
may make it an attractive target for an attack.  Anything built in to
Emacs needs to be *strong*.  Is it worth that much effort?

Why not just start with the relatively easy optional verification of
signed files based on an installed OpenPG tool, and add pluggable
verification modules as people have interest?

 > I still think public-key cryptography and asymmetric ciphers are the
 > answer here,

I'm pretty sure the people who *really* know what they're doing[1]
will agree with you.

 > but I don't know how much we want to depend on external tools or
 > libraries for package installations, and how willing we are to make
 > installations insecure if those tools or libraries are not
 > available.  So I need the maintainers' wise opinion :)

"Only YOU can prevent forest fires" -- Smokey the Bear

But they happen *unnecessarily* anyway, because people ignore the
simple rules posted at every campground and entrance to wilderness
areas.

FWIW, I recommend providing security features as suggested above for
those who *want* them, at first.  Provide reasonably secure
automation, and enable it by default.  If disabled, encourage
reenabling, perhaps by changing the control variable name every
release ;-).

Footnotes: 
[1]  On the Internet, nobody knows that you're Bruce Schneier.  But
I'm not.  :-)