Slashdot Mirror
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."
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.
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
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.
In this case it is a bit more complicated because releasing early patches is putting the distro-using people at risk. The fact is inherent to OSS, when a fix is released you just have to diff the source code to easily find the vulnerability of the old version and exploit it. So in this case I think this expose people to more risk than just a reasonable delay for everyone during which the vulnerability is not disclosed anyway.
so if you think a project will unreasonablly delay responding to a security bug just cc Full-Disclosure@lists.netsys.com when you report it.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
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.
This is not new, persay... however, it is getting very annoying.
The cow goes "tink"
mozilla-firefox-1.0.4 hit the Gentoo tree the same day the official 1.0.4 version was released and had been moved to stable on most architectures by the beginning of the next day. The binary packages (mozilla-firefox-bin-1.0.4) was in the stable tree within two days, same timing as Debian.
Sorry, my karma just ran over your dogma.
See and that is where you are wrong.
Red Hat doesn't just patch up other's work. Red Hat codes most of the stuff in the linux desktop and they pay alot of programmers to do it. Red Hat has coded most of Gnome (ximian also did alot), Red Hat hosts Gnome.org. They've done a hell of a lot of work for making OpenOffice.org integrate well with the linux desktop including using native widgets and Red Hat has coded and still currently develops GCJ allowing them to compile all of OpenOffice's java stuff natively.
They contribute code to firefox to make it work seamlessly with Linux. Red Hat contributes tons of code to Apache, they played a key role in getting SELinux into the mainline kernel. As a matter of fact, they pay the salaries of some of the best and most important kernel coders including Alan Cox. Red Hat has put more code into the kernel then any other entity.
Most of the drivers you are using were probably written by Red Hat, especially the audio and video drivers, and most likely your network drivers. Most of those kernel bugs and security issues are fixed by Red Hat within 24 hours, if not a few days, and Red Hat is one of the reasons why linux is known for such a good turn around time with patches.
Lets see what else they do... okay they host and fund GCC, GLIBC, Binutils, GDB and brought us Cygwin as well. Red Hat is a major backbone in the OSS world. They deserve all they praise and success that has come to them simply because most of the applications you use in a free software environment were coded, if not fully, then partially by them.
They are an integral part in Linux's success and are the only reason that it is enterprise ready with high levels of stability. You were right in saying that most distro's just repackage and sell other people's work, but Red Hat is the exception to that. Red Hat actually helps to make the stuff it sells and plays a huge role in that software. Now they are working on advancing linux's graphics capabilities and bringing linux to a whole other level.
You knock Red Hat for selling other people's work, yet they've written most of it and others repackage it and sell it. Get your facts straight and start appreciating what they do for the community (and just FYI, they do alot of quality assurance for OSS projects too, including firefox).
Regards,
Steve
You left out a variable: time. Releasing early widens the amount of time that the users relying on the distro for the patch are vulnerable. There is tons of evidence that vulnerabilities are attacked more after release of a patch, or announcement of a vulnerability. (Not to say it doesn't happen before, just that it happens *more* afterwards.)
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.
When a project knows there is a security hole and when the general public knows there is one is usually at least a week sometimes several apart. Many projects have secret lists that security information is distributed on. Also with respect to fixing the bugs in CVS they in general don't commit the security fix in CVS until the public disclosure date. An example project that I know does this is KDE.
People just like to beat up on Redhat but this really is standard practice for Case 1.
This isn't about communication making the world better. It's about a simple courtesy so you're not putting others in uncomfortable situations needlessly.
I used up all my sick days, so I'm calling in dead.