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

[Stephen J. Turnbull]

Matthias Dahl writes:

 > > Then your model of security is inadequate.  Software is *inherently*
 > > insecure.
 > 
 > Agreed. But if someone says there are security leaks all over the
 > place,

I didn't read Stefan as saying "leaks", I read him as saying "Emacs is
not designed to be your security nanny."

 > that is a different story. This implies those are tolerated for
 > various reasons.

Well, sure.  A concrete block is inherently more secure against an
earthquake than a building.  That doesn't mean we should replace the
latter with the former.

 > But they do exist and should be fixed, nevertheless.

And they are fixed, frequently.  For example, "safe" and "risky" local
variables.

 > Agreed. But this doesn't imply that the user should be powerless against
 > 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.

I gather you haven't read Ken Thompson's ACM address recently.

 > Right now there is absolutely nothing stopping a hacked plugin to do
 > just about anything until the community or the user somehow notices
 > this.

Sure.  But the problem of making a sandbox is very hard.  Python gave
up.  Maybe the Emacs people are smarter, but the Python developers
aren't dumb.

 > And what would you suggest in terms of ELPA / Marmalade and MELPA and
 > the package system in general based on this...?

If you care, don't use them.  On my exposed system, I don't install
any XEmacs packages that I don't absolutely need.