Replying ->
On 20/10/17 17:20, Simon McVittie wrote:
> 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.
I'm happy to do that, in theory we could just build up a set of
directories and check for the two suffixes, including the .pkla.
If we find a .pkla, populate the rule file with a different parser,
but still have the same rule evaluation methods.
The struct could easily support it, as it has fields like:
gchar **unix_groups;
gsize n_unix_groups;
PolkitResponse response;
PolkitResponse response_inverse;
unsigned int constraints;
- ikey
>
> smcv
> _______________________________________________
> polkit-devel mailing list
> polkit-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/polkit-devel
>
_______________________________________________
polkit-devel mailing list
polkit-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/polkit-devel
