Re: package security auditing and isolation

[Ted Zlatanov <tzz@lifelogs.com>]

On Thu, 06 Apr 2017 16:12:22 -0400 Stefan Monnier <monnier@iro.umontreal.ca> 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 <cpitclaudel@gmail.com> 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