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

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

> But apart from that, there is naturally also the other side: Security
> leaks due to bad code caused simply by inexperience which could be
> exploited.

Security problems in Emacs are everywhere, indeed.  We just try to plug
the most glaring holes.

> One idea thrown into discussion: We could differentiate between core and
> non-core functions. This would allow the introduction of a new
> permission like "re-define core function"... which naturally is like
> granting a program root access.

But there's also all the never ending list of hooks, plus the dynamic
scoping, and of course, the problem of defining and tracking the
"principal" corresponding to the code currently running.

If you think for example of a typical package providing a major mode for
a programming language, the "core" functionality can be provided with
the constraint that you can "only affect the current-buffer", "only
define new functions", but it will have to be able to set buffer-local
variables and hooks and define a major mode map which might rebind
global bindings, thus tricking you potentially into running code you did
not intend.

And, it'll naturally want to provide some support for running the
compiler/interpreter for that language, so it'll require the ability to
run an external command, which of course begs the question of "how to
make sure that external command doesn't send a tarball of your home
directory to google".


        Stefan