[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stefan Monnier
Subject: Re: security of the emacs package system, elpa, melpa and marmalade
Date: Wed, 25 Sep 2013 13:00:40 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

> 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".


reply via email to

[Prev in Thread] Current Thread [Next in Thread]