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

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

There are many different aspects in this discussion.

One is to try and come up with a technical way for Emacs's
implementation to try and prevent malicious code from harming the user
via some kind of sandboxing.  While I do think we could hypothetically
come up with some kind of sandboxing that is sufficiently flexible to be
usable at least for some packages, I doubt we could make it really
effective against an attacker (i.e. I doubt we could plug all the
holes).

So such a sandboxing would mostly work as a "sanity check" which can
catch coding errors/oversights rather than malicious code.

Another way to look at the problem is to perform code review.
By default Emacs's packages.el only accesses GNU ELPA, where the code is
not extensively reviewed, but where some attempts to install malicious
code would get caught.

So you could argue that the problem is not ELPA in general but
"unsupervised" archives such as MELPA.  Based on this, another approach
(one which should not require as much knowledge of Emacs subtleties as
the design and implementation of a sandboxing system) you could provide
a "safe MELPA alternative" where the changes are reviewed (to some
extent).  Or maybe, just hack on MELPA directly to try and setup some
kind reviewing system.


        Stefan