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: Wed, 25 Sep 2013 10:11:41 +0200 Message-ID: <52429ABD.6090603@binary-island.eu> References: <523FEE1B.9020408@binary-island.eu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1380096722 26789 80.91.229.3 (25 Sep 2013 08:12:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Sep 2013 08:12:02 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 25 10:12:04 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 1VOkCX-0005Sk-S4 for ged-emacs-devel@m.gmane.org; Wed, 25 Sep 2013 10:12:02 +0200 Original-Received: from localhost ([::1]:50583 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VOkCX-000398-DS for ged-emacs-devel@m.gmane.org; Wed, 25 Sep 2013 04:12:01 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38596) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VOkCN-0002zh-4S for emacs-devel@gnu.org; Wed, 25 Sep 2013 04:11:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VOkCG-0003AI-Lj for emacs-devel@gnu.org; Wed, 25 Sep 2013 04:11:51 -0400 Original-Received: from hemera.binary-island.eu ([97.107.138.233]:44934) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VOkCG-00036f-75 for emacs-devel@gnu.org; Wed, 25 Sep 2013 04:11:44 -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 3F4633C083; Wed, 25 Sep 2013 04:13:48 -0400 (EDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 In-Reply-To: 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:163629 Archived-At: Hello Stefan... > The current state, AFAIK is that we decided that ELPA servers should > put *.gpg signatures alongside their tarballs and other files, signed > with an "archive" key. This signature can be used to check that the > package you get indeed comes from that archive. Which is absolutely fabulous and will make it harder to temper with packages on one of the package repositories. Suffice to say, this won't do anything for preventing malicious code from (a hacked) upstream slipping through -- and this approach is not feasible for MELPA which is becoming (afaict) more and more popular these days. > Not gonna happen, indeed. It doesn't happen for Debian either, FWIW, so > it's usually not considered as a very major problem. The situation with Debian (and any other well maintained distro) is a bit different, imho. There are dedicated distro maintainers taking care of their packages and some distros also have a QA procedure. There are usually just more eyes watching and testing. Also, a lot of those upstream projects have a team of people working on their project which will make tempering on a decent dvcs easier to spot. In the Emacs ecosystem, people take code from the wiki or from any of the package repositories, knowing nothing about usually the single person who wrote said package... especially nothing about how security of their accounts is handled in terms of passwords, pubkeys and whatever. So a github could get hacked, malicious code placed without the maintainer even noticing for a very long period because he just moved on. And so on... Granted, those are all absolutely worst-case scenarios and one could argue for days about how likely and relevant such incidents really are. 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. > Sandboxing could be an interesting direction, but it seems very > difficult: not only it'll be a non-trivial amount of implementation > work, but even just designing it will be difficult, due to the current > nature of Emacs's design where everything is global and shared. I've been thinking about this really hard as well. And I've to admit, I'm not (at least not yet) an Emacs/elisp expert. But not every package needs to overwrite some core functions. 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. A core function could be, imho, any function that comes bundled with Emacs when it starts up - possibly including init.el and the user's modifications. If the user decides to load packages on his own, we could provide a new argument to load-file to pass a permission context in. And naturally, to avoid any priviledge escalation, we'd only allow permission narrowing and never widening. But I already touched that in my last mail. I agree, such a "sandbox" project would be quite an endeavour to take on and would require a great deal of careful designing and implementing. The question is this: Would there be any interest and motivation from the current dev community to drive such an endeavour? Because otherwise such a project would be doomed to fail, imho. Sorry for my late reply, by the way. I am currently fighting a nasty kind of human virus. I already tried putting my hand on the CPU and running an anti-virus scanner which surprisingly did not work. ;-) So long, Matthias -- Dipl.-Inf. (FH) Matthias Dahl | Software Engineer | binary-island.eu services: custom software [desktop, mobile, web], server administration