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@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
_______________________________________________
polkit-devel mailing list
polkit-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/polkit-devel
