Re: security of the emacs package system, elpa, melpa and marmalade

[Stefan Monnier <monnier@iro.umontreal.ca>]

> I know there has been a thread about (more or less) this topic sometime
> last year, iirc. But I was unable to find something current, so I hope
> it is okay to raise a few questions and ideas about this subject.

The current state, AFAIK is that we decided that ELPA servers should
put *.gpg signatures alongside their tarballs and other files, signed
with an "archive" key.  This signature can be used to check that the
package you get indeed comes from that archive.

In terms of code, it's not implemented yet, AFAIK (IIRC Ted is working
on it).

> The best solution imho would be that each package on a package server,
> no matter which one, is reviewed before being available either through a
> dedicated staff of volunteers or through a more open process that makes
> use of the user base somehow (which could be very difficult in terms of
> trustworthiness).

Not gonna happen, indeed.  It doesn't happen for Debian either, FWIW, so
it's usually not considered as a very major problem.

W.r.t. GNU ELPA packages, every commit installed send an email
containing the diff to a mailing-list to which some people are
subscribed, so there is a bit of review there, but it's far from
sufficient to prevent introduction of security problems.

> So, I'd like to propose the following as at least some measure of
> protection and a first step in making the package system more secure: A
> package gets a security context which details its very own permissions
> just like e.g. an Android app. That context is permanent, meaning that

Sandboxing could be an interesting direction, but it seems very
difficult: not only it'll be a non-trivial amount of implementation
work, but even just designing it will be difficult, due to the current
nature of Emacs's design where everything is global and shared.


        Stefan