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?
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.
and this is it. I totally agree with his ideas and would prefer his solution -- total openness.
"Otherwise it just becomes politics..." -- Linus Torvalds
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:
Gates doesn't (didn't) code anything himself. The two do not compare.
The old Lie: Dulce et decorum est Pro patria mori
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."
correction: although he is guilty of many things, this isn't one of them. Apparantly (from a friend who [foolishly?] used to work for them, he always has, and still writes code on a daily basis. Presumably he doesn't write much any more, but thats still a loong way from never writing anything.
"Success is based on knowing how far to go in going too far"
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!
I got two things from the article that Linus would like to see happen:
1. Take the bs out about who knows about security vulnerabilities
2. If you make a patch, send it to kernel.org so they can release it. This is as opposed to just patching the kernel for the distro you're working on.
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.
When information about a security hole comes out it immediately begins dissemination in two different camps -- the white hats and the black hats. If dissemination is slower in the white hats than the black hats, it means that the black hats have a window of opportunity to compromise systems of people who would normally immediately patch. (why .... that would be me!)
Keep information dissemination free and open (fast) amongst the white hats and patches and workarounds will be available as fast as is possible.
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
So if I code, I'm trustworthy and if I don't I'm not trustworthy?
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
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.
Right.
I think that TFA features Linus also saying that he's in favour of the security thing being closed so as to allow people time to discuss the problem and to not have to drop everything to fix the problem that day.
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
Grr, then point us to that article where Gates said that security holes should be revealed immediately as they're discovered, and that you should rely on other mechanisms for a safe OS, and not secretly kept bugs. Or are you just making things up?
Beware: In C++, your friends can see your privates!
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?
I wish that all the OS's would put more of an emphasis on security . . . more like openbsd(well maybe not them. They hash everything). Microsoft and Linux are both insecure. I think what needs to be done for linux is that we need a site dedicated to handling security patches, etc. Then they could just access it all through this one website. It'd be better than a mailing list.
Actually, things are much worse than that.
If Gates says this, people think: "Ah, a Linux based firewall/router, to protect my MSWindows systems!"
Realistically, that's not a bad idea.
If Torvalds says this, people think: "what should I now protect my system with? A Linux firewall doesn't make sense..."
So there again MSWindows scores! With MSWindows, you can add Linux as an extra layer of protection, with Linux, it doesn't make sense!
1-0 for Win vs Lin!
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.
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!
You should read the original mail. Linus says he wants the fix to be published ASAP (or as he proposes, a maximum of 5 day delay of the fix).
The announcement of the security hole is a whole different issue and can be delayed as long as people want.
BTW, if you don't fix it immediately you are vulnarable and in trouble. The sooner a fix (a fix, not a announcement of a hole) is out the better.
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.
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.
It was Microsoft's marketing department that got them the proliferation they have now. It had less to do with their developers. Besides, didn't Gates admit to having learned a lot about how to program by reading people's trash?
When you can market a stale piece of beef jerky as if it was a filet mignon, you get market penetration.
I think IBM learned this lesson the hard way when they barely did anything with Warp 3. If they would've been smart, they would've had the SDK out for various companies to develop software to go along with the release, then they would've done a real advertising campaign. Warp 3 beat Win95 to market, was generally more stable, had the kinds of things business users wanted, etc. The primary problems were a lack of software and a lack of marketing prowess.
OCO is Loco
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).
The vendor should be subscribed to the same lists. We're all alone in this, together. It's their butts and their customers buts if a vendor doesn't keep up with the latest fixes in the kernel. I completely agree with Linus: there is no good reason for not disclosing everything as soon as possible. The system has worked in the past, and should be able to work in the future.
Well to be honest 99% of the patches are okay even if developed in 5 days. I think it needs even less time, considered two big advantages: there is the source and there is the documented exploit. 5 days should be more than enough for the best kernel hackers in the world to fix a hole which is most likely trivial to fix but was hard to spot. And anyway, they don't NEED to fix it in 5 days, they NEED to disclose information after 5 days.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
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
HMM, so only White Hats are coding fer ms1??
I not only doubt it, I know it aint so!
member the Halloween Docs??
01101101 01111001 00100000 01110011 01101001 01100111
Yeah, sure he writes code. Often referred as "bugs". They have to sell updates somehow haven't they?
/If you can't decide if its flamebait, troll or funny, don't moderate./
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
Why try what ya already got!!
I just hope they stay on their current line of fud and defimation, if they keep up the obvious lies, people *will* notice
01101101 01111001 00100000 01110011 01101001 01100111
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!"
Yeah, something to group all the distros and list the different vulinerabilities in one large site.
And then Joey the script kitten reads it, and then he instantly can hack 8 different distros, and not have to even try and stay up.
keep yer sys. patched and listen fer new bugs!!
kill the connection if it's bad enough and then patch it.
01101101 01111001 00100000 01110011 01101001 01100111
--
sigs sugs
so say we all
No, the idea is that they did try. They try and try until market dominance is theirs. Then they stop. When was the last time you've seen something truly innovative / awesome in a Microsoft product that completely dominates it's market?
I wish I could write clever and witty sigs.
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.
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?"
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.
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.
"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.