661026 - make mozprofile slightly less horrible by evaluating prefs in a sandbox

Status: RESOLVED DUPLICATE of bug 668249

(Testing :: Mozbase, defect)

Description

[Jeff Hammel]

Attachment: naive implementation of prefs reading

Currently, mozprofile uses magic markers to read/write prefs.  While this is sufficient for a certain use-case, it does not let you read preferences from the profile.  If we wanted to do this, we could eval in a python-side sandbox taking advantage of the fact that JS and python are (for purposes of prefs.js) near in syntax.  This will still only cover maybe 95% of use-cases, but maybe that's better than 0%?

Comment 1

[Heather Arthur [:harth]]

It seems like it would be better to regex it? What's wrong with regexing it?

Comment 2

[Jeff Hammel]

Why would it be better to use regexes?  I don't really care how its done if I never have to maintain it or write it.  Since effectively you are writing a lexer/parser, regexes by themselves seem like a wrong choice.  Instead, I take advantage of the fact that except comments, and things like true->True, and semicolons, for (reasonable) prefs.js files, the syntax is the same as python so eval() + pre-tidying replaces the need for a parser.  Considering regexes:

user_pref('foo', "I said\"this\" yesterday\\\\");

Again, I would much prefer to debug the code I have versus using regexes.  I'm not sure why regexes are better here.  Though again, I mostly just want something to read prefs with and get an appropriately typed python dict back.   If I don't have to maintain it, then an arbitrarily complicated regex is fine ;)

I'd like to have this for testing bug 636035.  Other than testing there is no immediate use (although I would like to replace the crazy code in mozprofile with something better and more robust).  Plus, in general, something like this is useful from arbitrary python progs.

So is that an f-?

Comment 3

[Jeff Hammel]

I was using this implementation as part of the mutt tests.  https://bug668249.bugzilla.mozilla.org/attachment.cgi?id=543492 moves it into the mozprofile.preferences module, so if that sticks we can close, implementation details aside

Comment 4

[Jeff Hammel]

So evidently I did this in bug 668249 : see https://github.com/mozilla/mozbase/blame/master/mozprofile/mozprofile/prefs.py . There are things that can be improved here: especially for bad input cases, we don't catch them.

Long story short, I'd like to use http://mxr.mozilla.org/mozilla-central/source/python/mozbuild/mozbuild/frontend/sandbox.py as a more rigorous sandbox, but first it'd have to be its own package that mozprofile depended on