12 years ago
Comment on attachment 181355 [details] [diff] [review] untested patch r=dveditz
Does this need additional review or are we ready to land here? Does this have to make 1.8b2? If so, it needs to land ASAP.
Logistical issue: we can't ship a 1.0.4 and the 1.1 alpha at the same time, and the alpha will be shipped as soon as we get the beefed up fixes for the general class of bugs reported as mfsa2005-41 (bug 289074 et al, fixed on trunk as 281988). I just cc'd mikx on that one. soooo, if we check this fix in on the trunk a week or two before we can get 1.0.4 out will that expose this bug? It really just looks like a cleanup of the previous fix and could be checked in with comments to that effect. There's no obvious pointer to view-source (or jar: as in bug 291150). Or we ship a vulnerable alpha (to be called "Deer Park", not Firefox-something, to hopefully prevent massive adoption) and then when 1.0.4 goes out the alpha people learn about this. Most of them should be willing to grab the next nightly.
sure mikx owns this bug, but imho it is better to commit the patch to the trunk with non-intrusive comment so more testing for similar problems can be done. this also protects users running nightlies. i was involved in a similar situation with the linux kernel and a bunch of signedness problems - iirc the patches were publicly commited in the repository at least a week before the official release of the kernel and the sky didn't fell down. mikx: if you are concerned that someone disclose the bug because of the checkins, please have in mind this bugzilla entry shows when you have reported the bug.
(In reply to comment #7) > mikx: if you are concerned that someone disclose the bug because of the > checkins, please have in mind this bugzilla entry shows when you have reported > the bug. I am not scared someone will disclose the bug and take credit. Instead i am concerned about the security of majority of the userbase and the message of Mozilla products being a stable and secure platform. Most of you are probably longer involved in doing security stuff than i am. You have great "best practice" exprience when it comes to those situations when you have to choose from options that all have a drawback. I am sure MoFo will do whatever they consider best and maybe we can discuss optimization of the entire process in some other place, since that is probably far out of the scope of this bug report.
Comment on attachment 181355 [details] [diff] [review] untested patch a=asa
Neil, do we need a siilar change to xpfe (esp. on the 1.7 branch)?
Comment on attachment 181355 [details] [diff] [review] untested patch a=caillon for the branches
I copied the fix to xpfe and landed on aviary and 1.7 branches.
other than the test case in comment 0, are there other areas or things we should test to ensure that this didn't regress anything? thanks!
Testcase http://bugzilla:pdE2q8L@www.mikx.de/firelinking2/ appears to be fixed with latest Win32 Aviary build (Favicons appear to be working fine also): Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050509 Firefox/1.0.4
Checked in to trunk (although it's no longer a security problem there with darin's fix, I still prefer this approach).
Clearing security flag from announced vulnerabilities fixed in Firefox 1.0.4/Mozilla 1.7.8