javascript and the future of polkit?

[Miloslav Trmač]

Hello,
> I noticed that polkit at least builds with mozjs-185 or mozjs-17.
> 
> However, it seems like the future of mozjs is a C++-only API; a C API will no
> longer be provided.
> 
> Given that, what is the plan moving forward for polkit?
> 
> Would a patch converting polkit to use mozjs-24 be welcomed even though it
> means a C++ dependency?
> 
> Or is there a plan to migrate to some other JavaScript engine such as
> http://duktape.org/?
> 
> Or should polkit just grow a dependency on gjs which gives it back a C API?

I don’t see a C++ dependency (limited to *jsauthority.*) as an issue.  I am most concerned about, in this order:

1. Security: The JS engine should be designed to withstand malicious input (malicious programs are not so much of a concern), and be have a high likelihood of being maintained by someone motivated to care about this kind of security.
2. Functionality and compatibility: Formally we document supporting ECMA-262 edition 5; hot breaking existing scripts would also be desirable.
3. Well-defined and documented API (not like SpiderMonkey deleting the only wiki pages which at least partially document mozjs-17 behavior)
4. Stable API / low maintenance effort: Not having to patch *jsauthority.c all the time to take advantage of security fixes in the JS engine.
5. Stable ABI: Not having to recompile/update polkit for a JS engine update.
6. Performance: Should not suck too much ☺

AFAICS 1. pretty much binds us to using a JS engine from one of the major browsers/platforms, and their focus on performance makes [345] something we are unlikely to get.

I don’t know that much about gjs; from a quick look I can’t see that it wraps the SpiderMonkey rooting API, so native SpiderMonkey calls would still be needed in polkit; and its dependency on GTK is rather awkward.

So I think (Colin?) a patch updating polkit to mozjs-24 (or -31?) would be very welcome.
    Mirek