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