From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: security of the emacs package system, elpa, melpa and marmalade Date: Sun, 29 Sep 2013 05:53:36 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87y56gymvz.fsf@flea.lifelogs.com> References: <523FEE1B.9020408@binary-island.eu> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1380448437 13181 80.91.229.3 (29 Sep 2013 09:53:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 29 Sep 2013 09:53:57 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 29 11:54:01 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 1VQDhR-0002r2-3c for ged-emacs-devel@m.gmane.org; Sun, 29 Sep 2013 11:54:01 +0200 Original-Received: from localhost ([::1]:44075 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VQDhQ-0002aQ-PY for ged-emacs-devel@m.gmane.org; Sun, 29 Sep 2013 05:54:00 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46658) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VQDhI-0002aG-SP for emacs-devel@gnu.org; Sun, 29 Sep 2013 05:53:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VQDhC-00078M-Ig for emacs-devel@gnu.org; Sun, 29 Sep 2013 05:53:52 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:40486) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VQDhC-00078G-8g for emacs-devel@gnu.org; Sun, 29 Sep 2013 05:53:46 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VQDhA-0002c6-6e for emacs-devel@gnu.org; Sun, 29 Sep 2013 11:53:44 +0200 Original-Received: from c-98-229-61-72.hsd1.ma.comcast.net ([98.229.61.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 29 Sep 2013 11:53:44 +0200 Original-Received: from tzz by c-98-229-61-72.hsd1.ma.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 29 Sep 2013 11:53:44 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 80 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-98-229-61-72.hsd1.ma.comcast.net X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:SdQEndSrZ1w/eYkjsULtDTKN9zI= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:163710 Archived-At: On Mon, 23 Sep 2013 10:17:33 -0400 Stefan Monnier wrote: >> 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. SM> The current state, AFAIK is that we decided that ELPA servers should SM> put *.gpg signatures alongside their tarballs and other files, signed SM> with an "archive" key. This signature can be used to check that the SM> package you get indeed comes from that archive. SM> In terms of code, it's not implemented yet, AFAIK (IIRC Ted is working SM> on it). VERY slowly. I tried to get back to it, only to find out (see other thread under subject "bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt") that GPG2 is practically unusable. Frustrating. As I've mentioned in the past, I dislike relying on an external binary like GPG to do encryption so this is pushing me again towards a more built-in Lispy way to do signing of packages. Opinions welcome, especially if you can think of a way that Emacs can sign files in a similar way to GPG keys in Lisp. In any case, I posted a patch (probably needs to be rewritten by now) which intercepted package.el file requests and required an additional .sig file that signed the file. So any file, tarball, or index requires a maintainer signature to be used. >> 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). SM> Not gonna happen, indeed. It doesn't happen for Debian either, FWIW, so SM> it's usually not considered as a very major problem. SM> W.r.t. GNU ELPA packages, every commit installed send an email SM> containing the diff to a mailing-list to which some people are SM> subscribed, so there is a bit of review there, but it's far from SM> sufficient to prevent introduction of security problems. Stefan, I don't know if you remember it the same way, but when I worked with you on getting ELPA started, I recall I had the maintainer rolling out updates manually after review. We added the cron job later (maybe I was involved, I honestly don't remember) but I definitely wanted to avoid the current situation where updates to GNU ELPA packages get rolled out straight to our users without review. Unlike VCS updates, the GNU ELPA updates go to live users who don't know they may be using bleeding-edge or risky code, and IMHO should be gated by some kind of maintainer review or at least marked as "unreviewed update" in the UI. The auto-merging of external repos is an even bigger issue; again we need to establish a wall between developers and our live users but here we trust external groups of contributors to DTRT. I would propose using the signature files above to provide that wall, so auto-signing should not be done. Instead a maintainer team should review changes that need to go up on the GNU ELPA. >> 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 SM> Sandboxing could be an interesting direction, but it seems very SM> difficult: not only it'll be a non-trivial amount of implementation SM> work, but even just designing it will be difficult, due to the current SM> nature of Emacs's design where everything is global and shared. There are too many ways to compromise Emacs Lisp because it was not written with security in mind. Also see my previous proposals for secure data storage in Emacs, which would certainly be relevant if we consider external packages as a possible attack vector. Even that relatively minor improvement has met significant resistance; I would imagine a full security-oriented redesign would be as popular as SELinux. Ted