Replacing polkit JS backend

[Jeremy Linton]

Hi,

As a short term solution, there are patches to move to to mozjs38.

https://www.mail-archive.com/polkit-devel@lists.freedesktop.org/msg00499.html

I've recently been encouraged to do the port to mozjs52 as well, 
although my personal opinion is that javascript is way overkill for what 
polkit needs.



On 10/20/2017 10:57 AM, Ikey Doherty wrote:
> 
> 
> On 20/10/17 16:49, Simon McVittie wrote:
>> On Fri, 20 Oct 2017 at 16:10:24 +0100, Ikey Doherty wrote:
>>> Our intention is that when this work is complete and tested in Solus,
>>> we'll want to upstream this.
>>
>> (For avoidance of doubt, I do not consider myself to be a polkit
>> maintainer and am not in a position to accept or reject your design
>> proposal. I personally think it looks like it has potential, and will
>> be interested to see what happens.)
>>
>> I think the point at which you're ready to ship this to your users seems
>> considerably too late to upstream it: if the polkit maintainers are
>> interested in this design change in principle, but review raises design
>> issues in the "API" that cannot be resolved in a compatible way, then
>> you'll be stuck with a difficult decision between breaking compatibility
>> for your users, or being forever incompatible with upstream polkit
>> (maintaining a fork whether you wanted to be or not).
> 
> We manage all the polkit files in Solus already, so if changes are
> required we'll adapt them. We're rolling release so its trivial to
> do this.
> 
>>
>> I would suggest proposing the app- and user-facing "APIs" for review as
>> soon as you consider them to be reasonably well-thought-out, even if
>> the detailed implementation is only reviewed when finished.
> 
> Of course - 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.
> 
>>
>> Of course, it is possible that the reaction will be "you touched it last,
>> you maintain it now" :-)
> 
> That's a risk I understand, but that's fine too. I could always follow
> up with the oblig. convert to meson patches, given that its glib. :P
> 
>>
>> How do these keyfile-based policies compare with the old (polkit 0.105)
>> keyfile-based policies, which e.g. Debian and Ubuntu are still shipping?
> 
> Similar to the pkla but uses explicit fields to be expressive, i.e.:
> 
> InUnixGroups=
> InUserNames=
> 
> vs pkla:
> 
> AdminIdentities=unix-user:bob
> 
> It's simpler to parse, and does away with the JSisms. It also allows to
> do magic like:
> 
> [livecd.rules]
> Action=*
> InUserNames=live
> InUnixGroups=%wheel%
> Active=true
> Result=yes
> 
> or:
> 
> [blacklist.rules]
> ActionContains=.udisks.
> InUnixGroups=guest
> Result=no
> 
>>
>> Regards,
>>      smcv
>> _______________________________________________
>> polkit-devel mailing list
>> polkit-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/polkit-devel
>>
> _______________________________________________
> polkit-devel mailing list
> polkit-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/polkit-devel
>