Bug#783274: iceweasel: stop tracking ESR in testing/unstable and make an iceweasel-esr package instead
On Sat, 2015-04-25 at 11:54 +0200, Sylvestre Ledru wrote: > > Even when they're still supported by upstream, they simply receive far less > > scrutiny (in terms of security audits/analysis) than the current versions. > > Also often security holes are silently fixed, without being identified as > > such. > > > As Firefox release manager, I can tell you that this statement is incorrect. > For every security bug, if the information is not present, the question > "is ESR31 impacted?". Sure, I but I didn't talk about this at all. I referred to code that is changed/removed which may contain bugs that contains perhaps security issues, which are never identified as such, maybe not even as "normal" bug. > And if you saw any security holes being silently fixed, this was not on > purpose and it was a mistake. No I haven't seen any particular cases, but this has happened to all different kinds of software, libc (GHOST), the kernel and so on. I don't think that Mozilla can make extensive security audits of every line of code that is about to be changed/removed, so it's IMHO naive to believe that FF would be safe from this situation, whereas mostly all other software is not Best wishes, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#783274: iceweasel: stop tracking ESR in testing/unstable and make an iceweasel-esr package instead
Le 25/04/2015 01:03, Christoph Anton Mitterer a écrit : > Source: iceweasel > Severity: wishlist [...] > Even when they're still supported by upstream, they simply receive far less > scrutiny (in terms of security audits/analysis) than the current versions. > Also often security holes are silently fixed, without being identified as > such. > As Firefox release manager, I can tell you that this statement is incorrect. For every security bug, if the information is not present, the question "is ESR31 impacted?". All security bugs impacting ESR are fixed just like the release. We do security releases for ESR in case of 0 day or coordinated changes (like disabling ssl v3). And if you saw any security holes being silently fixed, this was not on purpose and it was a mistake. See the full list: https://www.mozilla.org/en-US/security/known-vulnerabilities/firefox-esr/ Cheers, Sylvestre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#783274: iceweasel: stop tracking ESR in testing/unstable and make an iceweasel-esr package instead
Source: iceweasel Severity: wishlist Hi. For quite some time now, the Debian iceweasel package tracks the ESR version in testing/unstable and the current version of FF is only available in experimental or through "unoffical" repos. I think many people run their desktop and or production servers on testing or even unstable, but still, in order not having to use a completely outdated FF one needs to use experimental, which is kinda annoying. Sure, pulling it in from experimental is quite easy via apt_preferences, but in experimental there is no security support (unlike testing). I guess the main reason of tracking ESR is probably to have a "long-term- supported" version in stable, but - wearing the security expert hat - assuming that such versions are really still secure after perhaps more than 1 or 2 years is probably an illusion. Even when they're still supported by upstream, they simply receive far less scrutiny (in terms of security audits/analysis) than the current versions. Also often security holes are silently fixed, without being identified as such. Long story short, I think it's at least somewhat questionable whether something such dynamic as a browser can be really long-term-supported. Anyway,... may I wish the following: Let the iceweasel package track current versions of FF and add e.g. an iceweasel-esr package, which tracks the ESR version. Since you anyway provide the current versions really fast in experimental, it shouldn't be too difficult to do the same for at least unstable. Such package could either never enter testing, or (based on my security analysis above) one could simply declare it unsupported in testing/stable after some short time, and request people to use a versions from backports. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
