From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: package security auditing and isolation Date: Thu, 06 Apr 2017 17:57:34 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87y3vdyzap.fsf@lifelogs.com> References: <87h9211v1c.fsf@lifelogs.com> <87d1cp1qvd.fsf@lifelogs.com> <8737dl1gol.fsf@lifelogs.com> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1491515893 23643 195.159.176.226 (6 Apr 2017 21:58:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 6 Apr 2017 21:58:13 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 06 23:58:09 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwFPs-0005cn-BQ for ged-emacs-devel@m.gmane.org; Thu, 06 Apr 2017 23:58:08 +0200 Original-Received: from localhost ([::1]:47824 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cwFPx-0001KK-Rz for ged-emacs-devel@m.gmane.org; Thu, 06 Apr 2017 17:58:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33523) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cwFPm-0001Jy-T5 for emacs-devel@gnu.org; Thu, 06 Apr 2017 17:58:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cwFPi-0006Tk-5C for emacs-devel@gnu.org; Thu, 06 Apr 2017 17:58:02 -0400 Original-Received: from [195.159.176.226] (port=36019 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cwFPh-0006Rm-Vn for emacs-devel@gnu.org; Thu, 06 Apr 2017 17:57:58 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cwFPP-0002rM-Qm for emacs-devel@gnu.org; Thu, 06 Apr 2017 23:57:39 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 37 Original-X-Complaints-To: usenet@blaine.gmane.org 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 Cancel-Lock: sha1:Kjbjsh5r/qbEkBnscziaBgXnr+Y= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:213724 Archived-At: On Thu, 06 Apr 2017 16:12:22 -0400 Stefan Monnier wrote: >> a) Can the parse tree of a package be analyzed safely (without running >> code in the package)? Is it deterministic? SM> Yes, currently the reader is pretty much unaffected by Elisp code. On Thu, 6 Apr 2017 16:17:17 -0400 Clément Pit-Claudel wrote: CP> Yes if you mean the parse tree, but no if you mean the expanded syntax tree: you CP> need to run macros to see the full AST, and macros can run arbitrary code. You CP> could apply a first analysis pass to the macros, decide that they are safe, CP> expand, and run the analysis again; but see (b) I think it's OK to leave macros unexpanded and only show to the auditor a diff that highlights the unsafe things. In other words, call `unsafep' or something like it on the new parts of the parse tree, and mark the unsafe pieces for review. The auditor can decide if the macros can be trusted, together with any other potentially unsafe code. In that case we need to make a canonical representation (parse tree) of a package's code before macros are expanded. That can be the mechanical part of the code audit (together with the signing process, which is an easier problem). Can Emacs make (a) easy with a package or with C code? The package metadata is probably the right place to define what constitutes a package's parse tree, and then that subportion of the metadata will have to signed together with the parse tree. I don't know if "parse tree" is the right term, either. I think one benefit of signing the parse tree is that packages can then be copied between various VCS systems and ELPA repositories as long as the code remains the same. IOW you don't have to trust the ELPA repository or the VCS system, you only trust the auditor(s) that signed the parse tree of the actual package you're about to install. Ted