On Sat, Jan 17, 2009 at 05:30:54PM +0100, Sylvain Beucler wrote: > On Sat, Jan 17, 2009 at 04:06:30PM +0100, Mike Hommey wrote: > > On Sat, Jan 17, 2009 at 02:19:02PM +0100, Sylvain Beucler wrote: > > > Package: iceweasel > > > Version: 3.0.5-1 > > > Severity: grave > > > Tags: security > > > Justification: user security hole > > > > > > > > > Since Debian stable is a "frozen" distro, it's not uncommon to install > > > the official Firefox binaries when the next version of Firefox is > > > released, and isn't packaged in stable or backported yet. I've also > > > also seen that useful to fix browser detection (hotmail) or support > > > binary extensions (probably to avoid stdlibc++ 5/6 discrepancies). > > > > > > Anyway, when Iceweasel is started, it silently disables the security > > > update checks in the configuration. > > > "about:config" reports that 'app.update.enabled' is set to false. This > > > is set on startup. > > > > > > This is a problem, because as I mentioned people may use, concurrently > > > or later, an official version of Firefox. In this case, Firefox will > > > disable security update checks as directed, and thus Firefox won't be > > > upgraded when there's a security fix. People may work several months > > > without being notified about a security hole in their Firefox. > > > > > > The fact Iceweasel disables upsteam security update checks is normal, > > > because Debian (not upstream) provides those. However it's a mistake > > > to disable that in the configuration, because this impacts other > > > versions of Firefox that do use those checks. > > > > > > So please don't alter 'app.update.enabled' and other settings, and > > > disable Iceweasel upstream security updates checks using another > > > method (e.g. by not compiling the related code, or by not using > > > ~/.mozilla/firefox to store the iceweasel configuration). > > > > Are you sure that when running firefox again, the config value doesn't > > go back to true ? Because these are global configurations that are not > > stored in user profile unless you modify them... So while running > > iceweasel would disable app.update.enabled, running firefox should > > re-enable it. Try resetting the config item (right-click -> reset, iirc) > > and try switching between iceweasel and firefox. > > > Here're a few tests: > > - open Firefox > - witness app.update.enable == false (bold, state="Defined by user") > - double click app.update.enable to switch it to true (normal, > state="by default") > - close Firefox > > - open Iceweasel > - witness app.update.enable == false (italic, status=locked) > - double click doesn't change a thing > - close Iceweasel > > - open Firefox > - witness app.update.enable is back to false (bold, state="Defined by > user") > - set app.update.enable to true again > - close Firefox > > - open Firefox > - witness app.update.enable == true (normal, state="by default") - > it doesn't revert to false by default, so it's well a Iceweasel > behavior > - close Firefox > > - open Iceweasel > - close Iceweasel without messing with the config > - open Firefox > - witness app.update.enable is false (bold, state="Defined by user") - > so it's a startup Iceweasel behavior, nothing manual involved > > > Thus I'm pretty sure the config value doesn't get back to true. > > If this is a global configuration, then possibly non-default global > configuration gets merged with the user configuration?
Hi, Any news about this? Also: I suggest setting it back to severity=grave. Mistakingly disabling 3rd-party software updates is harming security. I just noticed that Moritz had downgraded the severity without explaining why. -- Sylvain -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
