Re: ELPA security

[Achim Gratz]

Ted Zlatanov writes:
> SSL can easily be compromised and may not be available on all
> platforms.

I won't comment on that assertion, but in any case transport layer
security solves only a tiny part of the problem.

As far as the end user is concerned, what she really needs to know is
that the files on disk have not been tampered with compared to what the
maintainer intended to distribute.  This is a general problem with
Emacs, not just with ELPA and the solution IMHO doesn't lie with the
development process either (it's good to have a verifyable development
process, but that doesn't address the problem at hand).  So there are at
least three checks to make: check the metadata before the download, then
the downloaded archive itself and then again that the stuff unpacked
from that archive matches the distribution.  Lastly, maybe a fourth
check that after compiling the package no extra or missing files are
recorded.

This can be done via checksumming and comparison with a manifest, which
in turn needs to be signed.  Optimally the manifest would be signed by
the maintainer(s) of the package upon release and then again by whoever
runs the package archive upon publication, preferrably with some note
that the maintainer credentials have been checked successfully and when.
Also the metadata should be signed so that a rogue ELPA server or mirror
can not distribute files to the end user easily.  Since installing a
package produces additional files, they should probably be listed in the
manifest (without checksum) to ensure that no malicious files are
planted upon installation.

That moves all the authenticity issues to the signatures or rather the
trust you have in the keys used to produce them.  CPAN/PAUSE can be used
as an example of how something like this works out in practise (Debian
apt or openSUSE zypper are further examples, but they operate on a
different scale).  Emacs would need to be deployed so that it knows its
own signing key as well as the (preferably separate) key for ELPA.  I
don't think that it should implicitly trust them, though, so the user
should explicitly consent to trusting the key (either temporarily or
permanently).

Note that (D)VCS doesn't come into play at any level of this unless you
intend to publish packages directly from the DVCS they are developed in.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables