Free for All, Peter Wayner [my miracle luna book free read .TXT] 📗

make friends with less extreme folks who enjoy a Sunday ride down logging roads.

If you like cats, don't read what he had to say about his pets: "I own cats. Their names are Galileo and Kepler--they're still kittens. Kepler-the little bitch--can apparently teleport through walls. Galileo is a rather cool monster. When they become full-grown cats I will make stew & soup out of them. (Kepler is only good for soup)."

Throwaway comments like this have strange effects on the Net, where text is the only way people can communicate. There are no facial gestures or tonal clues to tell people someone is joking around, and some people don't have well-developed scanners for irony or sarcasm. Some love the sniping and baiting, while others just get annoyed. They can't let snide comments slide off their back. Eventually, the good gentlefolk who feel that personal kindness and politeness should still count for something in this world get annoyed and start trying to do something.

It's easy to see how this affected the NetBSD folks, who conduct their business in a much more proper way. Charles Hannum, for instance, refused to talk to me about the schism unless I promised that he would be able to review the parts of the book that mentioned NetBSD. He also suggested that forks weren't particularly interesting and shouldn't be part of the book. Others begged off the questions with more polite letters saying that the split happened a long time ago and wasn't worth talking about anymore. Some pointed out that most of the members of the current NetBSD team weren't even around when the split happened.

While their silence may be quite prudent and a better way to spend a life, it certainly didn't help me get both sides of the story. I pointed out that they wouldn't accept code into the NetBSD tree if the author demanded the right to review the final distribution. I said they could issue a statement or conduct the interview by e-mail. One argued that there was no great problem if a few paragraphs had to be deleted from the book in the end. I pointed out that I couldn't give the hundreds of people I spoke with veto power over the manuscript. It would be impossible to complete. The book wasn't being written by a committee. No one at NetBSD budged.

De Raadt, on the other hand, spoke quite freely with no preconditions or limitations. He still keeps a log file with a good number of email letters exchanged during the separation and makes it easy to read them on his personal website. That's about as open as you can get. The NetBSD folks who refused to talk to me, on the other hand, seemed intent on keeping control of the story. Their silence came from a different world than the website offering the phone number of the local pizza place as a hint. They were Dragnet; de Raadt was Politically Incorrect.

When the NetBSD folks decided to do something, they took away de Raadt's access to the source tree. He couldn't just poke around the code making changes as he went along. Well, he could poke around and make changes, but not to the official tree with the latest version. The project was open source, after all. He could download the latest release and start fiddling, but he couldn't make quasi-official decisions about what source was part of the latest official unreleased version.

De Raadt thought this was a real barrier to work. He couldn't view the latest version of the code because it was kept out of his view. He was stuck with the last release, which might be several months old. That put him at an extreme disadvantage because he might start working on a problem only to discover that someone had either fixed it or changed it.

Chris Demetriou found himself with the task of kicking de Raadt off of the team. His letter, which can still be found on the OpenBSD site, said that de Raadt's rough behavior and abusive messages had driven away people who might have contributed to the project. Demetriou also refused to talk about NetBSD unless he could review the sections of the book that contained his comments. He also threatened to take all possible action against anyone who even quoted his letters in a commercial book without his permission.

De Raadt collected this note from Demetriou and the firestorm that followed in a 300k file that he keeps on his website. The NetBSD core tried to be polite and firm, but the matter soon degenerated into a seven-month-long flame war. After some time, people started having meta-arguments, debating whether the real argument was more or less like the bickering of a husband and wife who happen to work at the same company. Husbands and wives should keep their personal fights out of the workplace, they argued. And so they bickered over whether de Raadt's nastygrams were part of his "job" or just part of his social time.

Through it all, de Raadt tried to get back his access to the source tree of NetBSD and the group tried to propose all sorts of mechanisms for making sure he was making a "positive" contribution and getting along with everyone. At one time, they offered him a letter to sign. These negotiations went nowhere, as de Raadt objected to being forced to make promises that other contributors didn't have to.

De Raadt wrote free software because he wanted to be free to make changes or write code the way he wanted to do it. If he had wanted to wear the happy-face of a positive contributor, he could have gotten a job at a corporation. Giving up the right to get in flame wars and speak at will may not be that much of a trade-off for normal people with fulltime jobs. Normal folks swallow their pride daily. Normal people don't joke about turning their cats into soup. But de Raadt figured it was like losing a bit of his humanity and signing up willingly for a set of manacles. It just wasn't livable.

The argument lasted months. De Raadt felt that he tried and tried to rejoin the project without giving away his honor. The core NetBSD team argued that they just wanted to make sure he would be positive. They wanted to make sure he wouldn't drive away perfectly good contributors with brash antics. No one ever gained any ground in the negotiations and in the end, de Raadt was gone.

The good news is that the fork didn't end badly. De Raadt decided he wasn't going to take the demotion. He just couldn't do good work if he had to run all of his changes by one of the team that kicked him off the project. It took too long to ask "Mother, may I?" to fix every little bug. If he was going to have to run his own tree, he might as well go whole hog and start his own version of BSD. He called it OpenBSD. It was going to be completely open. There were going to be relatively few controls on the members. If the NetBSD core ran its world like the Puritan villagers in a Nathaniel Hawthorne story, then de Raadt was going to run his like Club Med.

OpenBSD struggled for several months as de Raadt tried to attract more designers and coders to his project. It was a battle for popularity in many ways, not unlike high school. When the cliques split, everyone had to pick and choose. De Raadt had to get some folks in his camp if he was going to make some lemonade.

The inspiration came to de Raadt one day when he discovered that the flame war archive on his web page was missing a few letters. He says that someone broke into his machine and made a few subtle deletions. Someone who had an intimate knowledge of the NetBSD system. Someone who cared about the image portrayed by the raw emotions in the supposedly private letters.

He clarifies his comments to make it clear that he's not sure it was someone from the NetBSD core. "I never pursued it. If it happens, it's your own fault. It's not their fault," he said. Of course, the folks from NetBSD refused to discuss this matter or answer questions unless they could review the chapter.

This break-in gave him a focus. De Raadt looked at NetBSD and decided that it was too insecure. He gathered a group of like-minded people and began to comb the code for potential insecurities.

"About the same time, I got involved with a company that wrote a network security scanner. Three of the people over there started playing with the source tree and searching for security holes. We started finding problems all over the place, so we started a comprehensive security audit. We started from the beginning. Our task load increased massively. At one time, I had five pieces of paper on my desk full of things to look for," he said.

Security holes in operating systems are strange beasts that usually appear by mistake when the programmer makes an unfounded assumption. One of the best-known holes is the buffer overflow, which became famous in 1988 after Robert Morris, then a graduate student at Cornell, unleashed a program that used the loophole to bring several important parts of the Internet to a crawl.

In this case, the programmer creates a buffer to hold all of the information that someone on the net might send. Web browsers, for instance, send requests like "GET http://www.nytimes.com" to ask for the home page of the New York Times website. The programmer must set aside some chunk of memory to hold this request, usually a block that is about 512 bytes long. The programmer chooses an amount that should be more than enough for all requests, including the strangest and most complicated.

Before the attack became well known, programmers would often ignore the length of the request and assume that 512 bytes was more than enough for anything. Who would ever type a URL that long?

Who had an e-mail address that long? Attackers soon figured out that they could send more than 512 bytes and started writing over the rest of the computer's memory. The program would dutifully take in 100,000 bytes and keep writing it to memory. An attacker could download any software and start it running. And attackers did this.

De Raadt and many others started combing the code for loopholes. They made sure every program that used a buffer included a bit of code that would check to ensure that no hacker was trying to sneak in more than the buffer could hold. They checked thousands of other possibilities. Every line was checked and changes were made even if there was no practical way for someone to get at the potential hole. Many buffers, for instance, only accept information from the person sitting at the terminal. The OpenBSD folks changed them, too.

This audit began soon after the fork in 1995 and continues to this day. Most of the major work is done and the group likes to brag that they haven't had a hole that could be exploited remotely to gain root access in over two years. The latest logo boasts the tag line "Sending kiddies to /dev/null since 1995." That is, any attacker is going to go nowhere with OpenBSD because all of the extra information from the attacks would be routed to /dev/null, a UNIX conceit for being erased, ignored, and forgotten.

The OpenBSD fork is a good example of how bad political battles can end up solving some important technical problems. Everyone fretted and worried when de Raadt announced that he was forking the BSD world one more time. This would further dilute the resources and sow confusion among users. The concentration on security, however, gave OpenBSD a