The Fedora-Red Hat Crisis 263
jammag writes "When Linux journalist Bruce Byfield tried to dig for details about the security breach in Fedora's servers, a Red Hat publicist told him the official statement — written in non-informative corporate-speak — was all he would get. In the wake of Red Hat's tight-lipped handling of the breach, even Fedora's board was unhappy, as Byfield details. He concludes: 'If Red Hat, one of the epitomes of a successful FOSS-based business, can ignore FOSS when to do so is corporately convenient, then what chance do we have that other companies — especially publicly-traded ones — will act any better?'"
Consider Red Hat's response vs. Debian's (Score:5, Insightful)
The problem with a lot of corporate Open Source is that they ignore the ethical foundation of Open Source. And eventually we find out that Open Source isn't quite as good without the ethics.
Bruce
The real world is a bit different than that. (Score:2, Insightful)
They have to buy people's trust again now with their actions, and it's going to take years, if they even do it.
Re:welcome to the world (Score:4, Insightful)
It's happened numerous times. Consider the Bruce's comment regarding Debian above.
Frankly "a real business situation" sounds a lot like a metaphor for covering your ass at other people's expense.
Re:welcome to the world (Score:5, Insightful)
Does this justify the word "crisis?" (Score:5, Insightful)
Does this justify the word "crisis?" I doubt it does. In my opinion "conundrum" would be a better word.
At first read, the heading made me think that Red Hat and Fedora communities were bickering big time, threatening timely releases of software we have [all] come to rely on. Of course this is not the case.
So why the sensational heading?
gotta say, this is BAD (Score:3, Insightful)
I used to be 100% redhat and fedora... Now I've moved almost all my systems to ubuntu, but I still run centos on a few servers.
Every reputable tech company I deal with (ISP, Software, Hosting, Colo) has very clear, very open policies about outages, breaches, and security in general. If they don't I don't do business with them.
I know the ins and outs of my ISP, Hosting, and Colo companies processes because I get emailed whenever I have an outage that says "we experienced an outage from x-y on day z, the outage was caused by our dumb admin who tripped on the power cable, we rewired our entire data center to move all of the power cables to the ceiling to prevent a similar outage in the future".
Obviously that is a made up report, but it is extremely standard practice to let all your customers know a) when the problem happened, b) what caused the problem, c) concrete steps taken or procedures implemented to prevent similar problems in the future
That RedHat has fallen so miserably short of this basic tenet of IT procedures is extremely scary.
Re:Consider Red Hat's response vs. Debian's (Score:4, Insightful)
Bruse Byfield is a troll. So why debate his accusations?
Yes, there are many problems: patents [stopsoftwarepatents.org], open standards, dmca restrictions and so forth. But open source is still the best of all worlds.
RedHat as a company applies the usual tactics but as a community member gives a lot. Sure corporations are vulnerable to money. Novell is a good example...
Re:Consider Red Hat's response vs. Debian's (Score:3, Insightful)
I pretty much agree: Fedora was obviously squelched by Red Hat corporate who was apparently afraid of the reaction of their paying customers///////////// shareholders. Despite the token board openings and motions about openness, after this nobody can pretend that Fedora is on anything but a *very* short leash held by Red Hat.
As they say on that snarky message board across town, fixed it for ya.
As a publicly traded company, Red Hat's primary responsibility is to produce a profit for its shareholders. That is the law. If the officers of the company do anything which interferes with that solemn legal duty, they risk lawsuits, and even jail time for breach of fiduciary responsibility.
If an overly open disclosure policy is perceived to affect future sales or the value of the brand (i.e. "goodwill"), legal will tell them to say nothing unless they are breaking a bigger law (i.e. gross negligence) by saying nothing.
It's strange, but it makes money, which the law says is the only thing that matters.
Re:Press Releases... (Score:4, Insightful)
Yeah, but that is the techie paranoia.
Just because something can be done doesn't mean it actually happens. If I go to holidays and leave the door of my house open, it does not mean that something actually happens.
The point is, Red Hat signs their packages. If their signing mechanism has been compromised, it is quite conceivable that every single Red Hat package is untrustworthy.... you must throw out all Red Hat packages on your system, because any could be compromised.
Nonsense. Why should you "trust" RedHat Packages signed by employees?
The whole signing shit is a troll for the privacy church. What they forget are the proportions and what is really important. We know exactly that the problem didn't affect us in the past and it won't affect us in the future now we found out. No need to panic.
Re:Consider Red Hat's response vs. Debian's (Score:4, Insightful)
The jury must be very patient, indeed (Score:5, Insightful)
I would have phrased it differently: The issue isn't fully known, thus there's a problem.
There's been quite a lot of time.
Re:Consider Red Hat's response vs. Debian's (Score:4, Insightful)
So what exactly is Red Hat hiding? (Score:5, Insightful)
OK, some servers got hacked, the attackers didn't inject rogue packages into the repository servers so no customers/users were affected. Red Hat/Fedora responded by auditing everything and releasing a statement [redhat.com], along with tools [redhat.com] to detect packages with the attackers' signature. Big deal.
Seriously, what else is there to be known about it?
Yeah, say whatever you want, but it's not as if Debian never [debian.org] had [debian.org] its servers compromised in a similar fashion, and never had to perform some PR damage control.
Unlike Debian, Red Hat is a publicly traded company with a whole bunch of customers with signed SLAs. Handling such matters without press trolls all rolling over it spreading FUD and causing unnecessary panic is _not_ an easy task, as can be beautifully shown by TFA.
I respectfully disagree with Bruce Perens. The Debian OpenSSL fiasco was so much more serious, damaging and dangerous to users all over the world, it's not even fair to compare. We're talking about millions of known networks and sessions compromised in Debian over a year and a half period, versus none in Red Hat over a week.
I appreciate how Debian acted _after_ the fact, but was there any other way to handle such a terrible mishap?
This is not about flawed Open Source policies, this is about seriously flawed journalism, where conspiracy theories are used to make a story where there is none.
Re:gotta say, this is BAD (Score:5, Insightful)
You're very trusting with all that money. Someone else in the same situation might truthfully report: my vendor is keeping me the dark, I don't know the nature and degree of my own exposure.
This would make me nervous.
It ain't over yet (Score:3, Insightful)
Well yes. (Score:2, Insightful)
But they already know what happened.
You would expect they disclose what went wrong, that would save time and money to everybody.
Now, how can anybody running a Red Hat system know it is safe?
Openness is an advantage over closed systems, and it is why many of us buy from companies that are more open, in all the senses of the world.
Losing sight of what makes them different, and thus desirable, is a recipe for financial trouble (their lawyers will be paid in any way, so they should actually use them to ensure maximum disclosure).
Re:Consider Red Hat's response vs. Debian's (Score:1, Insightful)
As a publicly traded company, Red Hat's primary responsibility is to produce a profit for its shareholders. That is the law. If the officers of the company do anything which interferes with that solemn legal duty, they risk lawsuits, and even jail time for breach of fiduciary responsibility.
But nowhere does it say that it has to be short term profit at the cost of anything else, although CEOs and their ilk appear to understand it that way, since that is the way they themselves profit the most.
Re:Consider Red Hat's response vs. Debian's (Score:5, Insightful)
Unfortunately, that uncovered something perhaps more serious at the heart of Debian. Stop hacking on stuff downstream that you don't have any real idea about and that will only affect you if it blows up. The SSL thing has been a disaster waiting to happen, and it will probably happen again.
Re:You can rebuild everything from a known base. (Score:3, Insightful)
Well, gee. Thanks for explaining the meaning of "bootstrapping" to me.
The problem is: when can you consider a compiler "clean"? The only way to be sure is to develop it yourself in machine language (no, you can't even use an assembler, because it could generate a backdoor, too), or to fully scrutinize the machine language of an existing compiler binary.
In practice, if you are using gcc, you have a compiler that has been recompiled by itself over and over again for at least a decade. Can you be absolutely sure that there wasn't somebody somewhere in that chain who added some malicious code that has propagated on? Not unless you audit the machine code of a specific gcc binary. The most likely party to have performed such an audit would be the NSA, but I am not sure I would trust them if they report there is no backdoor (in fact, they are pretty high on the list of who might want to plant a backdoor to begin with).
Re:Press Releases... (Score:5, Insightful)
Nice try. The problem with Techies is that they don't get the larger picture. They focus on the blinking red herrings they are so used to and where they believe in.
We are talking about a serious flaw of a security model. True. But consider that most people run operating systems where executables are not signed at all.
There is no indication here at all that anyone externally found out about the problem before. It is basically that you found out that what you did over the last two years was vulnerable to potential attacks. How will it affect the future? Not at all, as the issue gets fixed.
Ah, and right now no one unauthorised actually has the key yet. It is only technically possible to crack it much easier...
No.Consider Red Hat's legal position vs. Debian's (Score:1, Insightful)
I think that is sufficiently clear, that there were legal concerns, that Red Hat has certain responsibilities and so it *has* to get Fedora to cooperate, and lawyers are naturally going to ask people to behave responsibly and in harmony with certain known best practices. That's not anti FOSS. It's anti STUPID.
Debian... well, who is tempted to sue them? Red Hat, with deep pockets, is a target. It's apples and oranges. Byfield betrays his bias, which is Novell, good; everyone else, bad. And he shows he missed the actual answer to the why question. Bias works like that. You can't see the forest because you already have mapped out the trees you like to get where you plan to end up. Without the bias, he might have noticed those phrases and if he doesn't understand the law, he could have inquired. When you want to bad mouth someone, it's cheap and easy to do it, but it leaves a bad taste in the mouth of your readers.
Re:Press Releases... (Score:3, Insightful)
Sorry but
Company has a problem with a server breach - no publicity, no comment - note even a hint
FOSS project - We're busy go away ...
Fedora - We have a problem we're sorting it out, we'll let you know when we know, the Server is Red Hat's and they have the same problem so they are dealing with it ....
Looks fair enough to me ....
Re:Consider Red Hat's response vs. Debian's (Score:3, Insightful)
Slashdot became ever so slightly less egalitarian that day, when 'UID cred' became something touted right up on the header of each comment.
So here's a long belated: Thanks, Bruce.
Like we about the opinion of a seven-digiter...
Re:Consider Red Hat's response vs. Debian's (Score:4, Insightful)
That is ridiculous. The law does certainly not say that making money is the only thing that matters.
i agree that it's ridiculous. it is however true.
http://en.wikipedia.org/wiki/Dodge_v._Ford_Motor_Company [wikipedia.org]
GP is right and you are wrong. Among non-experts, conventional wisdom holds that corporate law requires boards of directors to maximize shareholder wealth. This common but mistaken belief is almost invariably supported by reference to the Michigan Supreme Court's 1919 opinion in Dodge v. Ford Motor Co. [businessas...nsblog.com]
Re:Consider Red Hat's response vs. Debian's (Score:3, Insightful)
Technically speaking, there isn't any law that says they have to maximize profits, it's a fiduciary responsibility, for which they could incur civil liability, and/or lose their jobs. They wouldn't be breaking any law to take action in favor of the users/customers/third parties, but the Board of Directors might choose to end their employment for doing so. Or not.
Top level management has a lot of freedom in acting in the interests of the company. The main control is the Board of Directors removing them from management if the board disagrees with the approach.
Re:The real world is a bit different than that. (Score:3, Insightful)
Less than full disclosure is a problem because when you trust people, you place more potential points of failure in your security system than when you can verify something on your own. Real security does not trust, they check everything.
The problem is made worse by the fact that some people have all of the information. People in Red Hat and Fedora, and some customers that they've told under NDA, and whoever the perpetrator told. Those folks all have power over your system, potentially, that you would not want them to have.
Read Schneiner, he's a good independent source on this.
And if you please, "zealot" isn't polite. We all have our own beliefs, you same as I, for what we percieve to be good reasons.
Bruce
I have a referencing trusting trust rule (Score:3, Insightful)
Anyone who mentions Ken Thompson's Reflections on Trusting Trust [bell-labs.com]should also mention David A. Wheeler's "Countering Trusting Trust" [dwheeler.com]. Those who don't should be punished by having to argue both sides of the debate.
I occasionally post the counter argument [slashdot.org] in a reply but no one sees it... Next time you see someone else with this behaviour tr, here's ammo for countering it.
(I believe the gcc rebuilds aren't so much to remove this type of intentional bugging but rather ensure the final binary is free from things like first compilation optimisation issues... Comparing the compiler binaries would probably indicate differences due to things like dates being present BUT hopefully what they would output on a given source would be the same)
Re:Press Releases... (Score:4, Insightful)
And if the original compiler was gcc, and trojaned in the way the paper describes, then the triple compilation wouldn't catch it. Why? Step 1: the existing compiler builds binary 1 and inserts the backdoor. Step 2: Binary 1 builds binary 2 and inserts the backdoor. Step 3: Binary 2 builds binary 3 and inserts the backdoor. Step 4: binary 2 and binary 3 are compared, and if they are different, then there is an error. However, since all versions have the backdoor, there is no difference, and no error will be flagged. Try reading the linked article again.
The triple compilation is not for detecting trojans, but "because the compiler will be tested more completely and could also have better performance." [gnu.org]