Bug 1958111

I'll add just my two cents to one of the cons: 

- gjs and polkit build times get a lot slower and it's harder to iterate fixes there

If this change was to happen, I think it'd be best to have some sort switch in gjs/polkit to either use bundled mozjs or system mozjs. For some iterating over fixes that aren't affected by mozjs, one could switch mozjs to the system package (conditional BR and pulled from EPEL in such cases). That could reduce build times in some cases when a gjs/polkit issue/fix is unrelated to mozjs. It'd also allow to share polkit/gjs specfiles between Fedora and RHEL.

Ah, good idea! Thanks, František.

Hi Kalev,

being independent on the package in RHEL9 sounds interesting, especially after the trouble caused by rebase of Gnome Shell in RHEL7, however, do you have a specific plan in terms of maintaining the bundled library within the consumer packages? Aiming at the CVEs and other security issues...

Hi Jan,

I'm happy to help keep it up to date (as long as upstream is releasing new versions) and in sync with the copy that's bundled in gjs, basically just do the same minimum maintenance that it's getting now as a separate package.

I can't promise any CVE fixes after Firefox ESR 78 is EOL though, but it's the same issue when it's separate package. We just don't have resources to keep maintaining old, EOL mozjs versions. This whole bundling thing is to make it easier to get rid of the old versions in the future.

I think a good plan is to just keep polkit and gjs up to date with latest upstream releases. I'm sure both of them are going to eventually get ported to newer mozjs versions upstream and when that happens, I'm happy to help get new versions of bundled mozjs building and up to date, basically just copy what we do for gjs.

(Also, security issues in polkit's JS engine shouldn't be exploitable as polkitd only runs code that only admins can install to /usr/share/polkit-1/rules.d/, which makes the attack surface very small even if there's a flaw in the JS engine.)

Some random musings from the sidelines:

- Could polkit be ported to use gjs, instead of using mozjs directly?
- Alternatively, would smaller embedded js engines like ducttape be easier for this?

Either of these will certainly require some more resources in the short term, but would make the 'mozjs problem' disappear for polkit

I think this is a good long-term plan for gjs. Remember to add to the spec: Provides: bundled(mozjs) = 78.10.0.

For polkit, bundling mozjs seems OK as a short-term measure, but mozjs is really a terrible choice of JS engine due to lack of API and ABI stability. With gjs, this maintenance cost is primarily suffered and handled by upstream. But that doesn't seem to be going as well for polkit. Also, polkit's dependency on mozjs is much easier to eliminate than it would be for gjs.

(In reply to Matthias Clasen from comment #5)
> - Could polkit be ported to use gjs, instead of using mozjs directly?
> - Alternatively, would smaller embedded js engines like ducttape be easier
> for this?

duktape would seem to be much better. I imagine it probably has far fewer CVEs than mozjs. There is already a MR for this: https://gitlab.freedesktop.org/polkit/polkit/-/merge_requests/35. With duktape, we have to choose between bundling it vs. maintaining it as a system library. I guess we could do the former for RHEL and the later for Fedora. duktape seems to provide API but not ABI stability, which is fine for Fedora, but not good enough for RHEL. Also, it seems Fedora's system duktape is unmaintained and a couple years outdated, which is a negative. Finally, we probably don't want to maintain duktape in RHEL any more than we want to maintain mozjs, even though duktape would be easier.

mozjs is just the worst option possible. Even depending on JavaScriptCore (from WebKitGTK) would be better than that. (JavaScriptCore has a stable API/ABI, so keeping up with security updates is easy, and I handle it already.) duktape is probably best though. We just need to remember Provides: bundled(duktape) if we bundle it.

(In reply to František Zatloukal from comment #1)
> If this change was to happen, I think it'd be best to have some sort switch
> in gjs/polkit to either use bundled mozjs or system mozjs.

Well we have to do that anyway, because we want to share the spec with Fedora (so this change isn't lost for RHEL 10), but we don't want to bundle mozjs in Fedora.

(In reply to Kalev Lember from comment #0)
> It used to be that we needed to have mozjs as a shared library because gjs
> and libproxy both used mozjs symbols that ended up in the same process
> namespace. This meant that both had to be linked against the exact same
> libmozjs to avoid symbol clashes and weird crashes. However, libproxy is
> going away in RHEL 9 (and its mozjs backend is gone in Fedora) so this
> problem is no more.

One caveat: this plan is conditional on changing glib-pacrunner to do web proxy autodiscovery on its own, without libproxy. I'm planning to work on that, but it requires that I make glib-networking depend directly on a JS engine. I had been planning to use JavaScriptCore and split glib-pacrunner out into a subpackage to avoid a hard dependency, but I suppose duktape would work too, if the Fedora duktape package was in better shape. P.S. glib-pacrunner is already designed with a process boundary, so no extra effort is required to ensure the JS engine is used out-of-process and won't cause crashes for linked applications.

(In reply to Matthias Clasen from comment #5)
> Some random musings from the sidelines:
> 
> - Could polkit be ported to use gjs, instead of using mozjs directly?
> - Alternatively, would smaller embedded js engines like ducttape be easier
> for this?
> 
> Either of these will certainly require some more resources in the short
> term, but would make the 'mozjs problem' disappear for polkit

Polkit is also used on gnome-free DEs like KDE and Xfce. I don't use them so I don't know if having to install gjs wouldn't bring the entire gnome dependency list. I'd rather bundle the lib if I had to than this.

The work on transition from mozjs to duktape is stalled as the merge request mentioned in comment#6 doesn't meet requirements in terms of safety and code culture. The MR doesn't contain any implementation of runaway_killer and that would make polkit prone to infinite loops.

OK, I went ahead and merged the gjs changes to switch to bundled mozjs78 (gjs-1.68.1-2.el9, https://gitlab.com/redhat/centos-stream/rpms/gjs/-/commit/dfa7946b87c564737147ec7aebd8b7e7b1ba0c0b). I'll work on polkit next.

All tests from our test suite pass. No regression found.

OK, and here's the matching change for polkit to bundle mozjs: https://gitlab.com/redhat/centos-stream/rpms/polkit/-/merge_requests/2

Jan, are you OK with me merging this?

(In reply to Kalev Lember from comment #14)
> OK, and here's the matching change for polkit to bundle mozjs:
> https://gitlab.com/redhat/centos-stream/rpms/polkit/-/merge_requests/2
> 
> Jan, are you OK with me merging this?

Hello Kalev,

compiles, installs, works. I see no trouble.

Thanks, Jan! I went ahead and merged it and kicked off the build: polkit-0.117-6.el9

tpopela, I think you should be able to start the mozjs78 package removal process now if you want.

(In reply to Kalev Lember from comment #16)
> tpopela, I think you should be able to start the mozjs78 package removal
> process now if you want.

Thank you Kalev! I will remove it this week.