Re: ELPA security

[Ted Zlatanov <tzz@lifelogs.com>]

On Sat, 05 Jan 2013 17:46:19 +0100 Achim Gratz <Stromeko@nexgo.de> wrote: 

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

AG> So there are at least three checks to make: check the metadata
AG> before the download, then the downloaded archive itself and then
AG> again that the stuff unpacked from that archive matches the
AG> distribution.  Lastly, maybe a fourth check that after compiling the
AG> package no extra or missing files are recorded.

AG> This can be done via checksumming and comparison with a manifest, which
AG> in turn needs to be signed.

I think it's easier to simply require that every file have its own .sig
and avoid the verification chain from manifest to archive contents.
Then we rely on GPG to handle signing and verification for us, no matter
who actually generates the .sig files (as long as their signing key is
trusted by us).  I don't think checksums have any advantage there, but
maybe you see some?

I think the GNU ELPA maintainers should sign everything, but that's
debatable and not essential to the proposal.

AG> Since installing a package produces additional files, they should
AG> probably be listed in the manifest (without checksum) to ensure that
AG> no malicious files are planted upon installation.

I don't know if that's needed, but have no problem with it as a feature.

AG> That moves all the authenticity issues to the signatures or rather the
AG> trust you have in the keys used to produce them.

Yes, that's exactly what I'm trying to accomplish, instead of relying on
SSL/TLS or other transport-level solutions.

AG> Emacs would need to be deployed so that it knows its own signing key
AG> as well as the (preferably separate) key for ELPA.  I don't think
AG> that it should implicitly trust them, though, so the user should
AG> explicitly consent to trusting the key (either temporarily or
AG> permanently).

I think `package-list' has to work without prompts or configuration.
You should have to specifically exclude the GNU ELPA maintainers' keys
from your default (`emacs -q') configuration in order not to trust them.

Ted