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

[Stefan Monnier]

>> So I think the only way to attack the problem is to perform experiments
>> to get a feel for what might work and what problems show up.
> Ah, justice. I knew this would come back to me and bite me. ;) I know
> that since I am the one who started this discussion, it is expected of
> me (or considered good manors) that I volunteer to do so. And I'd in all
> honesty gladly jump on in... but my familiarity with the code base is
> very far from sufficient for this. This is something for someone with a
> very strong grasp of Elisp and Emacs, imho. :(

I suggest you lead the charge while asking for help at the same time.
Concretely, you could do something along the following lines:
- decide some set of rules that a package should follow.  Make those
  *very* simple (i.e. simplistic) for now.  E.g. "can only access
  current-buffer".
- try to figure out a way to implement it (without regards for
  efficiency, for a start).
- see how it works with existing packages.
- try to write something nasty to see if your rules are actually useful.
- iterate the process.

> each and every plugin he installs. One can assume that the Emacs code
> base does not contain any malicious code and is thus "secure" at least
> in this regard. Naturally there are holes - known and unknown. The key,

The set of people with commit access to Emacs is the same as the set of
people with commit access to GNU ELPA (includes more than a hundred
people, some of whom are not expert programmers).  And both repositories
send diff-emails for every commit installed in it.

So the main difference is that many more people clone/checkout the Emacs
repository than the GNU ELPA repository.


        Stefan