Re: Replacing polkit JS backend

2018-01-03 19:47 GMT+01:00 Simon McVittie : > On Wed, 03 Jan 2018 at 17:07:03 +0100, Miloslav Trmac wrote: > > See one of the other mails, I’m worried that with the vaguely > systemd-like ”no > > programming language, but a few ‘simple’ special-cased condition > operators” > > systems never stay s

Re: Replacing polkit JS backend

On Wed, 03 Jan 2018 at 17:07:03 +0100, Miloslav Trmac wrote: > See one of the other mails, I’m worried that with the vaguely systemd-like ”no > programming language, but a few ‘simple’ special-cased condition operators” > systems never stay simple. This is a valid concern. > more and more Conditi

Re: Replacing polkit JS backend

Hello, 2017-10-21 20:54 GMT+02:00 Ikey Doherty : > On 21/10/17 19:39, Michael Biebl wrote: > So to use the libvirt example: > > polkit.addRule(function(action, subject) { > if (action.id == "org.libvirt.api.connect.getattr" && > subject.user == "berrange") { > if (action.look

Re: Replacing polkit JS backend

Hello, 2017-12-18 12:10 GMT+01:00 Ikey Doherty : > > Though it'd be great to have Miloslav weigh in on some of this too; > particularly > > things like @smcv's suggestion of a pkla translator as @mtrmac also > maintains > > . > > > > So @mtrmac is the best on

Re: Replacing polkit JS backend

Hello, 2017-12-18 11:05 GMT+01:00 Colin Walters : > Based on some (long ago now) in-person discussion with the previous polkit > maintainer: > the JS backend was added for a reason from a real-world nontrivial in size > desktop deployment. > That said I don't have contact with them myself and unfo

Re: Replacing polkit JS backend

On Mon, 2017-12-18 at 11:10 +, Ikey Doherty wrote: > > Anyways, are you interested in being more active in upstream > > polkit? There > > are some outstanding patches to review; > > https://bugs.freedesktop.org/show_bug.cgi?id=99741 > > for example. From my perspective I'm fine adding you to

Re: Replacing polkit JS backend

Hey On 18/12/17 10:05, Colin Walters wrote: > Based on some (long ago now) in-person discussion with the previous polkit > maintainer: > the JS backend was added for a reason from a real-world nontrivial in size > desktop deployment. > That said I don't have contact with them myself and unfortun

Re: Replacing polkit JS backend

Based on some (long ago now) in-person discussion with the previous polkit maintainer: the JS backend was added for a reason from a real-world nontrivial in size desktop deployment. That said I don't have contact with them myself and unfortunately the original commit aeb2b50a7b0ed1411df81790231c

Re: Replacing polkit JS backend

2017-12-16 15:26 GMT+01:00 Ikey Doherty : > Apologies, been epically busy here over at Solus. > I've not done the PKLA parser and test suite yet, > I can spend time on that this weekend if you wish. No pressure. Was just interested in the current state/progress. -- Why is it that all of the inst

Re: Replacing polkit JS backend

Apologies, been epically busy here over at Solus. I've not done the PKLA parser and test suite yet, I can spend time on that this weekend if you wish. - ikey On 15/12/17 22:23, Michael Biebl wrote: > Hi Ikey, > > I'd be very interested to hear updates on your efforts. > Has there been progress o

Re: Replacing polkit JS backend

Hi Ikey, I'd be very interested to hear updates on your efforts. Has there been progress or did you run into issues? Regards, Michael 2017-10-20 17:10 GMT+02:00 Ikey Doherty : > Hi, > > I'm Ikey Doherty, leader of the Solus project [1]. > Yep, I know, yet another thread about replacing mozjs in

Re: Replacing polkit JS backend

On Sat, Oct 21, 2017 at 10:55:04AM -0700, Jasper St. Pierre wrote: > The last time this came up (when I tried to replace mozjs with Duktape), it > was pointed out that libvirt uses JS rules [0], and there's some evidence > that administrators are doing it as well. [1] > > [0] https://libvirt.org/a

Re: Replacing polkit JS backend

Hi Jasper 2017-10-21 21:06 GMT+02:00 Jasper St. Pierre : > > I notice that Debian actually patches this to add an additional rule to the > JavaScript -- is Debian shipping JS-based rules or not? We ship the JS based policykit-1 in experimental [1] but it was never part of a stable release. Some p

Re: Replacing polkit JS backend

On 21/10/17 20:06, Jasper St. Pierre wrote: > One more example for you, from gnome-initial-setup [0]. To give context > on this scenario, gnome-initial-setup is acting as if it was the > administrator in a restricted environment, guiding you through setting > up your system, so it asserts authori

Re: Replacing polkit JS backend

One more example for you, from gnome-initial-setup [0]. To give context on this scenario, gnome-initial-setup is acting as if it was the administrator in a restricted environment, guiding you through setting up your system, so it asserts authorization over its own actions. A fairly flexible whiteli

Re: Replacing polkit JS backend

Reply is down thar -> On 21/10/17 19:39, Michael Biebl wrote: > Hi! > > > 2017-10-21 19:28 GMT+02:00 Matthew Miller : >> On Sat, Oct 21, 2017 at 03:40:40AM +0100, Ikey Doherty wrote: >>> I've opted to make it an **alternative** backend to ease migration, >>> thus: >>> >>> --with-backend=js|keyf

Re: Replacing polkit JS backend

Hi! 2017-10-21 19:28 GMT+02:00 Matthew Miller : > On Sat, Oct 21, 2017 at 03:40:40AM +0100, Ikey Doherty wrote: >> I've opted to make it an **alternative** backend to ease migration, >> thus: >> >> --with-backend=js|keyfile > > Nice. I'm personally super in favor of it. Not speaking for Red Hat

Re: Replacing polkit JS backend

So for libvirt *itself* its easy to do the rules [1] but if push comes to shove I'm happy to help port the upstream projects if they're reliant on dynamic rule generation. As for the verbs part of the equation I do intend to have a part of the format allowing this, something along the lines of: E

Re: Replacing polkit JS backend

The last time this came up (when I tried to replace mozjs with Duktape), it was pointed out that libvirt uses JS rules [0], and there's some evidence that administrators are doing it as well. [1] [0] https://libvirt.org/aclpolkit.html [1] https://github.com/systemd/systemd/pull/1159 On Sat, Oct 2

Re: Replacing polkit JS backend

On Sat, Oct 21, 2017 at 03:40:40AM +0100, Ikey Doherty wrote: > I've opted to make it an **alternative** backend to ease migration, > thus: > > --with-backend=js|keyfile Nice. I'm personally super in favor of it. Not speaking for Red Hat officially, by any means. From a pure Fedora point of view

Re: Replacing polkit JS backend

OK I've got some initial rough patchwork hovering on GitHub: https://github.com/ikeydoherty/polkit-no-script/tree/noscript-3 https://github.com/ikeydoherty/polkit-no-script/commit/5bcb1c1f9f678d950c44eccba81db36fddb09efc I've opted to make it an **alternative** backend to ease migration, thus:

Re: Replacing polkit JS backend

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 pe

Re: Replacing polkit JS backend

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

Re: Replacing polkit JS backend

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 supp

Re: Replacing polkit JS backend

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 +

Re: Replacing polkit JS backend

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

Re: Replacing polkit JS backend

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 pro

Replacing polkit JS backend

Hi, I'm Ikey Doherty, leader of the Solus project [1]. Yep, I know, yet another thread about replacing mozjs in polkit! Anyway, we've opted to tear out the existing JS backend entirely in Solus [2] - but we're not putting any JS providers back in. Instead we're going with a simpler, statically de