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."

Secrecy?

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.

Re:Secrecy?

Honestly, Mozilla is in a lose/lose situation here.

If they hold on to fixes until all the distros are ready, they get beat up for slow patch times compared to MS. If they release immediately, they get beat up by the distros for not coordinating with them.

I think this is coming up because Moz is one of the first high-profile OSS projects to support both Linux/BSD and Windows. If this were (like most other Linux/BSD apps) an OSS-OS only app, then the lack of coordination would be a real issue. But, for the Windows folks, there isn't a distro to coordinate with, so Moz has to release as soon as possible. I'm with Moz on this, honestly.

Re:Secrecy?

I disagree. Completely. It's in the general interest of everyone for the app writers and the distros to work together...the goal, after all, is for the end user to get patches quickly, effectively, and *before* there's an exploit. A lot of the distros have central patch distribution systems...these systems are the best way to get patches to the end user for that distro.

If an app releases a bug fix without working with the distro, it leaves the end user there to get screwed...either they wait for their distro to get the patch put together (running vulnerable code the whole time), or they break their use of the patch distribution system (meaning they have to either re-patch once the vendor releases, or never follow the vendor patch system for that app again). This isn't a choice we want to be giving the users. The best result is *absolutely* a coordinated response, where the authors, the distros and the original reporter of the problem all release simultaneously.

That isn't possible in this case, since there's no distro to work with for Windows. Mozilla is, in this situation, choosing to minimize the risk for their Windows users (who likely far outnumber their OSS users), at the expense of the distro coordination. It's not a fun choice to make, but a sensible one, given their situation.

Re:Secrecy?

Why cant mozilla stop hiding bugs and marking vulnerabilities as secret in bugzilla? Open indeed...

I shouldn't respond to this troll, but I will.

Marking security-related bugs as secret is entirely appropriate. If the bug notes were public, they would serve as a blueprint to 0-day attacks on Mozilla, which the Moz folks are (rightly) attempting to prevent.

Attacking Mozilla for following standard security procedures for bugs is fucking childish.

Why is this a bad things?

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)

Nor should it have to.

Priorities are not the same all over, and Mozilla should be focused on supporting their users. Those several days of warning are extra days of end-user vulnerability. As a Firefox user, I would feel my trust was misplaced if they did something else..

One other comment:

indirectly -- it still displays their branding

Correct me if I'm wrong, but other builds are not supposed to use Mozilla's branding anyway. The PowerPC G4-optimized build of Firefox contains only compiler/linker changes, and apparently can not use the same icon.

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

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...

Just to clarify:

I am saying that if Red Hat expects OSS projects to sit on security updates until Red Hat has a new package ready, that is just plain rude.

Are all users not equal in the eyes of Free software? We should all be able to have a crack at the security update as soon as it is ready. Some of us do in fact maintain our own packages. Why should we be forced to wait?

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

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...

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?


Just speaking to the theory here, once the 'end users' are notified of the hole, it's reasonable to assume that 'someone' is going to reverse engineer an exploit out of the patch.

On very large holes, the coordinated release allows the largest possible user base to have an upgrade path by the time the hole is made public. If all users were notified as soon as a source patch was released, but the source patch didn't apply directly to distribution X because of local changes to the codebase, a malicious user could (and will) create and circulate an exploit before that group can create a patch.

Note that the security community does not agree here. When OpenSSH had a massive hole, Theo went mailing-list to mailing-list telling people a workaround, and coordinated a very large release of information on a specific day. When DJB's students come out with their list of new exploits every year, they release them all on a webpage with zero notice to ANYONE, including the software vendors involved.

It's a matter of philosophy - are you in the game to protect the most people, or are you managing your software and letting other people worry about their users? I personally don't have a problem with Mozilla's practices - they still beat some other vendors, even if they're not as 'responsible' as the OpenSSH crowd.

The question is "WHY?"

Quote: "redistributions of the official Mozilla releases are never going to give you security updates as quickly as Mozilla".

I read the above quote may times over and the person from RedHat's response. I kept asking myself over and over again...WHY? Because if Mozilla operated the same way other OSS projects do by default, I can only see good things out of this. I wonder why they choose to do things this way.

Re:The question is "WHY?"

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.

Re:The question is "WHY?"

So Mozilla should give RedHat preferential treatment? If they hold back a patch to wait for RedHat, don't they also have to wait for Suse? Debian? Everybody else?

Holding back patches is nonsense and is something Slashdotters regularly blast Microsoft for doing.

What's worse

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:What's worse

But mozilla/firefox from the mozilla foundation is released under the MPL with the logos trademarked (You can't use the firefox logo. In your custom version, you have to use the globe icon or something new)

You can freely download the tri-license source code (MPL/GPL/LGPL I believe) from the CVS. If the tarball isn't working it's probably because an automated script is busted and perhaps the person complaining should file a bug.

Well This Feels A Bit Weird...

Where's the article?? It's just two short blog entries between two guys arguing over an issue. How is that news or "stuff that matters"? It's almost like reading two headlines. This has a feel of high school.

High school girl A: So Ben Goodger's claim that "redistributions of the official Mozilla releases are never going to give you security updates as quickly as Mozilla"
High school girl B: "Christopher Aillon of Red Hat says that this is only because Mozilla doesn't play by the same rules as other OSS projects"
High school girl A: No. He didn't.

[cat fight]

Except there would be no cat fight here....

Making a story that isn't there.

Those links seemed almost like the biggest non-articles ever to hit Slashdot. I asked myself... "is that it?" Links to some petty blog nonsense, basically.

Mozilla's problems aside, Aillon's point is stupid. Stupid as that picture of him imitating the Matrix, or whatever the hell he is doing. Basically, there doesn't seem to be any meat here, any story. Good work saving Slashdotters the time of RTFA-ing, because in this case, reading the article wouldn't have made any difference.

Whiny RedHat, or lazy Mozilla?

This may sound like the tail whinning that the dog doesn't wag, but the vendors may have a legitimate complaint.

The potential for harm is if Mozilla releases a security fix, and the distros don't right away. There's a period of time in which Mozilla version x.y is vulnerable on FooDistLinux, and there's no reasonable expectation for the fix to happen for some period. Since the fix has been released, attackers are on notice that there is are vulnerable systems out there, and they're running Mozilla x.y on FooDistLinux.

Now, mind you, I don't think that's such a big fat hairy deal. But the situation does put minor distros (anything not supported by the official Mozilla site) at a disadvantage. The perception is that the major players are "more secure", since you can get your fix straight from Mozilla.org.

But Mozilla IS the vendor for most people

I suspect that the vast majority of Firefox users are on Windows (simply because the majority of computer users are). They don't have the luxury of up2date or an apt-get repository and have to go to each non-Windows vendor to obtain updates. Why should Mozilla wait for someone maintaining a repository for a minority of their users before releasing an update for the majority?

I'm sure that's the offical position, anyway. And of course they want to drive traffic to their site, and make a big deal about counting downloads.

fuck off

"simeltaneous releases of patched software"

This is OSS took to the extreme. One for all and all for one doesn't apply when people are at risk. If you don't release a fix ASAP then you're knowingly risking the security of peoples computers. Like it or not this is a ridiclous idea from the ground up.

Work together for the greater good, don't force others to work together so you all look good.

Depends

If the exploit is public knowledge, or is known as being used to exploit by blackhats, then releasing the fix as soon as it is finished is best. If the exploit is not publically known, and there are no signs it is being used, then a coordinated release is best. Not coordinating ends up leaving a window for blackhats to find out about the exploit and use the vulnerability on those systems that are not yet patched.

How is this Mozilla's problem?

I don't see how Mozilla is in the wrong. It is upto the various linux distributions to manage said distribution, not mozilla.

I want Firefox security updates as soon as they are available on my Micro$oft box, why should I have to wait for distribution X to play catchup. It is said distributions job to maintain that distribution, not Mozilla.

Should I, the user, have to wait for important security updates because some distribution wants to repackage them? The answer is no.

Paunch?

Is that a beer belly sticking out in that guy's Matrix imitation, or just the way his shirt hangs? Distinctly less Matrix-stylee if the former.

Why is latency such a problem?

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.

Becuase

Redhat makes it's own modificatoins to Mozilla and Firefox maybe.

Linspire surely does but they at least work with the company to get them into the main tree so it's not so much of a problem.

Along with any number of big distros that do something to the original package.

All which could of been avoided if said companies just used the plugin infrastructure to make their modifications and repackaged it that way.

Honestly

How long can it take for package maintainers to update the source and run the package-assembly scripts.

I mean, it is automated, isn't it?

Mozilla guys are not obligated to wait until the slowest of the crowd gets its job done. And they shouldn't treat any OS/distro differently from one another.

If Red Hat feels having up-to-the-minute RPMs is all that important, they should compensate Mozilla Foundation for the additional hassle. If not, they should wait in line just like everyone else.

Context... Context... Context...

This article rips Ben Gooder's words so far out of context that it is not even funny...

Here's the original sentence with the quoted portion bolded:
If security is important to you, this demonstration should show that browsers that are redistributions of the official Mozilla releases are never going to give you security updates as quickly as Mozilla will itself for its supported products.

The context of Ben's blog post was the final release of the Netscape 8.0 browser which was based on top of the Firefox 1.0.3 source code. Ben was merely pointing out that this left the Netscape users open to attack. Netscape promptly released 8.0.1 built on the Firefox 1.0.4 code.

Mozilla is fulfilling its obligation to its users by producing quality secure products, not pandering to an OSS "community" which seem more intent on arguing about every minute detail rather than change the way things are done.

To that end, Go Mozilla!

Project management

To me the project management of Mozilla looks messy if not broken. They make it extremely hard for people to contribute because their policies resemble those of a closed source company much more than those of open source projects. Just look at the patch review debacle that happened a while ago. If it's that hard to get code in there why would a developer even bother to waste his free time on this?

Now if that kind of tight control would allow Mozilla to keep their deadlines it would at least be explainable but given the performance in the months after the first release of Firefox I think their way of doing things needs to be changed quite a bit.

First there was the Aviary branch "crash landing" which caused a lot of bugs that weren't fixed even months after the merge. Then there was the planned 1.1 release which was originally planned for March then moved to June and I'm willing to bet they are not going to make that date either. At least the Deer Park developer release is really imminent now (Monday?).

Next is the whole Mozilla-as-a-platform thing which is something that was hyped *years* ago and yet we still don't have anything close to resembling a runtime environment. Hopefully there will be a XULRunner release soon but apparently neither Firefox nor Thunderbird will be put on top of it soon. I think most of these issues are a direct result of Mozillas bizarre desire to tightly control everything and keep the open source community pretty much locked out.

The irony is that Firefox has some exciting stuff coming up (<canvas>, svg, better extensions manager and update system) and it really hurts to imagine just how much more could be achieved if Mozilla would just open up a little more...

Firefox updates

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.

Red Hat not FOSS but IS a corporation

Red Hat has no valid beef. They merely want to look good to their stockholders. Remember that Red Hat is a corporation now and is no longer FOSS.

Mozilla is doing the right thing to release to users ASAP.

But Mozilla is a foundation.

Open-source companies will sometimes play games and be uncooperative.

But Mozilla is a foundation, so why should it care whether users get its code directly from it, or through Netscape, RedHat, etc., as long the user's code is properly patched.

So, instead of encouraging users to only get the code from them, they should work with others to setup good patch processes that work for everybody.

Waiting is a security risk

For Mozilla to wait to release security updates would increase the amount of time it takes to deliver security fixes. Mozilla's advantage is that it doesn't wait to deliver updates, so security holes can be filled quickly, unlike the competition.

Windows User Here

I have used Mozilla for over a year now and have been VERY satisfied with the release schedule especially as it comes to security releases. I get alerted with the little icon, I press icon, I download update, restart Mozilla, done. When it comes to security updates I do not want to see the release hampered because the distros haven't built it yet because quite frankly most of the exploits out there are for Windows anyway. No, I will not be transitioning to Linux anytime soon but I do support it where I can :).

Why?

I see the need for everyone to release server type updates at the same time, but not client things like web browsers. If there is a bug for Mozilla announced and your distribution doesn't have an immediate fix, don't use it. Ta-da! Use one of the many other browsers in the meanwhile.

Uncooperative

Bwaaaaa they're uncooperative... Mozilla doesn't wait those extra days to release their patches so we can have them first... bwaaaaaaaaaaaaaa mommy!!!!

What is this way "other OSS projects" behave?

Red Hat is basically a collection of several hundred separate OSS projects flying in close formation, each maintained by a separate team and integrated into an RPM for the installer to slide into place. Some of them are basically straight copies of the original, some of them are specially configured by Red Hat, some are more or less heavily modified. They are all different versions, and by no means are they all tracking the absolute latest release.

There are three or four major Linux releases like this, along with a dozen variants. All of these are "Vendors" that use OSS, as are the BSDs, commercial UNIX vendors, Microsoft, and Apple.

Most "other OSS projects" don't even know what versions of their software are being repackaged by vandors. In the case of commercial vendors, it's not even easy to find out. As far as I know yu can't even get a look-see into RHN without a license, and that can cost thousands of dollars.

There are really only a few a few high profile OSS projects with the time and money to do more than just stay on top of their own releases, and it's not at all clear that they should be obligated to do so. They're open source! They release code and make security announcements and if YOU care whether you're on top of the security of your software YOU monitor it and if YOU have some kind of security guarantees for your customers it's up to YOU to implement the tools to do it.

In general the assumption I've always made is that if I'm using OSS it's my responsibility to track it and stay on top of its security fixes... and make my own fixes if I think they're being lax. Having the ability to do that is one of the reasons you use OSS in the first place.

So...

If I download the Firefox source and do a G4-optimised build, I don't expect them to give me a heads-up ahead of time for a security fox. I'm not even paying for it: I'm downloading a copy of Firefox and that doesn't obligate them to me. Well, you know, unless Red Hat has explicitly established a tighter relationship with them than that (say, by paying for some kind of update service), they're not obligated to treat Red Hat any differently than any other person or group who's tracking their code base.

Other OSS projects don't. They don't have TIME to.

Re:We tried working with Mozilla...

It's a common troll. Replace the software in question with whatever is being discussed. The tagline is the giveaway, "Needless to say, the $SOFTWARE_PACKAGE team offered no support whatsoever. I made the employee uninstall $SOFTWARE_PACKAGE from the machines and lets just say he's not with us anymore."

Re:simeltaneous

Are you trying to say simultaneous?

Nope. He is obviously an overclocker running SMP and he is referring to the rare condition where all of his CPU's melt at once.

Re:We tried working with Mozilla...

Mozilla isn't obligated to offer you support. You are an idiot for firing an employee simply over a small software issue. Plus, any reasonable IT person would give users a CHOICE of IE or FireFox for quite a while, until people adjusted to the new software and the IT staff were certain that it would not conflict with existing systems (such as your intranet).

However, I'd like to note that Mr. Goodger should really learn how to develop websites for cross-browser compatibility. It looks like crap here at work, where we use IE. Being the lead-developer of a competing browser is no excuse for not having a website that looks good on ALL platforms.

corrupted project?

methinks you are in the wrong business if you design web-interface development apps that allow corruption of the source files due to a simple browser crash...

sum.zero

Re:We tried working with Mozilla...

This is not new, persay [slashdot.org]... however, it is getting very annoying.

Re:Who cares about Distro Packages, Compile your o

Mozilla is doing just fine, but I think it has the same overall outlook... 'if you're that stupid to use a package manager, then you gots to wait'.

Only the sith deal in absolutes!