Slashdot Mirror
Theo de Raadt gets 2004 FSF Award
Caligari writes "Richard Stallman, presents this year's award to Theo de Raadt.
"For recognition as founder and project leader of the OpenBSD and OpenSSH projects. Theo de Raadt's work has also led to significant contributions to GNU/Linux and other BSD distributions. Of particular note is Theo's work on OpenSSH. Theo's leadership of OpenBSD, his selfless commitment to Free Software and his advancement of network security, were cited by this year's award committee.""
Not only from a pure lines-of-code point-of-view, but also by the way the OpenBSD-project scrutinizes licenses and pushes security and cryptography forward every day.
Congratulations, Theo - keep on fighting !
Windows 2000 - from the guys who brought us edlin
Imagine a world without the networking Swiss Army knife that is ssh.
OpenBSD is a totally underrated OS too. Even if it is a bit slow, its packet filter actually works.
I use Linux every day, and appreciate the fact that I have a good method to connect to my servers in a secure manner, thanks to Theo.
And I want to thank him for his other contributions, as it has made me some good cash, installing BSD boxes in front of Windows email servers with packet filtering!
Again Thanks Theo. I wish this type of stuff could reach more mainstream news, but we can all know just like other major happenings in the world, there is a army of unsung heros who make things happen.
Unlikely. The BSD people are actively working to replace every GNU utility still in the system with a BSD-licensed version - look at the changelogs for OpenBSD, for example, and you'll occasionally see an entry mentioning that this or that has been replaced.
quidquid latine dictum sit altum videtur.
Actually the differences in ideology between the GNU and BSD developers are more in the outlook and means than any other thing. Free software is free software for both camps, and most sane people in both sides shares a common idea of what free software is. The licences, that are generally the main difference between the two, try to achieve an end using different approaches, but all in all both GNU and BSD people are great contributors to a common free software community. The noise many times created is more on the "newly convert" section of each side :).
It's IMHO rather silly to watch the flame wars between the GNU/Linux and *BSD sides when there is so much more that unites us than what divides us. This award make perfect sense. In the end a gnu, a penguin and a daemon can sometimes be noisy neighbourghs, but in the end they stick together to defend their building. Shitty alegory, I know, eh.
cheers,
fsmunoz
If you had any kind of clue about the way `proactive security' works, you wouldn't write such drivel.
Why is OpenBSD called OpenBSD ? because it was the first BSD to make its CVS tree accessible for everyone. That's right, anyone can subscribe to source-changes and see the commit messages. And anyone can get the sources.
Now, most security fixes are NOT tagged as security fixes. They're tagged as clean-up, or reliability issues, or normal bug-fixes.
Why is this so ?
Quite simply, because those fixes are done while reading the code, NOT in reaction to a security hole.
That's what `proactive security' means. When you find something fishy, you just go and fix it, you don't sit on your fat ass and wait for months until someone finds a way to exploit it.
As a result, OpenBSD is more secure than most other OSes out there. Not because of cool technology like ProPolice or W^X, but simply because of good engineering practices.
OpenBSD doesn't have the latest cool feature. It's never been about that. But it has obsessive-compulsive developers who care about security.
Security is not a plug-in. It's not something you add to a distribution after you've put in all the carelessly designed and dangerous features.
Security is a process.
Security is a state of mind.
Security is a priority: either you put it right there, in front of you, and FIX THINGS when you think they might get broken, or... you will run into actual nasty holes, and make the front page of bugtraq.
You still don't know what you are talking about.
Yes, most bugs we fix have some kind of security relevance. This is obvious. Now, are we going to tag each single entry we commit with `possible security fix' ? Are we going to spend a lot of time convincing other people this might be relevant ?
Nope, we are not.
We tried. This is simply a waste of time. It doesn't work. A lot of other projects don't have a clue. You tell them that what you're doing might be security-related, and you waste hours explaining the issue to them.
Think about it. Every time you simplify a piece of code, or replace an obfuscated algorithm with something simpler, you ARE handling security issues... or you might be. That's not important.
You are not going to waste time figuring out whether that fix is an actual security fix, or just some clean-up.
Because you can use the same amount of time fixing other issues, and that's more useful.
Want actual proof ? Look at all the changes in OpenBSD that replaced strcpy/strcat with strlcpy/strlcat. Now, go out on the linux lists, and ask why strlcpy still isn't a part of the glibc, but strfry is. Or look for comments on the above subject from Ulrich Drepper.
Make up your own mind.
Who do you think has a clue ?
The people who found out countless potential buffer overflows all over the place, fixed these, and still find that new code has the same mistakes and buffer overflows ?
Or the people who think that strlcpy is irrelevant because good programmers don't write buffer overflows ?
You could also look at tmpnam and mkstemp, and countless other examples.
As another instance, look at chroot and privilege separation. In many cases, the added safety translates to less features (like, a chroot'ed daemon that can no longer read its configuration file on a kill -HUP, or an http server that needs a whole set of libraries to run cgi). Bottomline, do you want the extra features, or the added security.
Most time, there is a trade. Those security fixes rely on non-portable parts of the libc. In many cases, third party software will buy back the extra stuff (look at rsync, kde and strlcpy), but this takes time...
try to do some development work, instead of posting opiniated, clueless comments on slashdot. Spend some time fixing security issues. See your patches take months to get accepted upstream. See the next release still have the bug, because some clueless, feature-conscious developer added some code with the exact same wrong pattern in another area than the one you've been fixing...
If you choose to distribute BSD licensed code, your stuff doesn't become less free because you chose to allow those distribution terms. You are only a 'prisoner,' as you said, of your own right to choose how to distribute some code. The GPL has numerous restrictions placed upon how you can use GPL software that the BSD license doesn't, therefore it grants far more freedom to everyone. The GPL is not a magic bullet and is not suitable for all situations, and simply having a 500 page license behind your software does not make it any better then anything else or guarantee that it will 'out evolve' anything else.
BTW, care to explain how MS locks me in by using BSD code that I can go and pick up just about anywhere else.
"I use a Mac because I'm just better than you are."
I've been personally involved with all these technologies. In my shop, we run two OpenBSD firewalls, one on each available broadband service. Our automated build system is based on SCons, and our scripts make heavy use of rsync internally. Our embedded surveillance project runs Linux which we compile in a chroot build environment along the lines of scratchbox (but scratchbox didn't exist when we started). We also have an ARM7 microcontroller in our product running on top of the GNU tools compilation environment, with some structural similarities to eCos/Redboot. Have I missed anyone?
I have a coworker here educated at the U. of Calgary (where I grew up myself) who knows (but does not enjoy) Theo through overlapping social circles. We had a short debate just a few weeks ago over a spicy Sichuan lunch special about where the boundaries between competence and personality belong. My coworker suggested "couldn't he accomplish as much without pissing people off?" I countered, "for someone with a knack for pissing people off, he retains some of the smartest out there within his circle. How does he do that?" There's a line I once read in Drucker that I've taken to heart "you're not in business to win friends". For me, the bottom line is that Theo delivers, and I admire the end results of his zealous rigour (regardless of where one might choose to draw the line between those qualities).
Before I became involved in this shop, I studied computational linguistics, which brought me into contact with just about everything in the area from which rsync originated. I was depressed that Tridge had to lose the award he deserves as much (well, almost as much, although it pains me to say it).
I've read all the benchmarks over the past year that show how OpenBSD is as slow as a senile dog. Whatever. For the purpose we employ those boxes, we've never had an iota of concern over performance level except for the negotiation phase on https. Guess what? Once Via/IBM finally coughs up the C7 Esther, OpenBSD running on a steroid enhanced 486 will crush the most expensive present day Pentium IV on our most essential performance metric.
The odd thing about OpenBSD, which many people never manage to assimilate, is that you have to look at that project through a very narrow gun turret to realize just how much they accomplish by entirely ignoring the whingings from everyone else.
It's an odd day in my personal universe to see RMS pat Theo on the back. I guess it takes one to know one after all.
At the end of the day, OpenBSD was created because Theo couldn't get along with the other 'first-tier' NetBSD developers, and didn't want to be a 'second-tier' developer.
Or you could phrase this as
At the end of the day, OpenBSD was created because the 'first-tier' NetBSD developers used access controls to try and enforce social policy and Theo refused to be extorted.
This whole thing cuts both ways.
As long as both sides keep improving their tools in order to convince people to switch, the user can only benefit from this.
quidquid latine dictum sit altum videtur.
You can't get hold of the propietary, extended code for windows networking to fix the operatability problem without NDA etc. You can only guess the BSD code up to the moment of forking. After the fork point, the code has been tweaked and closed and used to build a system that tries to lock you in forever after. That's the kind of danger the GPL protects you against.
If Microsoft does not use the code, they invent their own protocol. When Microsoft uses BSD code as a basis, they are at least easier to guess or work around. How long has it taken the people working on Samba to under all of the SMB protocol? Many years at least. Even Stallman has said the BSD license is good for standards.
BTW, the network stack in Windows has not been based on the BSD code for years.
The restriction of GPL protects the coders in the long run.
Protects coders from what? For example, when Microsoft embraces and extends a protocol (i.e., Kerberos, DNS, DHCP), they have no need for the source. They break the protocol. The GPL nor any other open source license would have power against that. You would need a patent (yuck).
The freedom of BSD can restrict the coders in the long run.
This is never true. I never need to use a proprietary vesion of open source. Which version of Kerberos do you use? With BSD-licensed code, I have very few restrictions placed upon me as a coder. Fewer than using GPL-licensed code.