Mozilla Uncooperative With OSS Groups on Security?

An anonymous reader writes "In response to Firefox lead developer Ben Goodger's claim that "redistributions of the official Mozilla releases are never going to give you security updates as quickly as Mozilla", Christopher Aillon of Red Hat says that this is only because Mozilla doesn't play by the same rules as other OSS projects. He says that while other OSS projects work with vendors to achieve simeltaneous releases of patched software, Mozilla does no such thing unless compelled to do so."

Comments

Why is this a bad things?

[afd8856]

They may want to release the updates earlier, without waiting for whatever linux/bsd distro to updated their packages.

And it seems fair to me. If I run fedora, for example, if I'm concerned about security, I can always download and install their binary package. Because, for example, I couldn't find an updated rpm for firefox 1.0.4 (only a spec file)

I'm not sure I agree with this...

[Rantastic]

Other projects make sure that the vendors know of a security vulnerability, supply the patch and new tarball (if applicable, which it is in mozilla.org's case), give a brief period of time for the vendors to catch up, and then do a synchronous release with them at a planned time.

Ok, I do agree that OSS projects should supply security patches when they have them, and new releases as well, but what good does it do to let the vendors at them first?

Why should end users not be offered the same patches as soon as they are ready? If it takes a vendor 24 hours to get a new package out, that sounds reason able to me, but again, why limit access to the update for that 24 hours?

Re:I'm not sure I agree with this...

[Husgaard]

I understand why Mozilla does not want to delay security updates. Of course Redhat would like that at it would look like they are less behind on security updates.

Unfortunately it looks like Redhat has persuaded other Open Source projects to delay their security updates.

And now Redhat is using these other Open Source projects to attempt to pressure Mozilla into also delaying their security updates by claiming that Mozilla doesn't play by the rules.

Shame on Redhat.

Re:I'm not sure I agree with this...

[zerbot]

Holding back by a few hours until vendors can merge the fixes with any customizations they have done actually equalizes the users, in that all end users have access to the fixes for their particular build at the same time, regardless of where they get their builds from. If Redhat discovered a security flaw, patched it themselves and then released their fixed version without giving the mozilla people time to patch and QA, people would be screaming bloody murder.

Re:I'm not sure I agree with this...

[zerbot]

I'm sure you have an example of a vulnerability not yet exploited in the wild that was patched and released by one distro without notification and coordination with the other distros.

Mozilla was not wrong to release this fix as soon as they had it ready, as the vulnerability had already been publicized. However, security fixes for vulnerabilities that don't have known exploits in the wild should be coordinated.

Re:I'm not sure I agree with this...

[LnxAddct]

Err... actually this whole everyone releases together is a common thing in OSS and it keeps the projects happy with each other. Red Hat writes a lot of code that gets put back into the official firefox build as well as alot of other OSS projects, including security fixes. Red Hat doesn't just release their security patches and then let the other projects know about them (thus putting firefox behind). They make sure that everyone is caught up, all of which can usually be achieved in about a 12-24 hour period which is fine. This isn't just something Red Hat does, all the major OSS projects do it, it actually takes some effort but as long as everyone follows these rules it works nicely. Mozilla would be screaming bloody murder if Red Hat released a security fix for firefox without letting the official firefox team in on the patch before it was relased. Red Hat does alot of active development and its not exactly fair that anything they fix they send to Mozilla and wait for Mozilla to officially release, but anything that Mozilla releases they just don't care about the many vendors who constantly do QA, coding, and security for Mozilla. Higher threads were talking about user/vendor equality, but vendors do alot more for mozilla then most users. Noone is complaining about Mozilla's security policy, just how it is ironic that if all the vendors started collaborating together and lets say Novell and Red Hat released a version of firefox to their users that they fixed so that their end users get the fix as fast as possible and then they let mozilla know about it, mozilla would be freaking the hell out. All the vendors are asking is that mozilla give them the same courtesy that they give to mozilla.
Regards,
Steve

What's worse

[keesh]

What's worse is the way the mozilla projects rarely seem to manage to put out an actual working source tarball. For the past dozen or so releases they've always released incomplete or unworking sources. Screwing up once is understandable, but to repeatedly omit things strongly implies that they're not interested in anyone using anything except their official binaries.

Re:The question is "WHY?"

[ProfaneBaby]

There's really two scenarios here:

1) A hole is made known to Mozilla before it's made known to the public.

2) A hole is made known to Mozilla and the public at the same time.

In (1), it's reasonable to ask that the software developer at least make a token notification to various vendor's security contacts. Most of the vendors are reasonably private - they won't post the matter to a mailing list - and responsible. The software developer certainly doesn't HAVE to do this, but it would benefit a larger portion of its end users.

In (2), it doesn't make any sense to notify each distribution, because the whole world already knows, and each hour wasted on notification could mean people who are damaged by the hole.

I think the difference between (1) and (2) is significant, and it's important to realize that the case we're talking about here is (2). The hole was made public in Bugzilla, and Mozilla had to rush to create a patch. Holding that patch to give the distributions time to update is silly - people already knew there was a hole, and users were already waiting on the fix. If the initial bug was private, this would be an entirely different story.

Why is latency such a problem?

[vagabond_gr]

I don't understand why a 1-2 days latency is such a problem for a distro. It's like someone complaining that cvs users get the fixes before they appear on mozilla.org.

Summary:
- you're paranoid about security, get cvs updates every hour.
- you're seriously concerned about security, get the new binary as soon as you read it on /.
- you're lazy and you like it: apt-get install, 1-2 days after.

Don't screw me because RedHat is slow

[Mr. Underbridge]

Holding back by a few hours until vendors can merge the fixes with any customizations they have done actually equalizes the users, in that all end users have access to the fixes for their particular build at the same time, regardless of where they get their builds from.

And that's good why? If a fix is out and I'm running something mission-critical, I want it now. If your distro is slow, get another distro - or better yet - install it your f**king self using the version Mozilla puts out. It's really not hard. Sometimes, I swear, I think some people would be incapable of installing software if they didn't have a package from their distro. Of course I imagine it's obvious what distro I use. ;)

Firefox updates

[ChrisJones]

Something that has irked me is that I can no longer use the official firefox extension type pages.
I'm running ubuntu with firefox 1.0.2 and the later security patches are applied, but their pages still tell me I should be running 1.0.4.
Pretty stupid imo.

Re:Secrecy?

[Chris Snook]

Sounds like the alleged rules involve keeping bugs secret until users of the code have updated it and/or changing their release cycle to accomodate this.

Nope. What happens is that everyone agrees to make full disclosure and a patch available at exactly the same time. Sure, this delays the patch slightly, but it keeps everyone on a level playing field for security, since it means that attentive sysadmins can read the advisory, determine if it applies to their systems, and have their machines patched within *minutes* of the announcement, no matter what OS/distribution they use. It's nothing like the "upgrade to the latest version and we'll tell you why in a few days" fiasco when the double-free bug was found in OpenSSH. Coordinated security updates also go through several vendors' (different) QA processes, greatly reducing the risk that the patch broke something else.

Re:How is this Mozilla's problem?

[Chris Snook]

It's the project's problem if they want the continued support of the vendors. A completely plausible example of how a vendor could be justifiably furious:

1) Vendor gets bug reports from their customers.
2) Vendor examines the code and discovers that the bug is exploitable.
3) Vendor's developers write a patch and send it to the project's security team.
4) Project security team realizes that they do a similar bad thing in other parts of their code, and the fix will need to be a much larger patch.
5) Project publishes the larger patch with full disclosure of vulnerabilities.
6) Vendor's QA and distribution people stay up all night verifying this much larger patch, to minimize the amount of time their customers are vulnerable to the exploit they discovered in the first place.

No, it doesn't always happen like this, but it can and has. This is why the vendors have set up coordinated disclosure agreements, where they all say "We're going to publish this whole thing at exactly this time." and if any vendor can't QA it and push it out to their customers in time, that's their problem.

For the millions of dollars in development effort that the various commercial distributors put into the various F/OSS projects they use, you'd think they deserve a level playing field on security. If your project doesn't think the vendors deserve this level playing field, don't be surprised when your project gets forked, or those millions of dollars in development effort get redirected to someone else's project.