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: Wed, 25 Sep 2013 13:00:40 -0400 Message-ID: References: <523FEE1B.9020408@binary-island.eu> <52429ABD.6090603@binary-island.eu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1380128467 10465 80.91.229.3 (25 Sep 2013 17:01:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Sep 2013 17:01:07 +0000 (UTC) Cc: emacs-devel@gnu.org To: Matthias Dahl Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 25 19:01:09 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 1VOsSV-00021g-AB for ged-emacs-devel@m.gmane.org; Wed, 25 Sep 2013 19:01:03 +0200 Original-Received: from localhost ([::1]:54000 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VOsSU-0005bo-Si for ged-emacs-devel@m.gmane.org; Wed, 25 Sep 2013 13:01:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38856) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VOsSK-0005YW-I9 for emacs-devel@gnu.org; Wed, 25 Sep 2013 13:00:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VOsSB-0005bM-MX for emacs-devel@gnu.org; Wed, 25 Sep 2013 13:00:52 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:37266) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VOsSB-0005bH-Be for emacs-devel@gnu.org; Wed, 25 Sep 2013 13:00:43 -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 r8PH0eIN019909; Wed, 25 Sep 2013 13:00:40 -0400 Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 60ED0B4102; Wed, 25 Sep 2013 13:00:40 -0400 (EDT) In-Reply-To: <52429ABD.6090603@binary-island.eu> (Matthias Dahl's message of "Wed, 25 Sep 2013 10:11:41 +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 RV4712=0 X-NAI-Spam-Version: 2.3.0.9362 : core <4712> : inlines <101> : streams <1044645> : uri <1547292> 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:163638 Archived-At: > 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. Security problems in Emacs are everywhere, indeed. We just try to plug the most glaring holes. > 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. But there's also all the never ending list of hooks, plus the dynamic scoping, and of course, the problem of defining and tracking the "principal" corresponding to the code currently running. If you think for example of a typical package providing a major mode for a programming language, the "core" functionality can be provided with the constraint that you can "only affect the current-buffer", "only define new functions", but it will have to be able to set buffer-local variables and hooks and define a major mode map which might rebind global bindings, thus tricking you potentially into running code you did not intend. And, it'll naturally want to provide some support for running the compiler/interpreter for that language, so it'll require the ability to run an external command, which of course begs the question of "how to make sure that external command doesn't send a tarball of your home directory to google". Stefan