On Thu, Jan 16, 2014 at 1:52 PM, Moritz Mühlenhoff <j...@inutil.org> wrote: > On Sun, Jan 05, 2014 at 02:47:39AM -0800, Vincent Cheng wrote: >> Hi, >> >> > Package: mozjs17 >> > Severity: serious >> > >> > This package forks a local copy of the Iceweasel Javascript engine which is >> > no longer supported with security updates (currently only the ESR24 series >> > is maintained) >> >> Out of curiosity, why is this a RC bug when there seems to be no >> issues from the security team with regards to src:mozjs (which is even >> older, based on Firefox 4 code AFAIU, and is currently in stable)? > > I hadn't notice it so far. That is even worse since it even up in a stable > release! > > Will file a bug soon, thanks for point this out. > >> > Why do we need a copy of the old version anyway? What are the expected >> > applications >> > using it and why can't they be migrated to the mozjs provided by the >> > iceweasel >> source package. >> >> The following packages are currently depending against libmozjs185-1.0: >> 0ad >> cinnamon >> couchdb >> dehydra >> gnome-shell >> libgjs0b >> libgjs0c >> libmozjs185-dev >> libpeas-1.0-0 >> mediatomb-common >> oolite >> policykit-1 >> >> (taken from mozjs17's ITP bug report, #709434) >> >> GNOME Shell stands out in that list above as a major package that >> depends on mozjs/Spidermonkey. I myself am maintainer for 0ad, hence >> why I'm interested in this bug report as well. >> >> My understanding is that Spidermonkey, as a standalone release >> (snapshot?) of FF's javascript engine, is meant to be embedded in >> applications that use it. I can't answer for all the packages above, >> but I know that 0ad requires a very specific version of Spidermonkey, >> and that transitioning between different releases seems to be rather >> painful for upstream. >> >> I guess one possible way to deal with this is to dump mozjs and >> mozjs17 (and future Spidermonkey releases) in the same category as >> webkit, i.e. unsupported by the security team? > > We can do that, but only as a matter of last resort. For practical > purposes this will leave an endless amount of spidermonkey copies around.
What other alternatives does the security team consider viable? My understanding is that spidermonkey has the same duration of support as the ESR release it was based on, so that's ~1 year. But unlike FF/Chromium, which we can continue pulling in new upstream releases to maintain security support during the lifecycle of a release, I'm not sure if that's doable with spidermonkey given all of the reverse dependencies that it has. And it would likely be an unsustainable burden on the security team and/or individual maintainers to backport changes to their packages in stable to make them work with newer spidermonkey releases, each time a new ESR release comes out and uploaded to stable. If no (standalone) spidermonkey copies were allowed into the archive, I suppose individual packages that depend on it would have to use an embedded copy instead...that's not ideal either. > I can see the point for 0ad, but there needs to be some effort by > apps to migrate to a proper supported version. 0ad upstream is already working (and making good progress) on migrating to ESR 24, and should be done in time for their next release. I can't speak on behalf of all the other packages that depend on spidermonkey currently though. Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
