Slashdot Mirror
Slashback: Bindery, Locality, Gruviness
Why is there a lizard in my hard drive? chromatic writes: "The Protozilla team has responded to the earlier Slashdot article with answers to some common questions." This helps explain a lot of the questions raised in comments about why anyone would want or need to run CGI processes locally.Yet another win for documentation!
The ties that BIND make great cable-holders, too. fredpasteck writes: "LinuxSecurity.com has a FAQ from Paul Vixie that helps to explain some of the controversy and misunderstanding surrounding the ISCs creation of a 'members-only' mailing list. Perhaps the community was a bit quick in their assessment of what's going to happen?"
Do you feel reading Bugtrak makes it easier to talk to people? Speaking of BIND, to dispel any misconceptions which may have entered the minds of readers of this story (which cited the reaction of several Big Names to recent moves to restrict certain information about BIND), Kurt Seifried of Securityportal wrote to clarify:
I actually interviewed Vince/Theo/Dragos/Greg via phone/email seperately, they didn't post those things to Bugtraq. Although they are all Bugtraq users ... hehehehe. (that makes it sound like we're all shooting up heroin or something).Let it not be said that Bugtraq is a controlled substance.
Stop kicking, stop kicking! A nameless shirker writes: "More 'clarifications' from Linuxgruven CEO Matthew Porter can be found during a recent discussion on the Kansas Linux and Unix Users Association(KULUA) mailing list. His answers were very evasive to what were considered very straightforward (if direct) questions. The beginning of his involvement in the discussion can be found here with follow-ups linked from that message. Other discussion on this topic before and after Porter's response can be found near near the bottom of the following archive thread page.
Just wanted to make sure everyone could see how "clear" Porter makes things in his "responses" to the questions he is asked."
What is the purpose of the delay? To minimize the damage done by the vulnerability. Immediate disclosure means everyone's vulnerable until the news spreads, and even then, the only option is to disable the vulnerable program until a satisfactory fix is found (which is costly enough that many people will not disable it). Waiting until a fix is found still leaves people vulnerable while the news spreads, and subsequently while they evaluate the fix (a non-trivial task for critical systems), but it usually results in less overall harm. A logical next step is to inform, in confidence, the users most at risk prior to public disclosure. That, if we give them the benefit of the doubt, is all the ISC intends to do.
There are two problems with this strategy: It offends some people because it is inegalitarian and secretive; and the chance of a leak or independent discovery go up as the number of people in the know increases and time passes. If you hold an extreme version of the first position, you should argue that not even the program maintainers should get advance notice. This is a legitimate stance, but is by no means consensus among security researchers. Otherwise, you must admit that it's a trade-off, not a black-and-white issue.
Consider: Imagine you found a hole in a program you were using. Obviously, you would fix it locally before announcing it. Would you also get a review of your analysis from a trusted expert before disclosing? What if your friend were using it--would you tell him first? What if an organization you admire were at risk? It's a delicate balance.
I'm not defending Vixie's specific policy, I just want to point out it is not prima facie unreasonable.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
Maybe BIND sucks, but it's still got my vote for now. I'd buy Mr Vixie lunch if he was ever in the area.
proof, n. A demonstration that a conclusion is implied by certain premises and axioms.
Have a gander at djbdns. This is software done right people.
Instead of upgrading to the latest version of bind because of yet another security hole, I decided to switch. And I've been happy ever since.
I've been searching for an alternative forever and I still can't believe I hadn't come across djbdns until someone on Slashdot posted it. There must be others like me.
ISC is trying to make money, yes, but it is a non-profit organization. They need the money to keep the global DNS system working. I assume you want that.
The most important port of an Open Source organization is that the Source is Open, which it is in this case. They are allowed to have private discussions just like anyone else, but anything substantive that is done to the code as a result of these discussions will be available just as soon as they've fixed certain critical nameservers.
If it weren't for this slashback this would be another slashdot hall of shame entry.
Someone would pay to be on this mailing list because anyone who runs a critical nameserver, or has customers that do so with their software will find it essential, no question. THAT is all.
Chris Morgan
For example: the answer that referred to (paraphrased) "if anyone else's software runs on 80% of servers and is as dominant as ours, then we'll take a lesson from them" smacks horribly of arrogance. Nah, couldn't be that anything but the most widespread software would be the best, could it? *cough*Microsoft*cough*Sendmail*ehem* Just because your software is on more machines than others, doesn't mean it isn't "full of holes."
Basically, the ISC is closing off the information loop for its own benefit and leaving the little guys in the dust. I could understand this better if it were a purely commercial entity, but their purpose is to serve the community, not just an elite, specially chosen group who is willing (and able) to fork over the money to be in on the secrets. This is not right and that is exactly why the community is in an uproar.
Anybody who's thinking of migrating to BIND9: if you're going to retool for the new version anyway, just switch to something else. Save the headache in the long run.
"This message is composed of 100% recycled electrons."
Now, if a bug is found in BIND, do you really want every script kitty trying to make a name for himself to HACK ROOT on the ROOT NAMESERVERS for the ENTIRE INTERNET? Does this sound like a good plan to you? Wouldn't you rather, since the entire internet depends on them, that they get a chance to be patched up first?
I realize we're all in favor of open processes, but I think if anything this proves that in some situations they aren't appropriate.
As an example, have you ever left your front door unlocked? Would you prefer if someone told you personally, so you could fix it? Or would you rather they sent this information to the doorunlockedtraq mailing list to let you and everyone else know of the mistake you made, before you get a chance to fix it?
Ben Schumin :-)
Agreed; this is a problem, but for another reason as well: this eliminates a certain amount of liability for making mistakes.
Closed source software vendors are often more careless in the development of their products than open source vendors, knowing that there is less a chance that a vulnerability will become publicized (benefit of obscured code). The more public attention (via open mailing lists, open code, etc) there is, the more careful the programmers and QA teams must be, to avoid damaging their reputation (benefit of shared code/information).
I suspect this class division (trusted groups vs. the rest of the world) lessens the potential damage a serious security flaw could cause, which may in turn lower release quality.
--
All men are great
before declaring war
A government is a body of people notably ungoverned - AC