From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: security of the emacs package system, elpa, melpa and marmalade Date: Fri, 27 Sep 2013 11:47:49 -0400 Message-ID: References: <523FEE1B.9020408@binary-island.eu> <52429ABD.6090603@binary-island.eu> <52432BE9.1070402@binary-island.eu> <5243F836.9020301@binary-island.eu> <5245938E.6040906@binary-island.eu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1380297147 10736 80.91.229.3 (27 Sep 2013 15:52:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 27 Sep 2013 15:52:27 +0000 (UTC) Cc: emacs-devel@gnu.org To: Matthias Dahl Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 27 17:52:28 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 1VPaLD-0002Dm-Hs for ged-emacs-devel@m.gmane.org; Fri, 27 Sep 2013 17:52:27 +0200 Original-Received: from localhost ([::1]:37298 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VPaLD-00030c-7q for ged-emacs-devel@m.gmane.org; Fri, 27 Sep 2013 11:52:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57662) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VPaGu-0001RJ-GA for emacs-devel@gnu.org; Fri, 27 Sep 2013 11:48:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VPaGn-00024M-6m for emacs-devel@gnu.org; Fri, 27 Sep 2013 11:48:00 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:47811) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VPaGn-000248-2t for emacs-devel@gnu.org; Fri, 27 Sep 2013 11:47:53 -0400 Original-Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id r8RFlnMV000788; Fri, 27 Sep 2013 11:47:49 -0400 Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 658C5B415F; Fri, 27 Sep 2013 11:47:49 -0400 (EDT) In-Reply-To: <5245938E.6040906@binary-island.eu> (Matthias Dahl's message of "Fri, 27 Sep 2013 16:17:50 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4714=0 X-NAI-Spam-Version: 2.3.0.9362 : core <4714> : inlines <108> : streams <1045928> : uri <1549186> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:163685 Archived-At: There are many different aspects in this discussion. One is to try and come up with a technical way for Emacs's implementation to try and prevent malicious code from harming the user via some kind of sandboxing. While I do think we could hypothetically come up with some kind of sandboxing that is sufficiently flexible to be usable at least for some packages, I doubt we could make it really effective against an attacker (i.e. I doubt we could plug all the holes). So such a sandboxing would mostly work as a "sanity check" which can catch coding errors/oversights rather than malicious code. Another way to look at the problem is to perform code review. By default Emacs's packages.el only accesses GNU ELPA, where the code is not extensively reviewed, but where some attempts to install malicious code would get caught. So you could argue that the problem is not ELPA in general but "unsupervised" archives such as MELPA. Based on this, another approach (one which should not require as much knowledge of Emacs subtleties as the design and implementation of a sandboxing system) you could provide a "safe MELPA alternative" where the changes are reviewed (to some extent). Or maybe, just hack on MELPA directly to try and setup some kind reviewing system. Stefan