Bug#733496: Code copy of older Mozilla code
On Sat, Dec 6, 2014 at 4:57 AM, Moritz Mühlenhoff j...@inutil.org wrote: severity serious thanks 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) What's the strategy here? Do you plan to backport/triage all Javascript related security issues from current Mozilla releases to your version? 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. There are no reverse dependencies left for mozjs17, so we should remove it now: (mozjs and mozjs24 can be kept, but they aren't covered by security support) RM bug filed as #772442. Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733496: Code copy of older Mozilla code
severity 733496 wishlist tags 733496 wontfix thanks Hi Mike/Emilio, On Thu, Feb 27, 2014 at 12:06:23PM +0900, Mike Hommey wrote: On Wed, Feb 26, 2014 at 08:53:32PM +0100, Emilio Pozuelo Monfort wrote: Hi Moritz, Laurent spoke to Mike regarding this and Mike said he was thinking/planning on dropping libmozjs packages from src:iceweasel (please correct. The only possible alternative is to have a code copy as a separate source package (as we have done with mozjs and now with mozjs17). Note that depending on mozjs from iceweasel would have a big impact on stable when iceweasel is upgraded. Indeed. The js API and ABI are both highly unstable, so having it shipped by iceweasel ensures all rdependencies using it will suffer. The same can be said of xulrunner, and I'm seriously considering killing the package too (in fact, I'm also pushing to kill it upstream, providing the functionality itself off firefox). As of current packaging, libmozjs is gone from the iceweasel 29 package on mozilla.debian.net. I'm tempted to make it go away as soon as 28. I agree with no longer providing xulrunner-dev. The approach used to be right in the lenny days when we only need to fix src:xulrunner to address icewasel/icedove and iceape, but with the yearly rotation there's clearly too much churn for the reverse deps. As for libmozjs*: We can treat them as unsupported with security updates. Every application build-depending on libmozjs* can assess whether this poses a problem, but I think it's acceptable for most. couchdb edbrowse dehydra gxine 0ad libproxy mediatomb gjs oolite dehydra The only reverse dep which seems to be exposed to untrusted Javascript from web sites is apparently edbrowse, but this seems like an acceptable risk... Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733496: Code copy of older Mozilla code
On Thu, Feb 27, 2014 at 8:17 AM, Vincent Cheng vch...@debian.org wrote: On Wed, Feb 26, 2014 at 11:09 PM, Emilio Pozuelo Monfort po...@debian.org wrote: Have you seen #739132 ? Do you have any plans to upload mozjs 24? Given mozjs17 hasn't entered testing and has very few rdeps, maybe we could go directly for mozjs24 and work towards getting rid of mozjs17 and mozjs185 (to avoid having several mozjs in testing / stable). I thought Mike would take mozjs24, but it seems I was wrong. I have no plans to upload mozjs 24 (I'd rather not maintain it by myself), but if the iceweasel and/or gnome maintainers would like a helping hand or even a co-maintainer, I'd be glad to help. If none wants to maintain it in the first place, I may upload it on Sunday. I'll need it anyway. Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733496: Code copy of older Mozilla code
Hi Moritz, Laurent spoke to Mike regarding this and Mike said he was thinking/planning on dropping libmozjs packages from src:iceweasel (please correct. The only possible alternative is to have a code copy as a separate source package (as we have done with mozjs and now with mozjs17). Note that depending on mozjs from iceweasel would have a big impact on stable when iceweasel is upgraded. I don't think this is a big problem. At least for my use case (gjs gnome-shell and a few other gnome apps) the executed javascript code is the application code shipped in their packages, not some random webpages. So we're not exposed to malicious code. Regards, Emilio -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733496: Code copy of older Mozilla code
On Wed, Feb 26, 2014 at 08:53:32PM +0100, Emilio Pozuelo Monfort wrote: Hi Moritz, Laurent spoke to Mike regarding this and Mike said he was thinking/planning on dropping libmozjs packages from src:iceweasel (please correct. The only possible alternative is to have a code copy as a separate source package (as we have done with mozjs and now with mozjs17). Note that depending on mozjs from iceweasel would have a big impact on stable when iceweasel is upgraded. Indeed. The js API and ABI are both highly unstable, so having it shipped by iceweasel ensures all rdependencies using it will suffer. The same can be said of xulrunner, and I'm seriously considering killing the package too (in fact, I'm also pushing to kill it upstream, providing the functionality itself off firefox). As of current packaging, libmozjs is gone from the iceweasel 29 package on mozilla.debian.net. I'm tempted to make it go away as soon as 28. I don't think this is a big problem. At least for my use case (gjs gnome-shell and a few other gnome apps) the executed javascript code is the application code shipped in their packages, not some random webpages. So we're not exposed to malicious code. ... assuming no malicious code is on the gnome shell extensions web site... That being said, without exploiting the js engine, they probably can already do a lot of harm. Mike -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733496: Code copy of older Mozilla code
Hi Vincent, Vincent Cheng wrote: 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. Have you seen #739132 ? Do you have any plans to upload mozjs 24? Given mozjs17 hasn't entered testing and has very few rdeps, maybe we could go directly for mozjs24 and work towards getting rid of mozjs17 and mozjs185 (to avoid having several mozjs in testing / stable). Regards, Emilio -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733496: Code copy of older Mozilla code
Hi Emilio, On Wed, Feb 26, 2014 at 11:09 PM, Emilio Pozuelo Monfort po...@debian.org wrote: Hi Vincent, Vincent Cheng wrote: 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. Have you seen #739132 ? Do you have any plans to upload mozjs 24? Given mozjs17 hasn't entered testing and has very few rdeps, maybe we could go directly for mozjs24 and work towards getting rid of mozjs17 and mozjs185 (to avoid having several mozjs in testing / stable). I have no plans to upload mozjs 24 (I'd rather not maintain it by myself), but if the iceweasel and/or gnome maintainers would like a helping hand or even a co-maintainer, I'd be glad to help. Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733496: Code copy of older Mozilla code
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-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733496: Code copy of older Mozilla code
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. I can see the point for 0ad, but there needs to be some effort by apps to migrate to a proper supported version. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733496: Code copy of older Mozilla code
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)? 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? Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733496: Code copy of older Mozilla code
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) What's the strategy here? Do you plan to backport/triage all Javascript related security issues from current Mozilla releases to your version? 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. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
