Re: package security auditing and isolation

[Stefan Monnier <monnier@iro.umontreal.ca>]

> We have to operate openly, because it's the only practical choice other
> than forming a cabal or ignoring the problem.

Agreed.

> Heuristics are not what I had in mind.

You mentioned "finding the function calls that can be dangerous", which
to me sounds like the usual flawed approach of "anti-virus" looking for the
known exploits.

> a) Can the parse tree of a package be analyzed safely (without running
> code in the package)? Is it deterministic?

Yes, currently the reader is pretty much unaffected by Elisp code.

> b) If the parse tree of a package is analyzed, and only has whitelisted
> functions such as `string-equal' in it, does that make the package safe?

We have unsafep.el which tries to use such a white-list approach.
I doubt it's really bulletproof, but in any case I don't think you could
write a useful Elisp package with that subset.
[ IIRC it was introduced as part of ses.el to check safety of formulas
  in SES spreadsheets, so full-generality was not a goal.  ]

> c) Can the parse tree of a package be compared deterministically at two
> separate VCS checkpoints to find what's changed?

Yes, of course.

> d) Can the changes to the parse tree between two VCS checkpoints be
> signed by a reviewer?

Technically, yes, of course.


        Stefan