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

[Matthias Dahl <ml_emacs-lists@binary-island.eu>]

Hello Stephen...

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

Well, only Stefan can clarify this. But if it was the latter, even
though I do agree, it does absolutely not imply that we should keep the
doors widely open and make no effort to support the user wrt to security.

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

Stephen, I'm not advocating we should all drive around in an armored car
or never ever connect our computers with the evil internet or whatever.

I'm also _not_ saying or implying that we should make Emacs "secure" as
I know all too well that there is no such thing. But one can always make
a best effort.

All I am saying is: It would be very helpful if we could give the user a
few tools to handle, grasp and maybe harden certain security aspects.
And in this concrete discussion: It is all about plugins who, once they
are installed through whatever means, can also do whatever they choose.

You wouldn't work as root on your system, would you? And why should a
plugin get full rights if just needs a few infos from the local buffer?

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

If you mean "Reflections on Trusting Trust" and to quote: "You can't
trust code that you did not totally create yourself.". If you mean that,
I fully agree.

But the reality is, we have to use software that others created. And the
open source/free software world is full of great minds and talents that
create astounding pieces of software. And those people working pouring
the time and life into those projects, usually would never place
any malicious code into their creations. It is through hacks or other
circumstances that such things happen. The world is not inherently evil.

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

I fully agree, again. And I'm not saying a sandbox is the best solution.
I'm after a discussion about the problem... which might even lead to a
totally unexpected solution.

I did not know that the Python devs worked on a sandbox, honestly. But
the problem here is a bit more "relaxed", imho. We are not talking about
hardening / sandboxing a language in general but only a very concrete
functionality in a specific program (which, granted, is very tightly
intervened with the language it is written in).

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

This may reduce the risk but is this really a solution? Say you use only
the great jedi.el for your Python development. I am sure that its author
Takafumi Arakaki would never put anything harmful in it... but I can
imagine several scenarios how something harmful could end up in it
nevertheless without him noticing it for a while.

So long,
Matthias

-- 
Dipl.-Inf. (FH) Matthias Dahl | Software Engineer | binary-island.eu
 services: custom software [desktop, mobile, web], server administration