libproxy crashes gjs applications when run outside GNOME with mozjs backend enabled, probably also crashes WebKit-based applications if WebKit backend is enabled

[mcatanzaro]

See https://bugzilla.redhat.com/show_bug.cgi?id=1524507. User reports that GNOME Weather crashes on startup if libproxy-mozjs is installed. libproxy gets dlopened by glib-networking when running outside GNOME, then libproxy dlopens mozjs38, and meanwhile gjs of course links to mozjs52. That makes applications explode.

I think the only reason this is not reported more often is that people don't often run gjs applications outside GNOME (in which case GProxyResolverGnome is used instead of GLibproxyResolver, so libproxy is not dlopened at all).

DimStar's dbusify branch would avoid this problem.

[mcatanzaro]

@DimStar77 any thoughts on this?

It seems clear that we need to get mozjs out-of-process somehow. I thought using D-Bus was as good a solution as any....

[mcatanzaro]

Apparently I have a long chain of comments on this in #68 (comment) from two years ago, but there's no real conclusion there on what to do.

[mcatanzaro]

Oh here's another thing we could do: we could invert the logic libmodman uses to attempt to use the pacrunner backend matching a JS library that the application is already using. libmodman is basically self-sabotage here. :D It would be better to use mozjs backend if and only if the application is NOT linked to mozjs, or use WebKit only if the application is NOT linked to WebKit, but libproxy is doing the exact opposite in pursuit of the misguided goal of reducing the number of JS engines loaded in-process.

[mcatanzaro]

Apparently I have a long chain of comments on this in #68 (comment) from two years ago, but there's no real conclusion there on what to do.

I've been thinking about this, and I'm leaning towards: never use libproxy in-process. Instead of linking directly to libproxy, I could change GLibproxyResolver to instead call some helper binary that would run libproxy, similar to how glib-pacrunner executes in a subprocess.

[Vogtinator]

AFAICT, that makes using libproxy substantially harder and more complex and won't help with existing users.
IMO it's libproxy's job to make it as easy as possible to just get the proxy for a URL, so it should do whatever is needed to perform that task. So if it's necessary to call some helper binary, libproxy should take care of that internally as an implementation detail.

It might be possible to convert libproxy.so into that helper binary and then create a new libproxy.so which then calls that binary.

[mcatanzaro]

It might be possible to convert libproxy.so into that helper binary and then create a new libproxy.so which then calls that binary.

Yeah, to solve this we need a process boundary between the process using libproxy and the JS engine evaluating the pacrunner. That's the only way it can really be solved. Only details to figure out are "what would it look like?"

[Vogtinator]

It might be possible to convert libproxy.so into that helper binary and then create a new libproxy.so which then calls that binary.

Yeah, to solve this we need a process boundary between the process using libproxy and the JS engine evaluating the pacrunner. That's the only way it can really be solved. Only details to figure out are "what would it look like?"

The libproxy API is practically just one single function: px_proxy_factory_get_proxies. So just using something like the proxy example to get those results might be enough. Or to get fancy, start a process on demand and stop it again on px_proxy_factory_free or when not used for some time.

[DimStar77]

Reviving https://github.com/libproxy/libproxy/tree/dbusify will be the way to go imho

[mcatanzaro]

This is now mitigated by #139. But ultimately the mozjs backend needs to either use IPC (dbusify) or go away.

Of course, while gjs apps should be good now, we probably transferred the problem to apps that use WebKit. I would be pretty unsurprised if it crashes for apps that use QtWebKit, for example. It's probably also a disaster for apps that use GTK 4 (since libproxy links to the GTK 3 version of WebKitGTK).

[mcatanzaro]

Since distributions now need multiple versions of WebKitGTK (and since QtWebKit is a thing that exists), that backend is no longer safe either. If there's no hope of #157 landing anytime soon, I think these backends should both be removed. duktape seems like the better option.

[janbrummer]

Closing as obsolete, we only support duktape.