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: Mon, 23 Sep 2013 10:17:33 -0400 Message-ID: References: <523FEE1B.9020408@binary-island.eu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1379945874 15309 80.91.229.3 (23 Sep 2013 14:17:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Sep 2013 14:17:54 +0000 (UTC) Cc: emacs-devel@gnu.org To: Matthias Dahl Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 23 16:17:54 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 1VO6xW-0007ld-8w for ged-emacs-devel@m.gmane.org; Mon, 23 Sep 2013 16:17:54 +0200 Original-Received: from localhost ([::1]:40952 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VO6xV-000870-Q4 for ged-emacs-devel@m.gmane.org; Mon, 23 Sep 2013 10:17:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41334) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VO6xK-0007wN-T7 for emacs-devel@gnu.org; Mon, 23 Sep 2013 10:17:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VO6xD-0002uc-Ji for emacs-devel@gnu.org; Mon, 23 Sep 2013 10:17:42 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:18863) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VO6xD-0002uO-FE for emacs-devel@gnu.org; Mon, 23 Sep 2013 10:17:35 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFFsoXM0/2dsb2JhbABEvw4Xc4IeAQEEAVYYCwULCw4mEhQYDSQuh3AGwS2ND4N7A5JbA5IcgV6DE4FT X-IPAS-Result: Av8EABK/CFFsoXM0/2dsb2JhbABEvw4Xc4IeAQEEAVYYCwULCw4mEhQYDSQuh3AGwS2ND4N7A5JbA5IcgV6DE4FT X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="28801331" Original-Received: from 108-161-115-52.dsl.teksavvy.com (HELO pastel.home) ([108.161.115.52]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 23 Sep 2013 10:13:26 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id E42A162D9D; Mon, 23 Sep 2013 10:17:33 -0400 (EDT) In-Reply-To: <523FEE1B.9020408@binary-island.eu> (Matthias Dahl's message of "Mon, 23 Sep 2013 09:30:35 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 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:163581 Archived-At: > I know there has been a thread about (more or less) this topic sometime > last year, iirc. But I was unable to find something current, so I hope > it is okay to raise a few questions and ideas about this subject. 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. In terms of code, it's not implemented yet, AFAIK (IIRC Ted is working on it). > The best solution imho would be that each package on a package server, > no matter which one, is reviewed before being available either through a > dedicated staff of volunteers or through a more open process that makes > use of the user base somehow (which could be very difficult in terms of > trustworthiness). Not gonna happen, indeed. It doesn't happen for Debian either, FWIW, so it's usually not considered as a very major problem. W.r.t. GNU ELPA packages, every commit installed send an email containing the diff to a mailing-list to which some people are subscribed, so there is a bit of review there, but it's far from sufficient to prevent introduction of security problems. > So, I'd like to propose the following as at least some measure of > protection and a first step in making the package system more secure: A > package gets a security context which details its very own permissions > just like e.g. an Android app. That context is permanent, meaning that 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. Stefan