On 8/22/12 1:00 PM, Ben Hearsum wrote:
On 08/22/12 12:43 PM, Jeff Hammel wrote:
If we do go with python, it would be nice to keep the configuration
files as much configuration as possible. The reason I question having
any "full" language as a configuration language is that in practice I
see a lot of logic creep in to "configuration" files and then they
become very difficult for a consumer to parse/use as configuration.
While a bit of an unfair example, our buildbot-configs fall into this
category.
A million times this. Putting our configs in Python has let to terrible,
terrible hacks - to the point where we don't even know how to do things
like "turn off leopard tests for some branches" anymore
(https://bugzilla.mozilla.org/show_bug.cgi?id=773120). I strongly
discourage using Python when you don't need a fully featured language.
You will do bad things. You will regret it.
There are a lot of bullets in "batteries included" languages. The Python
foot gun worries me greatly. We even have this problem in make, and that
is a much simpler language!
Let's think of what can be done to secure/limit Python. Disabling import
has already been mentioned. That's a start.
What about the ast module [1]? I /think/ it could be used to ensure
parsed code conforms to whatever we allow. e.g. no import statements, no
function definitions, no classes, etc. Actually, it may be better to
think of it in terms of what would be allowed. Only declaring variables
that are strings, lists, or dicts. Only calling pre-defined functions
"exported" by the build system, etc. We start with the minimum and open
it up as we need to.
Is there anyone out there with experience with this module? What's
performance like for walking the AST? Is this something we could do at
manifest read/eval time without incurring too much of a penalty? (If
not, there's always automated auditing, which could even be part of the
test suite so trees would go red if someone checked in something in
violation.) Are there any caveats to the low-level nature of this
module? i.e. is there a burden to supporting ast functionality on
multiple versions of Python (we'll eventually need to handle the 2.7 ->
3.x transition).
For those who don't know Lua, the main reason I said it was perfect in
the original post is it does all of this automatically! It's designed to
be embeddable. A newly-created Lua context/interpreter can do very
little. You need to explicitly load the standard library from the C API!
A new context doesn't even have a string module nor the ability to load
modules: These must be selectively enabled through the C API by the
process creating the context instance! It's still a full programming
language. But, it's so constricted without any external modules or
module loading support that you almost don't have to worry. It is a more
natural fit for the task at hand. But, given Mozilla's requirements
(extra build dependency, maintaining the Lua bridge code - I know the
Lua C API, does anyone else?), I think shoehorning Python would be
preferred over Lua.
[1] http://docs.python.org/library/ast.html
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
