Cheers!
On 20/10/17 17:29, Jeremy Linton wrote: > 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
