Remove end-of-life spidermonkey versions (78, 91, 102)

[mweinelt]

Both package have reached their end of life together with their respective firefox versions and should be removed before NixOS 22.05.

• spidermonkey_68: spidermonkey_68: drop #153451
• spidermonkey_78: EOL since 2021/11
  • required in polkit, but updated to mozjs-91 in https://gitlab.freedesktop.org/polkit/polkit/-/commit/a6bedfd09b7bba753de7a107dc471da0db801858
• spidermonkey_91: EOL since 2022/09
• spidermonkey_102: EOL since 2023/09

https://endoflife.date/firefox

@lostnet @abbradar @ajs124

[lostnet]

Here's the other packages that I've been monitoring:

• gjs: ok It looks like gnome 42 will release in march, probably soon enough to get an official release of gjs w/moz-91 https://gitlab.gnome.org/GNOME/gjs/-/merge_requests/632

• couchdb: ok has moz-91 support in mainline but has not cut a 3.x release. feat(couchjs): add support for SpiderMonkey 91esr apache/couchdb#3852

• cjs: has been made aware they will need another rebase to gjs-1.72 Rebase off 1.70.0-4 (ubuntu 22.04) linuxmint/cjs#101 (comment)

• libproxy: has duktape support in mainline but planned its next release to have moz-91 support. Add Duktape support libproxy/libproxy#161

[dasJ]

I'd like to remind the people here that branch-off is scheduled for tomorrow and depending on how good the staging builds progress, we will branch off rather soon.

[lostnet]

cjs seems to be the limiting factor. I think libproxy has not been correctly configuring spidermonkey so it could just be removed as a dependency and no functionality would change. 91.9.1 is actually the first version I've seen that unequivocally deals with a spidermonkey defect as the CVE, and unless that was a recent regression it therefore means clearly insecure EOL versions. It would make sense to isolate the usage of 78 to dependents that can be confirmed to require no sandboxing ( or other separation of privileges) and otherwise mark it insecure? I have no access to a normal computer this weekend though so I probably can't try anything ahead of the release.

…

On Sat, 21 May 2022, 19:07 Janne Heß, ***@***.***> wrote: I'd like to remind the people here that branch-off is scheduled for tomorrow and depending on how good the staging builds progress, we will branch off rather soon. — Reply to this email directly, view it on GitHub <#157874 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAK3LPM7SJT7JS5A5WYHDWTVLEJ37ANCNFSM5NMX6W5Q> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mweinelt]

Unrealistic to achieve and postponed to the 22.11 release cycle. Thanks for your research and documentation on the topic!

[lostnet]

libproxy could now be moved of 78 but cjs remains a problem as well as some other dependents.
So the refactor in #179822 still includes 78.

[ajs124]

libproxy could now be moved of 78

see #181917

[jtojnar]

Polkit done in #181264.

[ajs124]

I guess we can now remove spidermonkey_68 from the list, since that's gone, but need to add spidermonkey_91, used in couchdb and gjs, because support for that version of firefox has ended.

[jtojnar]

#182618 updates gjs

[mweinelt]

• couchdb: looks like they added support for spidermonkey_91 in 2022/04 https://blog.couchdb.org/2022/04/19/3-2-2/
• cjs: When will cjs be based on mozjs91? linuxmint/cjs#102
• 0ad: cc @chvp, please investigate if there is a possibility to usespidermonkey_102

[chvp]

It's not possible for 0ad unfortunately. The versions of spidermonkey have to match between clients, and we can't rely on other clients using the same version. AFAIK there are also no patches written yet for compatibility with 102.

[bobby285271]

Cinnamon 5.8 & CJS 5.8 bump (should use spidermonkey_102)

[mweinelt]

The 102 series will go EOL on 2023-08-29. The 115 series will be released in early July. https://whattrainisitnow.com/calendar/

[bobby285271]

The next GJS (>= 1.77.2, as part of GNOME 45) will depend on spidermonkey 115 (not packaged yet unfortunately)

[RaitoBezarius]

@chvp Please can you inline spidermonkey_78 inside 0ad? We will drop it officially but you can keep using it as the sole consumer of this package.

@puffnfresh Can you consider what it takes to move away from spidermonkey 102 in jsawk? Thanks!

@aforemny @jfrankenau Can you consider what it takes to move away from spidermonkey 102 in plowshare? Thanks!

I guess, we will have spidermonkey 102 for NixOS 23.11, but we can remove any public use of the previous versions IMHO by inlining 78 (0ad) & 91 (CouchDB 3.x) to their call site.

[mweinelt]

I'm not convinced inlining is a good solution to this problem. It's not like we are getting new consumers of EOL spidermonkey versions regularly.

[RaitoBezarius]

I'm not convinced inlining is a good solution to this problem. It's not like we are getting new consumers of EOL spidermonkey versions regularly.

It's not a permanent solution to the problem, it's a "let's erase them from the top-level" temporary solution.
For something like a game like 0ad, I'm not really sure we will see them disappear.

[ajs124]

@puffnfresh Can you consider what it takes to move away from spidermonkey 102 in jsawk? Thanks!

@aforemny @jfrankenau Can you consider what it takes to move away from spidermonkey 102 in plowshare? Thanks!

Both of these just call the js binary, which rarely ever changes. So just updating the package to a newer version and seeing if it still works as expected should be enough.

[mweinelt]

Spidermonkey is likely affected by GHSA-gv5g-5832-j3rm, GHSA-cm37-53wc-mx6g, so please evaluate whether your applications could be affected by that.

I'm inclined to mark versions older than 115 as known vulnerable at some point.

[chvp]

0ad should not be affected, no remote JS is loaded.

[bobby285271]

The patches are mozilla/gecko-dev@81806e7 and mozilla/gecko-dev@afbdf68 according to the bug ID I think.

It looks like MObjectKeysLength::computeRange is introduced in mozilla/gecko-dev@eec1c03 3 months ago, and mozilla/gecko-dev@afbdf68 does not touch the js folder 🤔

[bobby285271]

Cinnamon 6.2 and CJS 6.2 bump (should use spidermonkey_115)

[fpletz]

For something like a game like 0ad, I'm not really sure we will see them disappear.

The next version of 0ad will support a newer version of spidermonkey - unfortunately only 91 but then we can drop 78: 0ad/0ad@9513e7e

[mweinelt]

That is so very cool of them, now that 128 ESR is released. 🤦

[fpletz]

Next version of CouchDB will have support for QuickJS: apache/couchdb#4627

[bobby285271]

#333028 packages spidermonkey_128. and to test mozjs128 based GJS, gjs.passthru.tests should build on 7740a53.