From: Matthias Dahl <ml_emacs-lists@binary-island.eu>
To: "Stephen J. Turnbull" <stephen@xemacs.org>
Cc: Stefan Monnier <monnier@IRO.UMontreal.CA>, emacs-devel@gnu.org
Subject: Re: security of the emacs package system, elpa, melpa and marmalade
Date: Fri, 27 Sep 2013 16:18:08 +0200 [thread overview]
Message-ID: <524593A0.7020502@binary-island.eu> (raw)
In-Reply-To: <87a9iy2106.fsf@uwakimon.sk.tsukuba.ac.jp>
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
next prev parent reply other threads:[~2013-09-27 14:18 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-23 7:30 security of the emacs package system, elpa, melpa and marmalade Matthias Dahl
2013-09-23 14:17 ` Stefan Monnier
2013-09-25 8:11 ` Matthias Dahl
2013-09-25 17:00 ` Stefan Monnier
2013-09-25 18:31 ` Matthias Dahl
2013-09-25 22:42 ` Bastien
2013-09-26 9:02 ` Matthias Dahl
2013-09-27 14:02 ` Bastien
2013-09-27 14:17 ` Matthias Dahl
2013-09-27 14:19 ` Bastien
2013-09-27 18:29 ` Matthias Dahl
2013-09-26 1:09 ` Stefan Monnier
2013-09-26 9:02 ` Matthias Dahl
2013-09-26 9:21 ` Óscar Fuentes
2013-09-26 14:41 ` Stefan Monnier
2013-09-27 14:17 ` Matthias Dahl
2013-09-27 15:47 ` Stefan Monnier
2013-09-28 14:15 ` Richard Stallman
2013-09-30 15:12 ` Matthias Dahl
2013-09-30 21:11 ` Richard Stallman
2013-09-30 15:31 ` Matthias Dahl
2013-09-26 1:12 ` Stephen J. Turnbull
2013-09-26 9:02 ` Matthias Dahl
2013-09-27 7:10 ` Stephen J. Turnbull
2013-09-27 14:18 ` Matthias Dahl [this message]
2013-09-27 17:31 ` Stephen J. Turnbull
2013-09-30 15:25 ` Matthias Dahl
2013-10-01 2:19 ` Stephen J. Turnbull
2013-09-27 20:12 ` chad
2013-09-26 9:31 ` Andreas Röhler
2013-09-26 16:25 ` Richard Stallman
2013-09-27 14:18 ` Matthias Dahl
2013-09-27 15:04 ` Óscar Fuentes
2014-09-13 17:57 ` Thomas Koch
2013-09-29 10:12 ` Ted Zlatanov
2013-09-29 9:53 ` Ted Zlatanov
2013-09-29 17:49 ` Daiki Ueno
2013-09-29 18:18 ` Ted Zlatanov
2013-09-30 13:25 ` Ted Zlatanov
2013-09-30 14:50 ` Stephen J. Turnbull
2013-09-30 15:10 ` Matthias Dahl
2013-09-30 17:18 ` Ted Zlatanov
2013-10-01 14:03 ` Matthias Dahl
2013-10-02 2:45 ` Stephen J. Turnbull
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=524593A0.7020502@binary-island.eu \
--to=ml_emacs-lists@binary-island.eu \
--cc=emacs-devel@gnu.org \
--cc=monnier@IRO.UMontreal.CA \
--cc=stephen@xemacs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.