EDIT: my bonsai query is wrong - I restricted it incorrectly, so there are actually more changes. I still think my point stands, though this means many more lines of code changed.
Nothinman sent me a pm.
Figured I might as well reply here. I'm not speaking for anyone. This is a mix of facts as I understand them, and my opinion.
Response to http://www.infodrom.org/~joey/log/?200507300606:
The ranting Debian person also fails to explain WHICH of the VERY small number of changes weren't security-related. (In this case, the API change in 1.0.5 wasn't security issue, but a fix for a major regression that had been introduced on the Gecko 1.7 branch, which powers Firefox 1.0.x and Mozilla 1.7.x).
The Mozilla Foundation has broken compatibility twice so far in 1.0.x releases - 1.0.3 to fix a severe security issue (I believe this was a reasonable decision - get hacked when using any of a large number of extensions, or break compatibility with a handful extensions - what would you pick?), and 1.0.5 because they didn't catch side-effects of a change (1.0.6 unbreaks what they broke with 1.0.5). Are they not allowed one mistake?
What's really annoying is when distros do something like "1.0-3" which backports a security fix into 1.0 and report a 1.0 user agent, though the code is identical to, say 1.0.4. The result is that they get banned from Mozilla Update, since for security reasons Mozilla Update can't serve any content to Firefox 1.0.3 or older, but the site can't tell that their "1.0" actually has the necessary security fixes. Because the distros don't bump the version number, their users come complain to the Mozilla Update people. We take enough flak about picking security over convenience from people using official releases already.
Response to http://kitenet.net/~joey/blog/entry/bug_hiding_systems-2005-07-30-06-25.html:
The guy goes on to log in with a bugmenot and, of course still can't access the bug.
Ubuntu's decision to just include the new release rather than backporting patches is probably what the Mozilla Foundation wants anyway - that way there are fewer users filing bugs on nonsensical / modified product versions. Every so often, someone files a bug using a distro-modified version that turns out to be a problem in the modifications the distro made. Shipping official versions would reduce this.
If I understand correctly, this guy is first complaining that the bug is closed, and second complaining that it's only closed for two weeks before the black hats get access. Which way does he want it? He's also apparently not aware that there's an advance-notification list that distributors and vendors can join to be notified earlier about security issues and fixes.
Nothinman sent me a pm.
Figured I might as well reply here. I'm not speaking for anyone. This is a mix of facts as I understand them, and my opinion.
Response to http://www.infodrom.org/~joey/log/?200507300606:
You could use bonsai to diff the sources between point releases and get the patches you want. {edit:following numbers are incorrect - real numbers are 1-2 thousand} They added 52 lines and removed 39 lines of code between 1.0.4 and 1.0.5. They undid one of the changes (+33 lines, -46 lines) for 1.0.6. It doesn't get much more specific than that. Each checkin even has a brief comment explaining what the code change does. The code itself is often commented. If the Debian team doesn't care enough to read those few dozen lines of changes, and get on IRC and talk to mozilla devs to figure out what's being changed if they don't understand, maybe they shouldn't be shipping modified versions of the product.It is very unfortunate that the Mozilla Foundation does not provide dedicated, isolated and clean patches for security problems that have been reported against their software packages which do not change the functionality. Instead they release new versions that usually fix tons of security problems and other stuff irrelevant for security updates.
The ranting Debian person also fails to explain WHICH of the VERY small number of changes weren't security-related. (In this case, the API change in 1.0.5 wasn't security issue, but a fix for a major regression that had been introduced on the Gecko 1.7 branch, which powers Firefox 1.0.x and Mozilla 1.7.x).
The Mozilla Foundation has broken compatibility twice so far in 1.0.x releases - 1.0.3 to fix a severe security issue (I believe this was a reasonable decision - get hacked when using any of a large number of extensions, or break compatibility with a handful extensions - what would you pick?), and 1.0.5 because they didn't catch side-effects of a change (1.0.6 unbreaks what they broke with 1.0.5). Are they not allowed one mistake?
What's really annoying is when distros do something like "1.0-3" which backports a security fix into 1.0 and report a 1.0 user agent, though the code is identical to, say 1.0.4. The result is that they get banned from Mozilla Update, since for security reasons Mozilla Update can't serve any content to Firefox 1.0.3 or older, but the site can't tell that their "1.0" actually has the necessary security fixes. Because the distros don't bump the version number, their users come complain to the Mozilla Update people. We take enough flak about picking security over convenience from people using official releases already.
Response to http://kitenet.net/~joey/blog/entry/bug_hiding_systems-2005-07-30-06-25.html:
First off, it's not that you log in, it's that you have to be a member of the security group. Note that the message says:There were several links to the mozilla bug tracking system, I chose the first:
Amazingly, they want you to get a user account and log in just to see a bug report. This is normally the point where I decide I have something more pressing to attend to, and so will most people.Access Denied
You are not authorized to access bug #294795. To see this bug, you must first login to an account with the appropriate permissions.
Please press Back and try again.
I can't see the bug either. These are the only people who can see that bug (plus any others they specifically allow). This guy should understand that for all major vulnerabilities, they specify a date when the relevant bugs will be open. The idea is to give distributors time to fix their releases, and people time to update before telling the world how to exploit the hole (often bugs contain testcases which could trivially be adapted into exploits).To see this bug, you must first login to an account with the appropriate permissions.
The guy goes on to log in with a bugmenot and, of course still can't access the bug.
As I said above, there aren't that many changes made in 0.0.1 releases. The distro people can't spend 10 minutes on IRC to talk with Mozilla developers about the changes?That's right, this bug, which is for a security hole that was fixed two weeks ago, is not being dislosed until apparently, August 1st. Same is true for several others of the holes fixed in recent versions. That's two weeks for distibutions that have to backport these fixes to race against black hats to see who can track down the hole in all the other changes in the new mozilla release, and respectively fix and exploit it.
Ubuntu's decision to just include the new release rather than backporting patches is probably what the Mozilla Foundation wants anyway - that way there are fewer users filing bugs on nonsensical / modified product versions. Every so often, someone files a bug using a distro-modified version that turns out to be a problem in the modifications the distro made. Shipping official versions would reduce this.
If I understand correctly, this guy is first complaining that the bug is closed, and second complaining that it's only closed for two weeks before the black hats get access. Which way does he want it? He's also apparently not aware that there's an advance-notification list that distributors and vendors can join to be notified earlier about security issues and fixes.