Replacing polkit JS backend

[Simon McVittie]

On Fri, 20 Oct 2017 at 16:57:55 +0100, Ikey Doherty wrote:
> however the fact remains right now of nuking the dead mozjs
> implementations actively from Solus, mozjs17 was dropped, now mozjs185
> is kicked out (super dead) and git only supports mozjs24, again, very
> dead. We're only allowing 38 + 52 to exist in Solus right now. Allowing
> the older implementations to exist is a gaping security issue that we're
> addressing, albeit with a large hammer.

I can understand the desire to hunt down old versions of mozjs (Debian
would like to do the same), but a JavaScript interpreter is not
*inherently* security-sensitive. A JS interpreter is only security-sensitive
when it interprets JS obtained from untrusted sources. Given how polkit
works, if your copy of polkit is interpreting untrusted JS, then you have
far worse problems than the age of its mozjs implementation :-)

(From what I've seen of the mozjs build system, there are other reasons
to want to run away from its older versions, though.)

In an attempt to keep track, here are the proposals I've seen for the
future of polkit:

* keep JS, repeatedly update to latest mozjs (probably not viable long-term)
* keep JS, switch intepreter to Duktape
* go back to .pkla
* your new keyfile backend

I wonder whether it would be feasible (for either upstream polkit
or a transitional patchset in interested distros) to load .pkla into
the same data structures as your new thing, effectively using it as
a deprecated alternative syntax? One of the reasons Debian is still
using .pkla (although not the only one AIUI) is that we don't have a
particularly great compatibility story for what happens to sysadmins'
locally-installed .pkla files.

    smcv