Slashdot Mirror
Torvalds on the Linux Security Process
darthcamaro writes "Linus Torvalds thinks that Linux kernel security disclsoure should be completely open and he really doesn't like the vendor-security model of having a time embargo on security disclosure. 'I think kernel bugs should be fixed as soon as humanly possible, and any delay is basically just about making excuses,' Torvalds wrote. 'And that means that as many people as possible should know about the problem as early as possible, because any closed list (or even just anybody sending a message to me personally) just increases the risk of the thing getting lost and delayed for the wrong reasons.'"
...he propably knows what he's talking about.
kernel bugs
Thou shalt not speak ill of the linux kernel!
Oh wait, it's Linus.
any closed list (or even just anybody sending a message to me personally) just increases the risk of the thing getting lost and delayed for the wrong reasons.'"
I think he really hit the nail on the head with that comment. I can't tell you the number of times CRs or issues have been sent to me through e-mail which have either been lost or forgotten about on my part (sorry). However, using tracking programs which the entire group has access to (we use Mantis) not only are the problems kept on fresh but people will remind me of them or if they are feeling particularly bold, fix them themselves.
-Teiresias
Bingo.
The old Lie: Dulce et decorum est Pro patria mori
"And that means that as many people as possible should know about the problem as early as possible, because any closed list (or even just anybody sending a message to me personally) just increases the risk of the thing getting lost and delayed for the wrong reasons.'"
I don't disagree with what Linus is saying, but what difference does it make if 10 people are informed rather than 10 million when it still doesn't change the fact that only a select few can change the official kernel source? People in production environments aren't going to apply a patch created by Joe in his basement, they're going to want an official kernel patch.
If the ones responsible for the affected part of the kernel are slow to handle a security issue, full disclosure IMHO is a bad thing.
One could argue that full disclosure would motivate those responsible to fix the problem faster, but this is not always the case.
If Linus is the only person that can change a specific part of the kernel, what good does notifying the world instead of just him do?
once an issue comes out, if they don't fix it immediately, and then we patch our systems immediately, we're in trouble.
I don't get that. Linus may be smart, but that just seems dumb if some time can be bought.
the risk of the thing getting lost and delayed for the wrong reasons
As opposed to getting lost for the right reasons?
bug.gd: error search engine. Humanity working together to solve all errors.
I've never really gotten the mechanism whereby software giants keep their software secure by not telling anyone about the security hole until it's fixed. First, we know about information leaks. Secondly, it's terribly profitable for some people to sit around and figure out security holes so they can steal from people.
Especially in the position that Microsoft is in, with the lion's share of the market, and a supposed interest in keeping my data secure, I would assume that the first move would be to notify their customers of any security hole that might be potentially harmful to me. Given the number of them, I guess it would keep my mailbox full, but I wouldn't mind.
Oh, I don't use Windows. Nevermind. Yay for Linux (and Linus)!
Please stop stalking me, bro.
I'll sit here cowering behind my hardware firewall, and prepare for an invasion...
Cheezit! We're boned! - famous 31st Century bending unit
and this is it. I totally agree with his ideas and would prefer his solution -- total openness.
"Otherwise it just becomes politics..." -- Linus Torvalds
I totally agree with Linus on this. Without an open system of issues, where is the accountability to get this stuff fixed quickly. Any bottleneck is still a bottleneck.
Got a site/story worth sharing? Leave a mark
Torvalds says this and its the TRUTH for the masses.
Gates says this and its LIES for the masses.
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
Why would you have all your ports exposed with nothing running on them? I have a hardware firewall. I only run HTTP ad FTP when I need them and then turn them off when I am through. It is really just simple security. Be smart. Oh yeah I subscribe to security lists and patch when security patches are released.
Insert Generic Sig Here:
Linus is the only figure in the entire OSS movement who doesn't have his head shoved up his ass.
Everything he says is practical. He's all about technology, not new-age computer "philosophy" or rhetoric. He doesn't go around promoting linux because he thinks "M$ is Gayer Thean AIdz!@!!", he does so only when he truly believes it's a good solution.
Here he is showing it again. He believes in full disclosure of bugs, not for any philosophical bullshit or imaginary right-to-know, but because it gets bugs fixed faster and improves the product.
Once again, he's the only member of the OSS movement worthy of respect. He's the only reason businesses have considered linux an option, and the reason for any success it sees.
The rest of the movements "figureheads" do more harm than good. Who else has been shot down when proposing a linux/OSS solution, having one of RMS's communist rants thrown back at them?
I don't need no instructions to know how to rock!!!!
Linus is just trying to keep the politics out of it, is all. He's not saying that every bug should be made public knowledge immediately, only that things shouldn't be kept secret for reasons other than the security of the users' systems.
"You're older than you've ever been, and now you're even older."
When someone sends a personal message to me about bugs I forward them to a mailinglist as fast as possible, otherwise it _will_ be lost.
Mohahah!
Something like a moderated BugZilla. People submit their bugs/holes, and they go to a list which only trusted people can see. I think there are more people out there willing to see a security advisory and use that to create malicious code (if only to test it out, trick people etc.) than those who see an unsolved security advisory and work on patching code. I don't really want the general public seeing what holes I have on my machine, as that's what it comes down to really.
http://it.slashdot.org/article.pl?sid=05/01/10/035 225&tid=172&tid=106
0 7/ 2028203&tid=172
http://linux.slashdot.org/article.pl?sid=05/01/
Since the article is pretty much a copy/paste job from the lkml, why not link directly to the thread in question?
-- If no truths are spoken then no lies can hide --
I'm still debating whether its good or not. Well, the theory is good, and what's bad will be systems where changes can't be made immediately. For eg, a corporation says that security patches MUST be analyzed/tested in-house BEFORE applied to production or "public" systems. Also, I'm sure there will be systems whether the admin can't get to them right away. This, obviously, is a problem. Is it worse than having a closed system and delayed notification?
rewriting history since 2109
The other reason why this is the right way to go is because we should be moving towards a model of damage containment with all forms of electronic security. Faults should be isolated. A security problem in one part of the code should not result in a total compromise of the system, even if that fault is in the kernel. That's where Linux should be heading. Part of that would be moving more stuff out of the kernel and also having less stuff running as root. The end goal would be to get rid of root entirely.
There's a good writeup on this thread at KernelTrap, too. Includes links to the full thread, which is quite fascinating.
Linus, I recall corresponding with you back in the day (whoa, date myself, around pre-.9) and you were right on then, and you are right on NOW. NO crap delays.
Linus Torvalds for president
While I would like to know of security vulnerabilities, it makes me very nervous when the associated POC or 'sploit is released along with it. There should be a middle ground. As a security admin, I would like to know when I have a vulnerability on systems as to allow me to attempt to mitigate the issue as much as possible. When the POC/'sploit is released in the same day as the security alert, I am that much more of a disadvantage.
Paranoid tinfoil hat crowd say Y here, everyone else say N.
Computer security these days is becoming more and more related to national security.
We need a simple bill (preferably a UN decision that countries agree to abide by and enforce among their citizens).
1. All vendors must provide an email contact for security issues.
2. There will be 1 official list for security disclosures. Mantained internationally.
3. The vendor gets 48hr advanced notification. To allow them to patch/research if it's high profile.
4. If vendor feels the security issue is extremely critical to safety/welfare, they may ask the offical list for extended time. In which only governmental agencies will have acess to the issue. Not the general public.
5. Fix/workaround must go to another list. This list will be publically accessible to anyone.
Last regulation is simple:
*no* charge may be issued for security fixes. All security patches must be made available free of charge to a paying customer.
Reasons:
1. Central place to know of security issues. Rather than checking several places.
2. Ability to keep critial problems away from public knowledge until the vendor when it's serious.
3. Make it easy to find out and research issues.
The current situation is to ad-hoc and spread out. It's very hard to manage.
That guy is not right!!
All you need to keep Linux computer secure:
1) enable *by default* build-in kernel firewall to reject all incoming connections
2) keep your kernel up to date, by autodownloading & installing patches from kernelupdates.linux.org
3) build antivirus *inside* linux kernel and insure that you have latest antivirus and exploits definifins.
I don't understand why are you, linux users, don't come with that simple idea long time ago! If every linux users will follow this three simple steps then no one from internet will be able to hack or exploit your computer.
If a closed vendor is "slow" on fixing an issue guess what happens? You wait. Hopefully there is disclosure so you know what to protect "from the outside" while you patiently wait for the vendor to release a fix.
On the other hand, if the maintainer responsible for an errant kernel module is "slow" then guess what happens? Someone else fixes it. Most importantly, you can fix it if you chose to do so. If you know there is a problem, you have the source, and ultimately you can fix it. You don't have to wait for the kernel maintainers to get going. You can get started on correcting it today. This is why full and open disclosures on security issues are important for Linux and BSD.
Ultimately, this is the strength of OSS projects. No one is beholdened to any programmer or entity. You are given more options on what to do than wait for the vendor.
I am completely amazed by Linus. I have been reading the Kernel list for a few days now and I realize just how incredible he is.
He seems to take this approach that he is a figurehead. At times he seems like he knows this and sometimes does not want to be. But for the most part seems to revel in that he is the figurehead of Linux. I wish I had some of the really simple things but in this particular instance he was talking about how he has to choose the route of being completely open. All kernel-sec issues are completely open to the public and there is no secrecy. He then goes on to describing how vendor-security lists are completely closed and noone releases information until it is fixed or it actually goes public by a third party. He descibes a middle of the road where there is a closed-open list I still don't get it.) And that since it's a comprimise noone wins but it meets both people needs.
Anyway I highly advise subscribing to kernel mailing lists and just filter everything except for Linus and maybe Alan Cox, and Morton. I am sure everybody on the lists are just as important but there really aren't enough hours in the day to follow the whole thing.
This sig is my vote for Linus to be nominated for a nobel prize.
CAPS LOCK: ITS LIKE THE CRUISE CONTROL FOR AWESOME
Obscurity is the most basic security strategy. Just as the guys on the Death Star.
Scenario 1: Bug is detected. Full disclosure including exploit.
Result: Mallory uses exploit. Alice releases a bugfix, Bob applies the fix. If it takes Alice andBob longer than Mallory, the server is compromised.
Scenario 2: Bug is detected. Kept quiet.
Result: Eventually Mallory detects the same bug. Exploits it. Server compromised.
Scenario 3: Bug is detected. Released only to trusted developers.
Result: Alice releases bugfix. Announces that it fixes a security hole. Gives general details of what the bug is. Mallory has to work out the details and exploit it. This gives bob a lot more time to apply the patch than scenario 1.
So what's so great about full immediate disclosure?
It doesn't really matter. You should consider wild exploit code available the moment a vulnerability is discovered. While this is less common than some kind of grace period (days, week?) you should act according to the risk of immediate vulnerability.
would be Kernel Sanders - the 11 secret herbs and spices are one of the most closely guarded industrial secrests of all time.
Whenever theres an article by Perens or RMS or these other blowhards, I cringe a little bit, and hope my boss doesn't read them.
I think most of what you say is very valid but right here you lost me a bit.
The OSS movement is not alone in having some more extreme members. I'll take RMS any day over Ballmer jumping around like a monkey screaming, "Developers! Developers! Developers!"
Really, I know what I'm doing...Ohhhh, look at the shiny buttons!
The vendor should be notified immediately and allowed time to provide a fix to the public. If you notify the vendor and the public of your discovered vulnerability at the same time then you have not helped anyone since there is no patch available anyways. All you've done is let some script kiddie exploit a lot of machines, and that's not responsible disclosure.
While I see your point, I do not agree fully. If an exploit is not the wild when the vulnerability is discovered, providing the code will most certainly assist in accelerating the release of a worm or a script kiddy tool.
Paranoid tinfoil hat crowd say Y here, everyone else say N.
It could just have the effect of informing thousands of 'bad people' exactly how to compromise your system and there's still no patch available. All you've done is add one more complexity to the issue by disclosing it to script kiddies.
Would you want to install a patch across thousands of workstations when it was developed and tested in 5 working days just so you feel safer? This could have even worse side effects than actually leaving them vulnerable. That's a sysadmin 101 no-no.
Billg wrote parts of the MS Basic code, waaaay back in the day. One particular part that comes to mind was the "paint fill" function (whatever it was called). Turns out it was as slow as a pig's ass, too. Tee Hee.
Yeah, right.
He says he never wants to wait applying a fix, because he wants to give users the best kernel possible. Then he says that it probably doesn't matter that the kernel.org kernel gets fixes last, because most users run vendor kernel anyway.
But I think what annoys me most is that he is constantly claiming he is not forcing his (in his own admittance extreme) views on anybody. But this is just not true: In his position, he imposes his view on dealing with security issues on all kernel.org kernel users, and indirectly on vendor kernel users, just by the way he actually deals with them.
From the discussion it turned out that the vanilla kernel often lacks security fixes because of Linus' complete refusal to work with vendor-sec. (2.6.10 got released with holes that had been fixed in 2.6.9-ac for a while.) And on the other hand, Alan Cox blamed him for quietly applying security fixes to his tree all the time; he actually said he is constantly reviewing the patches for this (since the blackhats obviously are doing the same).
I think the full discussion is worth reading. It's an interesting clash of culture between people like Alan Cox, Marcelo Tosati etc. who have been working for a vendor for a long time and feel responsible for their users, and have thus adopted a rather pragmatic view, and the more fundamentalist full-disclosure of people arguing on Linus' side.
Anyway, I am sure they will find a middle ground, because all agree that there is a need for a) a linux kernel security contact point (which will probably be a new closed mailing list with rather short disclosure timeline), and b) an established channel for announcing security holes (and maintaining security-fixes-only 2.x.y.z kernels).
How iptables keeps me safe from the latest Mozilla vulnerabilities coming out? Yeah...
The responsible people that post to those lists give the vendor about 30 days. Five is just ridiculous. And in fact, those who have immediately disclosed the vulns with PoC attached are indirectly responsible for the worst worms because of their tell-all mantra. Script kiddies turn that into a worm before the vendor even has a chance to fix and test (testing is an important time-consuming part of this) it. It's irresponsible.
And you are under the impression Linus writes all the kernel code are you? You poor stupid bastard.
here
That's just great - let's get the government involved. Can you name ONE thing that government has done more efficiently and more economically than the private sector? RW
Interesting read about OS/2 (and IBM)
the sp2 firewalling as default, is just a really stupid way to solve the real problem, listening on ports not needed. come on, why would you listen on a bunch of ports, then firewall them?
For what it is worth...
0 0azV2y9... . understand please that we (well, spender at least) already had had a working two-way email connection with Linus. during the holidays i had finally time to work on the forward port of PaX (last supported version was 2.6.7) and that's when i realized the change in status of the expand_down() bug as since 2.6.9 it became exploitable by unprivileged users as well. so i emailed Linus about it (of the importance, not the bug itself, he had already known about it from spender, although he had never replied back on that one). one week later, which is early this year i resent the mail to Linus and Andrew as well, and the next day spender forwarded the mail himself to them (as i said, he had a known working email route to Linus at least). nothing happened except spender was preparing the next grsecurity release and it became more and more urgent to get some feedback on these issues. we were considering emailing Alan Cox (the week of waiting allotted to Andrew as well wasn't over yet) when the uselib() exploit suddenly hit the net and everyone entered forced release mode, we couldn't delay it either.
(Posted Jan 10, 2005 11:26 UTC (Mon) by guest PaXTeam) (Post reply)
lots of speculation so let's see the actual timeline a bit. spender emailed Linus sometime early december about the few issues he had found. he also mentioned some of the fixes that were in PaX, the result of one of them was this commit: http://linux.bkbits.net:8080/linux-2.6/cset@41bc9
now that you know some background, tell me again, 1. how much more we should have waited, 2. why we shouldn't have contacted Linus/Andrew in the first place, 3. why we should have contacted Alan first (who is explicitly not the security contact anymore), 4. why we should have contacted a VM hacker first (none of whom is a security contact either, not even for their respective employer, let alone linux/VM in general).
see, i've been in the security industry for some number of years now, and i know quite well what best practices are (everyone's got his own, but there're some common elements):
rule 1: you contact the explicit security contact first. for linux this used to be Alan himself, nowadays it's vendor-sec (yes, that means you're not supposed to deal with individual distros, that's why vendor-sec was established in the first place). except they proved to unreliable, not to mention that it's *impossible* to contact them in a secure way (they don't have a PGP key).
rule 2: short of such a security contact, you begin contacting the 'people in control', from top to down, not the other way around. for companies that's relevant because the chain of control also represents the chain of responsibility. you can argue that open source/free software projects are free of chain of control, but they're not free of responsibility. i believed and still believe that we did the right thing when we began contacting Linus, then Andrew and were about to contact Alan when external events intervened.
> THAT is why there is all this maintainers/lieutenants business.
except the VM has no explicitly listed maintainer. but yes, i can guess who the main contributors are, but that doesn't make them a security contact (remember, we only wanted to get feedback, be told what to do next, and *not* to force Linus or anyone to actually manage the issue). it makes them the right person to actually fix the bug, but that's only the second step after the initial contact.
> PaxTeam isn't subscribed to LKML. Why? Because "there's too much"?
correct, i have a day job (unrelated to linux), family and friends, i can't handle that email load (and there's more in my world than lkml). i don't know where you got that i didn't like lkml, if i wasn't sympathetic to linux, i would have posted everything to bugtraq a month ago (contrast that to the recent DJB case).
> And that fact that it claims to report a security vulnerability is quite
> likely to get it classified as "crying wolf"
i provided a proof of concept exploit (which you would know if you had actually read the announcement and posts here).
"Rocky Rococo, at your cervix!"
--
sigs sugs
so say we all
On the Banks of the Wabash, Far Away
Written by Paul Dresser
Composed by Paul Dresser
'Round my Indiana homesteads wave the cornfields,
In the distance loom the woodlands clear and cool.
Oftentimes my thoughts revert to scenes of childhood,
Where I first received my lessons, nature's school.
But one thing there is missing in the picture,
Without her face it seems so incomplete.
I long to see my mother in the doorway,
As she stood there years ago, her boy to greet.
[CHORUS]
Oh, the moonlight's fair tonight along the Wabash,
From the fields there comes the breath of newmown hay.
Through the sycamores the candle lights are gleaming,
On the banks of the Wabash, far away.
Many years have passed since I strolled by the river,
Arm in arm, with sweetheart Mary by my side,
It was there I tried to tell her that I loved her,
It was there I begged of her to be my bride.
Long years have passed since I strolled thro' there churchyard.
She's sleeping there, my angel, Mary dear,
I loved her, but she thought I didn't mean it,
Still I'd give my future were she only here.
Damn - Linus is like the super hero of the computer world. He's replaced our president as someone I look up to. The guy is really on top of what's right to make the best program. I'd love to spend a day with Linus just hanging out.
ZX2C4
From a theoretical standpoint Linus is absolutely correct: the more eyeballs, the faster the issue is fixed, so distribute it far and wide and as fast as you can.
From a practical standpoint, however, everyone would have to update their system the moment the fix is available, because the published issue is in the hands of the "bad guys", too. That is simply not going to happen in the real world.
The Right Thing(tm) is probably somewhere in-between, which is (as I perceive it) precisely what the industry is presently doing, for the most part. There may be (and probably should be) improvements to that model which should be made, but complete and immediadiate openness is at one extreme end of the spectrum just as gag orders and denial by proprietary software vendors are on the other.
--Udo.
As an administrator, having the exploit published is extremely helpful.
1) It allows me to test a system myself to see whether it is vulnerbale, especially in a case where I have a non-default setup or other security measures in place. I may also need to know whether non-linux systems may also be vulnerable and have simply not been reported yet.
2) It gives me thorough understanding of how the vulnerability works, how a successful or attempted exploit might show up in my logs, and just how much damage can be done. Is this a 'open a telnet window and start typing root commands' situation or is this an hours long process of unravelling layers of security? Should I be concerned by these attempted connections to port 183? Am I already compromised?
3) It gives me an opportunity to disable relevent kernel functionality or make a patch (even if just crudely hacking out a feature temporarily) myself if I really feel the need and, and this is the important part *test* the change to make sure the exploit is *actually blocked*.
Without the exploit published, I *cannot do these things*. Now, *Do I* do these things? Sometimes. I have to pick my battles and pay attention to the worst exploits against the most critical targets. A defense in depth allows me to do that and the *published exploit* gives me the information I need to decide.
Yeah right, because of his years of worldly experience and megabucks investment? Pardon me, but until Linus is personally, professionally, and financially responsible for "his" products installed at various personal and corporate sites, I don't think I'll be listening too closely to him.
My problem with this is that some people will interpret it as how quickly you can patch over the symptom, rather than how quickly you can correct the underlying problem. This will lead to "workarounds" being called "patches".
Personal experience shows that most bugs involve issues that might take a few days to resolve conflicts. "If I insert this fix here, does anything else break?"
Thank you. So the rest of us have to wait for either our support people, support contract personell, or an available replacement package update before we are once again "secure" knowing all the time that the knowledge is now out in the wild. This doesn't sound any better than closed source/proprietary software. So what if SOME of you can implement the fix, I suspect that's a small percentage of Linux users and given the goals of the OSS community, it will continue to be a smaller perecentage of Linux users as more neophites use Linux. This is good, how?
What if Alice and/or Bob are blackhat hackers themselves?
Just because it CAN be done, doesn't mean it should!
Simply to inform there is a typo in the original posting: "disclsoure" should read "disclosure"
What if someone discovers a security bug, and they are really responsible professional researchers, and they want to give all affected vendors some time to come up with an official solution? (researchers, not ppl into 0day exploits or cracking or whatever)
The way to do this is to have a multiple vendor coordinated release, where all agree on a date to release all together the alert and fix. This usually takes a few days, as most of them need to go through QA and other processes, as they are responsible to their customers.
SecurityFocus offers such a service for FREE to any researcher/vendor.
Blowing the whistle too early:
Even with that, there is always some a**hole or some idiot vendor breaking this blanket period. See how RH fsckd up this, many times, and got themselves up to the point of being told late. Some other linux groups also did this, by "mentioning" the bug to uncontrolled developers who went fixing on their own, thus blowing the whistle.
IF LINUS & CO LEAVE THIS COORDINATED SCHEMA, THEY'LL LOCK THEMSELVES OUT NOTIFICATIONS FROM RESPECTED RESEARCHERS.
NOTE1: i have nothing against the 0day or the cracking comunities, im only stating IF a researcher wants to give a blanket to vendors. (a very common case)
NOTE2: im not affiliated with SF, and even HATE the split bugtraq times for special vendors (i think this really killed it, a VV BAD move)
NOTE3: you might not agree with this schema, but consider most top name security firms follow it and it is to protect the users.
NOTE4: there is a defined period, so vendors are urged to come up with patch/alert
NOTE5: think also for the poor devs working for those vendors, making them work overnight hurried is not polite, they are devs like all of us
(im sure i miss some note and i'll get flamed anyway... flame on grrrrr)
I disagree with immediate, full disclosure. That is the perspective of a computer scientist.
I do believe in partial disclosure for a limited time, and then full disclosure. This time limit should be variable and discussed by the private community that has access to the report. The private community should respect this disclosure time limit.
The article does suggest something like this.
-- I was raised on the command line, bitch
Not that I agree with the grandparent, but Healthcare leaps to mind.
personally, professionally, and financially responsible for "his" products installed at various personal and corporate sites
You mean like, say, Microsoft? Riiiiight, they have done a much better job. They obviously care more about quality, security and the effects of their decisions on customer data in their software.
If the issues are 100% open, then 0% of the security comes from obscurity.
If 0% of the security comes from the ability of others to keep secrets (obscurity), then 100% of the security comes from my configuration, my password, my private key, etc.
Me controlling 100% of my security is a Good Thing.
+5, insightful
Nevermind arguments about fixing bugs (although I think Linus is right here too). The important thing is to NOT let kernel security issues be driven by vendors perceived needs. Give vendors that, and they will run wild. Security is a favorite bugaboo under which any change be justified - kudos to Linus for not letting this happen. If they want to form a secret cabal where they can keep secret any kernel security issues they know about - fine (but stupid), but don't try to tell everybody else you can't talk about these issues.
in security issues and in source code rights (SCO).
Linus lacks courage to be a leader. Lets not kid ourselves that lack of direction is about freedom.
http://www.us.xfce.org/archive/xfce-4.2.0/src/xfde sktop-4.2.0.tar.gz
Better that some boxes are fixed than all are vulnerable.
I'm really sick of all these comments by people that think stuff like this can magically be fixed instantly. Any bug requires time for analysis, coding, testing, etc. This applies to both Open and Closed source. Having a delay before the script kiddies here about this stuff, so that things can be fixed and send out, seems perfectly reasonable to me.
You could quit using Windows. :D
Please stop stalking me, bro.
"You should never depend on a single point of failure."
/can/ depend on.
/can/ break into locked cars, but you shouldn't leave these things to chance. See: multiple points of failure are much more dependable.
You're right - I always prefer multiple points of failure myself. They are just so much more likely to break down. That is something you
So, don't just leave your car door unlocked, also leave a window open - and your cash in full view (in case they can't find it in the glove box)... and a sign saying you'll be away for several hours. I know people
I am anarch of all I survey.
It looks to me as if instead of contacting the people that deal with it they tried to get to Linus, who may have ignored the email thinking that vendor-sec would have got it as well and would let him know if it's important. Linux is not a one man band. You don't contact the head of a multinational corporation to get a washer fixed in a third world hotel - even if it is going to flood the building and kill people - you call the plumber on the contact list you have been given and let them know how important it is, and maybe they can do something about it very quickly because they've handled the same thing a few times before.
> So the rest of us have to wait for either our support people, support contract personell, or an available replacement package update before we are once again "secure" knowing all the time that the knowledge is now out in the wild.
Yes, you can either be ignorant that you are waiting or wait with the knowledge.
> This doesn't sound any better than closed source/proprietary software.
Can your support personel fix bugs in gdi.exe ?
>So what if SOME of you can implement the fix, I suspect that's a small percentage of Linux users and given the goals of the OSS community, it will continue to be a smaller perecentage of Linux users as more neophites use Linux.
The goal of OSS is to be OPEN, with all that that entails.
> This is good, how?
If we pretend that one of the goals is commercial acceptance then it is better that when Amazon uses Linux they pay to have skilled staff who can search for and make fixes for stuff on zero day. If they play properly these fixes will be contributed. Serious companies will reduce their exposure to zero day exploits by having skilled people on hand. Thus the numer of skilled programmers contributing will increase. This is better for everyone and is the whole point of OSS and impossible with CSS
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
No. If we as a community are to say we are open source, then we should be open to criticism.