Slashdot Mirror

The story points to plus46.html which isn't useful for a general distribution announcement like this. Here's a much better choice (which includes a link to the plus46.html page):

http://www.openbsd.org/46.html

or

http://www.sigmasoft.com/~openbsd/archives/html/openbsd-announce/2009-10/msg00001.html

for the record, i submitted it with different links. plus46.html was originally linked from the text "and lots more." they "improved" the links in the story before they published it.

The story points to plus46.html which isn't useful for a general distribution announcement like this. Here's a much better choice (which includes a link to the plus46.html page):

http://www.openbsd.org/46.html

or

http://www.sigmasoft.com/~openbsd/archives/html/openbsd-announce/2009-10/msg00001.html

I had an employer many moons ago who manufactures PC-add-on boards such as RAID controllers
[...]
because a bigger competitors could take that knowledge and turn it into a less expensive product
[...]
there were features designed into the hardware ASIC's that should have worked, but didn't.
[...]
the company was unwilling to disclose that there were embarrassing design flaws in their hardware, a perception that could have ruined them

Sounds like your bigger competitor could have been Adaptec. I guess they used the same ASICs. Was the 'race' about circumventing non-functional parts of RAID-controllers ?

http://hardware.slashdot.org/article.pl?sid=05/03/20/1944233
http://marc.info/?l=openbsd-misc&m=111118558813932
http://www.sigmasoft.com/~openbsd/archives/html/openbsd-misc/2005-03/msg01362.html

I'd say.. avoid like the plague

Here's the direct link about the AAC driver mentioned in the story.

For anyone who hasn't read the mail threads here. The much maligned ex-Adaptec employee here, is actually Scott Long the maintaner/developer of Adaptec support in FreeBSD. His addmission of the buggy nature of adaptec hardware is actually an offer of help from another BSD developer. Which was very rudley declined. Some people really need to grow up.

For anyone who hasn't read the mail threads here. The much maligned ex-Adaptec employee here, is actually Scott Long the maintaner/developer of Adaptec support in FreeBSD. His addmission of the buggy nature of adaptec hardware is actually an offer of help from another BSD developer. Which was very rudley declined. Some people really need to grow up.

From this piece (linked to from the post):

"...and though we would like to support "all" of the various flavors of these new operating systems..." (emphasis mine)

The first release of the Linux kernel was in, what, 1992? OpenBSD has been around for how long? NetBSD has been around for how long? Debian has been around for how long? Red Hat has been around for how long?

Windows XP (released 2002?) is "newer" than any of the "major" Linux-based or BSD-based operating systems. The mental midget who wrote this piece referred to "[OpenBSD] as well as many other flavors of Linux/Unix" as "new operating systems" (his words), implying that Unix itself is a "new" thing. Reminder: Unix has been around since 1969; Win32 systems have been around since... what, 1993?

With such a PHB-style, Windows-centric philosophy, is it any wonder these guys are basically dodging all requests for help or support?

The author of ipf (Darren Reed) is regularly on the openbsd mailing lists, and quite often it's just gripe. This whole issue has become quite personal, jugding from the posts.

Back on topic, this post by Darren is particularly amusing:

To: deraadt@cvs.openbsd.org (Theo de Raadt)
Subject: Re: OpenBSD 3.6
From: Darren Reed <avalon@caligula.anu.edu.au>
Date: Wed, 29 Sep 2004 12:14:38 +1000 (Australia/ACT)
Cc: misc@openbsd.org

Hey wow, I just got told that I get a mention in the lyrics :)
Thanks :)

That's almost enough to tempt me into buying my 1st ever CD :)

Not everyone gets immortalised (for better or worse) into song
so thanks :)

I don't know what is such a mystery to you.

They explain their philosophy, the source to their patches, the change logs, access to their bug tracking, and mailing list archives.

It is all linked from the front pages. What is so hard to figure out?

If Win2k gets a higher rating than Linux, then why do we have stuff like this happening?

Isn't it odd that a "comprehensive security rating" can overlook something as serious as a complete remote compromise?

EAL4 - methodically designed, tested and reviewed

EAL4 permits a developer to maximize assurance gained from positive security engineering based on good commercial development practices. Although rigorous, these practices do not require substantial specialist knowledge, skills, and other resources. EAL4 is the highest level at which it is likely to be economically feasible to retrofit to an existing product line. It is applicable in those circumstances where developers or users require a moderate to high level of independently assured security in conventional commodity TOEs, and are prepared to incur additional security-specific engineering costs.

An EAL4 evaluation provides an analysis supported by the low-level design of the modules of the TOE, and a subset of the implementation. Testing is supported by an independent search for vulnerabilities. Development controls are supported by a life-cycle model, identification of tools, and automated configuration management.

If Win2k gets a higher rating than Linux, then why do we have stuff like this happening?

Isn't it odd that a "comprehensive security rating" can overlook something as serious as a complete remote compromise?

EAL4 - methodically designed, tested and reviewed

EAL4 permits a developer to maximize assurance gained from positive security engineering based on good commercial development practices. Although rigorous, these practices do not require substantial specialist knowledge, skills, and other resources. EAL4 is the highest level at which it is likely to be economically feasible to retrofit to an existing product line. It is applicable in those circumstances where developers or users require a moderate to high level of independently assured security in conventional commodity TOEs, and are prepared to incur additional security-specific engineering costs.

An EAL4 evaluation provides an analysis supported by the low-level design of the modules of the TOE, and a subset of the implementation. Testing is supported by an independent search for vulnerabilities. Development controls are supported by a life-cycle model, identification of tools, and automated configuration management.

Rather then acting like adults Theo and others make personal attacks, against projects, against persons etc.

WTF are you talking about! Did you even bother to read the thread? Of course not, you're a slashdot reader. No slashdot reader ever bothers to inform themselves.

Here is what Theo said: "I'm now going to step aside and let our user community decide how do deal with such copyright violations."

This was the post that started it all. Doesn't sound like personal attacks to me. In fact, the only personal attacks I can find were attacks on Theo.

From everything I have seen all the BSD projects seem to simply be full of arrogant babies.

Relatively speaking, everyone is an "arrogant baby" to someone else. No operating system is free from this. Certainly Linux, Windows and Mac fans are not free from this trait.

I think Linux users should clean up their own interdistro arrogancy and ad-hominem attacks before they commence with dispensing Good Housekeeping tips to other free operating system projects.

but unlike djb, the mplayer group utilizes the standard GPL license (probably because they were too lazy to write their own crazy license) and seems to think they can utilize the GPL as a shield for protection of their illegal software.

in short, this isn't the first case of killer-app type software that is written by immature and/or wacky authors with questionable licensing terms (bitchx, qmail/djbdns, glftpd, vision-x, etc.)

if anything, their messages to debian-devel and the retalliatory flames are certainly entertaining reading.

SMP is a big deal. OpenBSD does things, and it does them RIGHT. To do SMP right, we'd need to make the kernel fully-reentrant. This means that we'd clean up the kernel I/O functions so that they don't wait on one another (that's a really dumbed-down, bad explanation of it.) By making the kernel re-entrant, we wouldn't have the problem of spinlocks (one processor waiting on the other to finish I/O, etc.) This would mean almost a COMPLETE re-write of the kernel. This would be a six+ month ordeal for quite a few coders working 40-60 hour weeks. Remember, such a huge task needs to include not only the re-writing of existing code, but checking it to make sure it works on all supported platforms without breaking all the great existing features of OpenBSD.

SMP is a big deal. OpenBSD does things, and it does them RIGHT. To do SMP right, we'd need to make the kernel fully-reentrant. This means that we'd clean up the kernel I/O functions so that they don't wait on one another (that's a really dumbed-down, bad explanation of it.) By making the kernel re-entrant, we wouldn't have the problem of spinlocks (one processor waiting on the other to finish I/O, etc.) This would mean almost a COMPLETE re-write of the kernel. This would be a six+ month ordeal for quite a few coders working 40-60 hour weeks. Remember, such a huge task needs to include not only the re-writing of existing code, but checking it to make sure it works on all supported platforms without breaking all the great existing features of OpenBSD.

SMP is a big deal. OpenBSD does things, and it does them RIGHT. To do SMP right, we'd need to make the kernel fully-reentrant. This means that we'd clean up the kernel I/O functions so that they don't wait on one another (that's a really dumbed-down, bad explanation of it.) By making the kernel re-entrant, we wouldn't have the problem of spinlocks (one processor waiting on the other to finish I/O, etc.) This would mean almost a COMPLETE re-write of the kernel. This would be a six+ month ordeal for quite a few coders working 40-60 hour weeks. Remember, such a huge task needs to include not only the re-writing of existing code, but checking it to make sure it works on all supported platforms without breaking all the great existing features of OpenBSD.

SMP is a big deal. OpenBSD does things, and it does them RIGHT. To do SMP right, we'd need to make the kernel fully-reentrant. This means that we'd clean up the kernel I/O functions so that they don't wait on one another (that's a really dumbed-down, bad explanation of it.) By making the kernel re-entrant, we wouldn't have the problem of spinlocks (one processor waiting on the other to finish I/O, etc.) This would mean almost a COMPLETE re-write of the kernel. This would be a six+ month ordeal for quite a few coders working 40-60 hour weeks. Remember, such a huge task needs to include not only the re-writing of existing code, but checking it to make sure it works on all supported platforms without breaking all the great existing features of OpenBSD.

Answer: OpenBSD See subsection 6.8.3.1
and read this for why

Its about time that these tools be phased out -- the services have been shut off (by default) in just about every *nix distribution on the market over the last decade. Someone needs to pioneer killing them -- and a strip-down default install like OpenBSD seems to be the appropriate place to do that.

There's a number of "what about me" folks out there -- who have some mitigating circumstance to need those tools (see here). It seems that these folks are just speaking out to hear themselves speak. Its not like these services are being excluded from the ports tree. Even if they were, you can still grab the source and build it yourself -- hell, there are still binary packages out there that you can just build.

Lastly, as stated in the thread here, its just the servers that are getting the axe, the clients stay...so all of the valuable tools (telnet, rlogin, etc) aren't going away.


-Turkey

Its about time that these tools be phased out -- the services have been shut off (by default) in just about every *nix distribution on the market over the last decade. Someone needs to pioneer killing them -- and a strip-down default install like OpenBSD seems to be the appropriate place to do that.

There's a number of "what about me" folks out there -- who have some mitigating circumstance to need those tools (see here). It seems that these folks are just speaking out to hear themselves speak. Its not like these services are being excluded from the ports tree. Even if they were, you can still grab the source and build it yourself -- hell, there are still binary packages out there that you can just build.

Lastly, as stated in the thread here, its just the servers that are getting the axe, the clients stay...so all of the valuable tools (telnet, rlogin, etc) aren't going away.


-Turkey

True, IETF is very friendly towards business. To the point of letting patented stuff get into IETF standards.

Theo's the instigator and the one calling names. Dan is not completely innocent either, but Theo (as usual) could have definitely handled the licensing issue better. Something along the lines of "Hey Dan, I was looking over your licensing for qmail and djbdns, and I'm concerned that we may inadvertently be breaking it," and then working from there. Even if Dan had ended up saying "no, don't change my paths" at least there would have been a good faith effort to work together. Did Theo even bother to ask for clarification or get in contact with Dan before pulling DJB programs out of ports?

What a knee-jerk reactionist Theo is... he seems to go out of his way to piss people off and provoke confrontation. In this followup DJB clearly states:

I don't mind a BSD-style port that simply follows the installation instructions. I have also explicitly granted permission for the distribution of precompiled packages that behave correctly. There's nothing stopping OpenBSD from distributing a qmail package.

So, as usual, Theo is blowing his stack over nothing and jumping to conclusions. He may be a good programmer, and he may be a good security expert, but he acts like a two-year-old.

1. package:
2. 
   ipfno modify reed removed by deraadt
   yacc/test/ftp.y no modify UCB removed by deraadt
   tcpwrappers no modify wietse fixed wietse & deraadt
   cron/popen.c no modify UCB alternative by millert
   md5(1) no modify RSA rewritten by millert
   games/hunt/list.c no modify d leonard fixed by d leonard
   login_fbtab no modify wietse fixed wietse & deraadt
   rpc.pcnfsd may not sell sun fixed sun & deraadt
   NRL code not on file NRL/craig metz fixed cmetz & deraadt
   We have a whole bunch of others to fix. I have contacted the authors of the other packages. I am optimistic that we can get most of these issues worked out. The ones which have particularily large problems:
   
   the multicast tools
   pppd
   ppp
   tcpdump
   

On the other hand, there was recently a question (and answer, make that answers) on the mailing list about a linux emulation error, but no mention of the possible trip-up (which novices might well encounter) in the HOWTO.

The OpenBSD developers spend a lot of effort making sure their documentation is clear, up to date, and accurate; it's an extension of their security focus in the sense of: "code should always do exactly and only what the documentation says it does".

What bothers me most, honestly, is having a secondary source that doesn't make it clear that 1) it is a secondary source, 2) where to find primary sources.

The beginning user who reads this and finds it inadequate has no guidance of where to go for further, possibly updated, help.

On the other hand, there was recently a question (and answer, make that answers) on the mailing list about a linux emulation error, but no mention of the possible trip-up (which novices might well encounter) in the HOWTO.

The OpenBSD developers spend a lot of effort making sure their documentation is clear, up to date, and accurate; it's an extension of their security focus in the sense of: "code should always do exactly and only what the documentation says it does".

What bothers me most, honestly, is having a secondary source that doesn't make it clear that 1) it is a secondary source, 2) where to find primary sources.

The beginning user who reads this and finds it inadequate has no guidance of where to go for further, possibly updated, help.

4.* is not nearly in good enough shape for shipping

Besides, evaluation requires huge amounts of $$$ and documentation, and may not actually involve an exhaustive code audit. (C2 certainly does not.) Frankly, Theo is not impressed with TOS evaluations, and might have to wea ken OpenBSD's crypto to get such a rating.

It is much more reliable to just turn things off until you have time to audit them.

OTOH, Theo's decisions are not flawless. C2 would require ACLs, and Theo does n't want them in OpenBSD. I think he's correct, that they usually are a problem, but I think that an admin should have the option of using them.

Besides, evaluation requires huge amounts of $$$ and documentation, and may not actually involve an exhaustive code audit. (C2 certainly does not.) Frankly, Theo is not impressed with TOS evaluations, and might have to wea ken OpenBSD's crypto to get such a rating.

It is much more reliable to just turn things off until you have time to audit them.

OTOH, Theo's decisions are not flawless. C2 would require ACLs, and Theo does n't want them in OpenBSD. I think he's correct, that they usually are a problem, but I think that an admin should have the option of using them.

Besides, evaluation requires huge amounts of $$$ and documentation, and may not actually involve an exhaustive code audit. (C2 certainly does not.) Frankly, Theo is not impressed with TOS evaluations, and might have to wea ken OpenBSD's crypto to get such a rating.

It is much more reliable to just turn things off until you have time to audit them.

OTOH, Theo's decisions are not flawless. C2 would require ACLs, and Theo does n't want them in OpenBSD. I think he's correct, that they usually are a problem, but I think that an admin should have the option of using them.

Besides, evaluation requires huge amounts of $$$ and documentation, and may not actually involve an exhaustive code audit. (C2 certainly does not.) Frankly, Theo is not impressed with TOS evaluations, and might have to wea ken OpenBSD's crypto to get such a rating.

It is much more reliable to just turn things off until you have time to audit them.

OTOH, Theo's decisions are not flawless. C2 would require ACLs, and Theo does n't want them in OpenBSD. I think he's correct, that they usually are a problem, but I think that an admin should have the option of using them.

Miguel: "...but I don't think their [BSD] tools have evolved like they should have evolved. Their kernel is great, but their tools, their userland, is just ancient. It needs some updating (the emphasis is mine). And, doing a Red Hat port, you'll hate me here, but the Red Hat port to the BSD kernel, looks like a good idea. You get some nice features from the kernel, and it'd be nice if you could just switch the application and run on the kernel is more interesting to you. Actually, you can do that. If the library is the same, and if the application is going to do any system calls, they just call the library, you can actually have binaries from both the BSD kernel and the Linux kernel."

And here is Theo's rebuttal shamelessly ripped from The o's Response

Miguel is wrong. I never find core files for the stock OpenBSD binaries. When bash.core stops being found, perhaps he can make some claims. When they stop having security holes, perhaps they can start to claim that their userland tools are non-ancient. When they stop calling mktemp(), inet_addr(), and strcpy, then perhaps they can start to claim something like that. Their source code is unmaintained.

Maybe short-sighted wasn't a good description for Miguel, ignorant would have been perfect. Try not to worship people from now on.

There was a short discussion about the merits of giving UNIX systems real time capabilities.
Its on the OpenBSD misc-mail list.

http:// www.sigmasoft.com/~openbsd/archive/openbsd-misc/20 0006/msg00018.html

and hey, "where's the beef" on that http://www.rtmx.com/ page? I want more details.

Sure, I'd be glad to explain. You're wondering why www.OpenBSD.org is running on a Solaris server. See this comment from the misc OpenBSD mail archive.

Basically www.OpenBSD.org runs on a University of Alberta server. The bandwidth is provided free. OpenBSD is looking for venture capital and funds are limited so why look a gift horse in the mouth?

While you're looking around the site, check out their T-shirts. I like the fish-cipher t-shirt t-shirt that any open source guy would like. It has the Blowfish code printed on the t-shirt's back.

Funny how this bit of ignorance comes from one of the largest penguins out there. Miguel de Icaza! Miguel's Incompetence

Miguel is wrong.

I never find core files for the stock OpenBSD binaries.

When bash.core stops being found, perhaps he can make some claims.

When they stop having security holes, perhaps they can start to claim that their userland tools are non-ancient.

When they stop calling mktemp(), inet_addr(), and strcpy, then perhaps they can start to claim something like that. Their source code is unmaintained. Theo's response

Todd Miller posted to misc@openbsd.org yesterday saying that this bug was fixed "quite some time" ago in OpenBSD.

And then he followe d up to his own message, explaining that OpenBSD was vulnerable...

N

Todd Miller posted to misc@openbsd.org yesterday saying that this bug was fixed "quite some time" ago in OpenBSD. A copy of his message can be seen here.

I as ked about this on the OpenBSD tech mailing list, and Theo de Raadt as sured me that it didn't.

I as ked about this on the OpenBSD tech mailing list, and Theo de Raadt as sured me that it didn't.