Slashdot Log In
Mozilla Uncooperative With OSS Groups on Security?
Posted by
CmdrTaco
on Sun May 22, 2005 08:56 AM
from the working-the-bugs-out dept.
from the working-the-bugs-out dept.
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Secrecy? (Score:5, Insightful)
Re:Secrecy? (Score:5, Insightful)
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.
Parent
Re:Secrecy? (Score:3, Insightful)
NO! Mozilla is responsible for its own releases and security updates and not for the distros'. Mozilla isn't there to make the life of Linux distros easy. The Linux distros must make security patches available ASAP.
Re:Secrecy? (Score:5, Insightful)
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.
Parent
Re:Secrecy? (Score:3, Insightful)
Lets break this down:
If:
Re:Secrecy? (Score:3, Informative)
So, it's in the general interest to get as many people patched *quickly* once the public announcement is made. Vendor patch systems are the best way to do that.
Re:Secrecy? (Score:3, Insightful)
Re:Secrecy? (Score:3, Insightful)
How do you pick what distros to work with? There are so many to choose from, do you just choose those who give you financial backing? Should the release time of distro A be forced to coincide with distro B? Should Red Hat and commercial vendors be in control?
I think they should release fixes as soon as a stable fix is available. Alot of people just use a distro for a base install, and then build apps from source, some even choose to do Linux From Scratch, its their choice. No one should be locked in
Re:Secrecy? (Score:5, Informative)
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.
Parent
Re:Secrecy? (Score:3, Insightful)
No, the fact that the most recent bugs were hidden for months and leaked along with an exploit is fucking childish.
Both RedHat and Mozilla have been trying this "hide all the bugs" crap for a while and it has resulted in worse security. And the only reason they're bitching at each other now is that each one wants to be the sole provider of updates. This is the kind of behaviour you would expect from Microsoft, not
Why is this a bad things? (Score:5, Interesting)
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)
Re:Why is this a bad thing? (Score:3, Informative)
Nor should it have to. (Score:5, Insightful)
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.
Re:Nor should it have to. (Score:2, Insightful)
Re:Nor should it have to. (Score:3, Insightful)
If its a 0day vulnerability letting other distros know in advance would be putting the vulnerability into the wild for any script kiddie to play with.
waiting to update their own product is bad for their own users
Exactly. If someone forks or uses open source code its a lot to ask the people who made the original trunk to take care for all. Share knowledge yes, but to do the j
I'm not sure I agree with this... (Score:5, Interesting)
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... (Score:5, Insightful)
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?
Parent
Re:I'm not sure I agree with this... (Score:3, Informative)
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.
What? Can you point out one instance of this happening, ever? Distributions release fixes all the time without waiting for the application team to apply and test the patches.
Don't screw me because RedHat is slow (Score:3, Interesting)
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 no
Re:I'm not sure I agree with this... (Score:3, Interesting)
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... (Score:5, Interesting)
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.
Parent
Re:I'm not sure I agree with this... (Score:3, Informative)
Re:I'm not sure I agree with this... (Score:4, Insightful)
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.
Parent
The question is "WHY?" (Score:4, Insightful)
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?" (Score:5, Interesting)
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.
Parent
Re:The question is "WHY?" (Score:3, Informative)
People just like to beat up on Redhat but this really is standard practice for Case 1.
Re:The question is "WHY?" (Score:2)
Re:The question is "WHY?" (Score:5, Insightful)
Holding back patches is nonsense and is something Slashdotters regularly blast Microsoft for doing.
Parent
What's worse (Score:5, Interesting)
Re:What's worse (Score:4, Informative)
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.
Parent
Re:What's worse (Score:2)
Well This Feels A Bit Weird... (Score:2, Insightful)
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
Re:Well This Feels A Bit Weird... (Score:2)
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.
Except that these two highschool girls talk in the name of two pretty large OSS projects, and thus are in the interrest of 'News for nerds' ...
Making a story that isn't there. (Score:5, Insightful)
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? (Score:5, Insightful)
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.
Neither... (Score:3, Insightful)
The real problem is that a Linux application needs to be modified in some way by the operating system vendor before end-users of that operating system can use it. Think about that for a minute. When's the last time you had to go through Microsoft to download the latest copy of a 3rd-party application?
One of the selling points of OSS development has always been its decentralized nature.
But Mozilla IS the vendor for most people (Score:5, Insightful)
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 (Score:3, Insightful)
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 (Score:5, Insightful)
Parent
Re:Depends (Score:3, Insightful)
I can set things up to automatically patch or notify me when security patches come out for my distro. I don't know of anyway to do that right off the Mozilla site. This is all pretty moot in this situation since the exploit was already publicized, and this is end user software as opposed to serve
How is this Mozilla's problem? (Score:3, Insightful)
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.
Re:How is this Mozilla's problem? (Score:3, Interesting)
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 pu
Why is latency such a problem? (Score:4, Interesting)
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 (Score:3, Insightful)
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 (Score:3, Insightful)
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... (Score:5, Insightful)
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!
Windows User Here (Score:3, Insightful)
Re:We tried working with Mozilla... (Score:3, Insightful)
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 wo
Re:We tried working with Mozilla... (Score:2)
Re:simeltaneous (Score:3, Funny)
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.