From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Matthias Dahl Newsgroups: gmane.emacs.devel Subject: Re: security of the emacs package system, elpa, melpa and marmalade Date: Fri, 27 Sep 2013 16:18:08 +0200 Message-ID: <524593A0.7020502@binary-island.eu> References: <523FEE1B.9020408@binary-island.eu> <52429ABD.6090603@binary-island.eu> <52432BE9.1070402@binary-island.eu> <87d2nw1j3b.fsf@uwakimon.sk.tsukuba.ac.jp> <5243F828.6060901@binary-island.eu> <87a9iy2106.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1380291521 901 80.91.229.3 (27 Sep 2013 14:18:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 27 Sep 2013 14:18:41 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 27 16:18:45 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VPYsW-0001m5-Ku for ged-emacs-devel@m.gmane.org; Fri, 27 Sep 2013 16:18:44 +0200 Original-Received: from localhost ([::1]:36849 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VPYsW-0002dl-6e for ged-emacs-devel@m.gmane.org; Fri, 27 Sep 2013 10:18:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34475) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VPYs4-0001og-DJ for emacs-devel@gnu.org; Fri, 27 Sep 2013 10:18:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VPYrx-0006bo-MO for emacs-devel@gnu.org; Fri, 27 Sep 2013 10:18:16 -0400 Original-Received: from hemera.binary-island.eu ([97.107.138.233]:51545) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VPYrx-0006bc-Fu for emacs-devel@gnu.org; Fri, 27 Sep 2013 10:18:09 -0400 Original-Received: from [10.0.0.20] (95-88-238-193-dynip.superkabel.de [95.88.238.193]) by hemera.binary-island.eu (Postfix) with ESMTPSA id 31C693C27F; Fri, 27 Sep 2013 10:20:18 -0400 (EDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 In-Reply-To: <87a9iy2106.fsf@uwakimon.sk.tsukuba.ac.jp> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 97.107.138.233 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:163680 Archived-At: 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