Slashdot Mirror

You're right. See their Crypto page. In fact, they build their binary releases only in Canada, Sweden, and Germany to avoid ITAR type restrictions.

from the OpenBSD FAQ:

3.3 - Does OpenBSD provide an ISO image for download?
Starting with OpenBSD 4.2, for select platforms, yes!

Users of the alpha, amd64, hppa, i386, macppc, sparc and sparc64 platforms can now download and install ISO image which can be used to create a CD-ROM that can boot and install all of OpenBSD.

Note, this ISO is not the same as the official CD set. These images are for single platforms, and do not include any of the pre-compiled packages, stickers, or artwork that the official CD set does.

As before, however, ISO file installation is NOT the optimum installation method for many people. It is still usually faster and simpler to download the boot media and then install just the portions needed. However, for those who wish to do a number of installations, or can not figure out how to drop ten files on a CD-ROM or set up a local FTP server, ISOs are available.

The OpenBSD project does not make the ISO images used to master the official CDs available for download. The reason is simply that we would like you to buy the CD sets to help fund ongoing OpenBSD development. The official OpenBSD CD-ROM layout is copyright Theo de Raadt. Theo does not permit people to redistribute images of the official OpenBSD CDs. As an incentive for people to buy the CD set, some extras are included in the package as well (artwork, stickers etc).

Note that only the CD layout is copyrighted, OpenBSD itself is free. Nothing precludes someone else from downloading OpenBSD and making their own CD.

For those that need a bootable CD for their system, bootdisk ISO images (named cd45.iso) are available for a number of platforms which will then permit the rest of the system to be installed via FTP. These ISO images are only a few megabytes in size, and contain just the installation tools, not the actual file sets.

IP over IP, duh. Look, it's been lying dormant in BSD networking code for years! Below that, it's turtles all the way down.

Part of the problem is building it in from the beginning. There is much more fun and/or marketing appeal to build in eye candy, support the latest games, multi-media capabilities, mobile devices support etc. than to design in security.

A vendor or kernel programmer group should design it in from the ground up. But there isn't really any money in it for vendors and few programmers think of it as fun. With the exception of these guys maybe http://www.openbsd.org/security.html

So in other words, many people are dropping the ball for a variety of reasons, commercial interest, lack of skill or plain disinterest.

Security should be "plug and play". The user shouldn't have to think about it at all, other than put in the correct key (physical or virtual). Which I think is also part of your point.

"Secure by Default" is OpenBSD's claim, it is not from Linux. The previous poster didn't mention anything about Linux in his post. Nice of you to deliberately confuse the issue. Microsoft shill much?

Ah, the old days of slashdot, where at any mention of Linux, some bastard would morph the conversation to claim someone had said Linux is "bulletproof" "perfect" "impossible to hack", when in fact, no one had made any such claim at all.

We do not find as many problems anymore, it is simply a case of diminishing returns. Recently the security problems we find and fix tend to be significantly more obscure or complicated. Still we will persist for a number of reasons:

* Occasionally we find a simple problem we missed earlier. Doh!
* Security is like an arms race; the best attackers will continue to search for more complicated exploits, so we will too.
* Finding and fixing subtle flaws in complicated software is a lot of fun.

The auditing process is not over yet, and as you can see we continue to find and fix new security flaws.

That page has a list of security advisories in their releases. They're fixed in the current branch, but it proves that they acknowledge when they have holes & then fix them.

The FreeBSD man page says "A wall command appeared in PWB UNIX" (my link), and the OpenBSD man page says "A wall command appeared in Version 7 AT&T UNIX" (again, my link).

So... mid- to late 70s at the latest.

I think errata 013 and 014 fixed http://www.openbsd.org/errata31.html were the best examples of critical bugs making it in for at least 2.5 years of releases. Now of course they were not remote exploits so do not count for those two, but they led to the OpenBSD guys to carefully look for other possible signed/unsigned mistakes in a whole lot of code, and of course they were very serious bugs.

While OpenBSD does have an outstanding security record, with good design & separation of privileges, they aren't perfect.

As they say on their website, "Only two remote holes in the default install, in a heck of a long time!"

Indeed you are correct, it is false to state that OpenBSD has never had critical bugs. However the 2 bugs mentioned on their website is an amazing statistic compared to the best serious software vendors like sun, HP, redhat, IBM, etc. have managed.

but this is just plain wrong!

`` exactly on the date promised''

Lies! OBSD releases are regularly released a month early.

And, the canard that de Raadt is an asshole is plain wrong. To those who follow OBSD for anything other than a short period of time will know what his, the team's refrain is: We make this OS for us, not for you! Your benefit is an unintended consequence. We don't want to be the most popular, we make this OS for us, not for you! You want Linux. We don't talk, we code. We don't suggest bs features, we code. You want it, code it. But then you keep posting to the list, you've been told to help yourself, that we make this OS for us, not for you! So I will now tell you to fuck off, slacker.

It's simple, man. I've read Bruce Perens say he met the guy, extended his hand but the guy never acknowledged him, that he might be Aspergerish. I thought Bruce was off his rocker when I read that. He bats .400 most of the time, and some-times I say WTF is he drinking today?

Check out theo.c for a lot of laughs!!!

One list goodie went sort of like this years ago: Why are you posting to misc@. Why didn't you read the man pages, slacker. They're quality, this is not Linux. If you didn't bother you're an idler. If you read them and didn't understand them you're a lamer.

"you bring new meaning to the terms slackass. I will have to invent a new term." --Theo de Raadt

http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mg/theo.c

The slides are here: http://www.openbsd.org/papers/asiabsdcon2009-release_engineering/

While OpenBSD does have an outstanding security record, with good design & separation of privileges, they aren't perfect.

As they say on their website, "Only two remote holes in the default install, in a heck of a long time!"

Is the one developed by the hard working folks at the OpenBSD project whom have been studying spam for well over 5 years. They came up with something that is devlishly clever called OpenBSD Spamd. Spamd is basically a fake smtp engine that sets the TCP RWIN to 1. By doing this, it causes the transmission speed to slow to 1 byte per second. This can cause a backlog or even crash the spam spender. Fight back, don't filter! You can even create a serious of spam trap addresses, publish them, and reverse harvest the IP addresses of the spam senders. Check out http://www.openbsd.org/

I forgot how good of an article that was, these were fixed in OpenBSD 3.1, they are errata 014 and 015.

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

When mounting a filesystem under OpenBSD you can specify that any file within that mount cannot be executed. I find that this is very much a valuable flag (noexec) when you are mounting /tmp and /home as it pretty much prevents execution of files outside of expected areas.

http://www.openbsd.org/cgi-bin/man.cgi?query=mount&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

Of course if it is a script, nothing stops the person from calling the interpreter first. e.g. perl script.pl

Here's a problem with ESET's Nod32 discussed on March 9, 2009: NOD32 was deleting very critical and required Windows files.

The fundamental problem is that Microsoft makes more money if there are security problems in Windows.

OpenBSD doesn't require anti-virus and anti-spyware programs partly because it was written to be secure. Apple's Mac OS X is based on BSD, and users rarely have problems with that operating system being insecure.

Amazingly, Microsoft is not only supplying insecure software, it is charging for programs to fix the insecurities!!! See Windows Live OneCare.

Microsoft charges Microsoft Windows users $50 for software to fix problems in Windows! Windows Live OneCare has "Antivirus and antispyware all in one". More: "Two-way firewall helps stop hackers in their tracks". Hmmm, Microsoft, if Windows needs a "Two-way firewall", and it certainly does, why do you supply a one-way firewall with Windows???

See Windows Live OneCare Gripes. Quote: "Create the problem, then charge people money to solve it." Another quote: "Why should Microsoft profit from the plague of viruses and Spyware? Shouldn't it have designed Windows better to begin with? And if it has indeed found a way to protect Windows, isn't it a tad exploitative to charge for it? Microsoft has no convincing answer for these questions . . ."

Another quote: "McAfee, Symantec and Microsoft (with Windows Live OneCare) all set your credit card up for automatic renewals when you purchase their security software on-line. ... the gripe is that you can't opt out of this during the purchase. OneCare is the most difficult of the three to opt out of. In fact, you can't. Instead you must must cancel your subscription altogether by calling 866-663-2273."

To me, it seems like this: Testing... Testing... How much abuse will computer users accept?

OpenBSD's pf firewall has some options that can help mitigate the "single attacker, single source IP" version of this attack. Of course if the attackers decide to spread the attack out over multiple source IPs like a DDoS, this becomes much harder to deal with until Apache has a patch.

Filter rules that create state entries can specify various options to control the behavior of the resulting state entry. The following options are available:

The total number of source IP addresses tracked globally can be
controlled via the

src-nodes runtime option.

Source at:

ftp://ftp.usa.openbsd.org/pub/OpenBSD/distfiles/rtmpdump-v1.5.tar.gz

Can't find 1.6 tho.

But since they're general drivers, they never archieve the same results as specific drivers made for Windows by the manufacturer.

OTOH, you also have OSS drivers that are better, where, e.g., you can use the same configuration utility to run your wireless card or the same configuration utility to manage your RAID.

But since they're general drivers, they never archieve the same results as specific drivers made for Windows by the manufacturer.

OTOH, you also have OSS drivers that are better, where, e.g., you can use the same configuration utility to run your wireless card or the same configuration utility to manage your RAID.

Does OpenBSD have any of the SELinux type security features?

systrace is a different kind of tool. It does allow you to set access policies, but for the system calls. Also, SE Linux is an add-on for the Linux kernels only. Systrace is available for Linux and the BSDs, which would include systrace for OpenBSD, You'll have to check if OS X is still covered.

According to their website, it is built for security:

The first sentence under goal: OpenBSD believes in strong security. Our aspiration is to be NUMBER ONE in the industry for security (if we are not already there).

Actually the OpenBSD guys rewrote their pkg_* tools (in Perl) some time ago. See http://cvs.openbsd.org/papers/ven05-espie/index.html for more information. On FreeBSD you still have to use old pkg_* tools that are not so sophisticated. On the other hand in FreeBSD you have the portinstall/portupgrade stuff since FreeBSD software installation process is more focused on support for installation from source...

Keeping systems up-to-date, both base system and userspace stuff, is much easier on Debian-based systems, IMO.

I upgraded to 4.5 this morning, and the package upgrade instructions were to run pkg_add -ui -F update -F updatedepends. Now, I'm typing this on Ubuntu, and I use FreeBSD on most of "my" servers, but that just about as convenient as it gets.

Except that - as someone pointed out in an earlier comment - the optional packages like Firefox and KDE don't get the auditing and code screening. Hell, allegedly they don't even get prompt security updates when upstream fixes something.

"The one area where OpenBSD is let down on the security front is the packages/ports"

"The ports & packages collection does NOT go through the thorough security audit that the OpenBSD base system does. Although we strive to keep the quality of the packages collection high, we just do not have enough human resources to ensure the same level of robustness and security"

"I find it intimidating that the community is unable or unwilling to maintain proper information channels for security-related maintenance"

You could try looking over on the Bug Tracking System or the openbsd-bugs mailing list

I'm in a business where we welcome GPL-licensed apps with open arms. Of course, we don't sell software, we sell services and expertise.

Well, many people sell service and expertise and they use non-GPL products. For instance, the URLs below will take to people who sell services and expertise in *BSD systems.

http://www.freebsd.org/commercial/consult.html
http://www.openbsd.org/support.html
http://www.netbsd.org/gallery/consultants.html
http://www.ixsystems.com/

If you published a method for taking control of an OpenBSD system by having physical control of the hardware...

The method is already published in OpenBSD FAQ 8.1: I forgot my root password, what do I do now?

...In fact, I can tell you how to do that right now...

Your guidance is incorrect. No live media needed, and there is no such thing as /etc/shadow. OpenBSD is not Linux.

Yet again, OpenBSD shows foresight by having this bugginess fixed in 2003 long before the actual chips were available on which this can happen. Well done, lads.

What version of OpenBSD are you referring to?

Stable. I refer the honorable gentleman to the BSD FAQ I gave previously. Actually, you might find that reading it will help you manage your BSD system effectively.

P.S. SELinux is not anti-virus software any more than PF is anti-virus software. Please have a look at some of the documentation. It's a quite interesting security framework which actually includes RBAC as a possible configuration. Possibly a bit complex to build; in RedHat it is almost user-transparent which means that it shouldn't be a problem. Please also note mellon's comments.

There is a project called OpenBSD which does exactly what you suggest open source projects don't do: conduct security audits of their whole system.

Personally, I would trust OpenBSD much more than I would any closed-source vendor. Also, OpenBSD has a number of security features that limit the impact of any vulnerabilities not caught by the audit process.

Not to mention that going with OpenBSD hands them a huge PR opportunity and it likely to net some serious support from senior OpenBSD developers.

There is a project called OpenBSD which does exactly what you suggest open source projects don't do: conduct security audits of their whole system.

Personally, I would trust OpenBSD much more than I would any closed-source vendor. Also, OpenBSD has a number of security features that limit the impact of any vulnerabilities not caught by the audit process.

Not to mention that going with OpenBSD hands them a huge PR opportunity and it likely to net some serious support from senior OpenBSD developers.

I agree with you that Linux in general isn't a very safe bet when you want to be secure, especially not if you are worried about targeted attacks.

However, that does not mean that ``open source software, in it's current form, cannot defend against a concerted attack by any large groups of individuals. It can't be done.''

There is a project called OpenBSD which does exactly what you suggest open source projects don't do: conduct security audits of their whole system.

Personally, I would trust OpenBSD much more than I would any closed-source vendor. Also, OpenBSD has a number of security features that limit the impact of any vulnerabilities not caught by the audit process.

Also, Debian has an audit process that looks not only at the base system, but also at the packages that are included in the distribution. This does not cover all packages, but goes a whole lot further than what many vendors (particularly Microsoft) offer.

On the whole, I think you are being overly negative about security in the open source world, and too optimistic about security in the closed source world. From personal experience, I can tell you from personal experience that the idea that code in closed-source projects has to make it past "at least one code review" is simply wishful thinking. By contrast, the idea that code has to pass at least one review before being accepted is an actual reality in at least some open source projects (including Linux and OpenBSD).

So, while certainly not claiming that using Debian or even OpenBSD is a panacea for security, I have much more faith in those projects than in any closed source project.

I agree with you that Linux in general isn't a very safe bet when you want to be secure, especially not if you are worried about targeted attacks.

However, that does not mean that ``open source software, in it's current form, cannot defend against a concerted attack by any large groups of individuals. It can't be done.''

There is a project called OpenBSD which does exactly what you suggest open source projects don't do: conduct security audits of their whole system.

Personally, I would trust OpenBSD much more than I would any closed-source vendor. Also, OpenBSD has a number of security features that limit the impact of any vulnerabilities not caught by the audit process.

Also, Debian has an audit process that looks not only at the base system, but also at the packages that are included in the distribution. This does not cover all packages, but goes a whole lot further than what many vendors (particularly Microsoft) offer.

On the whole, I think you are being overly negative about security in the open source world, and too optimistic about security in the closed source world. From personal experience, I can tell you from personal experience that the idea that code in closed-source projects has to make it past "at least one code review" is simply wishful thinking. By contrast, the idea that code has to pass at least one review before being accepted is an actual reality in at least some open source projects (including Linux and OpenBSD).

So, while certainly not claiming that using Debian or even OpenBSD is a panacea for security, I have much more faith in those projects than in any closed source project.

OpenBSD believes in strong security. Our aspiration is to be NUMBER ONE in the industry for security (if we are not already there). Our open software development model permits us to take a more uncompromising view towards increased security than Sun, SGI, IBM, HP, or other vendors are able to. We can make changes the vendors would not make. Also, since OpenBSD is exported with cryptography, we are able to take cryptographic approaches towards fixing security problems.

Not to mention OpenBSD has been auditing their code file-by-file since 1996. They also employ the following technologies:

strlcpy() and strlcat()

Memory protection purify

• W^X
• .rodata segment
• Guard pages
• Randomized malloc()
• Randomized mmap()
• atexit() and stdio protection

Privilege separation

Privilege revocation

Chroot jailing

New uids

ProPolice

And since OpenBSD is based in Canada you get all the cryptography you would ever desire.

Surprised it doesn't seem to have been recommended yet. This OS is developed with security as a guiding design principle and offers binary emulation compatibility with Linux.

The obvious solution is Yellow Hat GNU/Linux.

Seriously, this is a great project. Surely the appropriate solution is a version of either GNU/Linux, such as SELinux, or OpenBSD. No system is entirely secure, but the idea that MS Windows could be as secure as GNU/Linux or BSD is wild.

I'm a BSD fan, but OpenBSD just changes their definition of 'exploit' everytime an exploit is found. I used to think it was impressive for their sayings on their website like 'no exploits in 10 years'. But then it happened, and it was changed to no remote exploits, then no exploits in a default install, and it appears now they've finally started admitting to it a little better.

A look at the index.html page in the CVS repository (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html) reveals that this is not true in the form you told it. As you can see, the "bragging" as the call it in the first introduction, started with Revision 1.284 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.283;r2=1.284;f=h) like the following:

Three years without a remote hole in the default install!
Two years without a localhost hole in the default install!

So the statement was always about remote holes (besides localhost holes) in the default installation. In Revision 1.305 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.304;r2=1.305;f=h) the "localhost thing" was dropped and in Revision 1.391 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.390;r2=1.391;f=h) a "Only" was added.

In Revision 1.534 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.533;r2=1.534;f=h) and 1.535 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.534;r2=1.535;f=h) the years were updated. In Revision 1.549 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.548;r2=1.549;f=h) the statement changed from "Only one" to "Only two" remote holes which is the current version.

Costed me five minutes of cvs crawling. :-)

I'm a BSD fan, but OpenBSD just changes their definition of 'exploit' everytime an exploit is found. I used to think it was impressive for their sayings on their website like 'no exploits in 10 years'. But then it happened, and it was changed to no remote exploits, then no exploits in a default install, and it appears now they've finally started admitting to it a little better.

A look at the index.html page in the CVS repository (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html) reveals that this is not true in the form you told it. As you can see, the "bragging" as the call it in the first introduction, started with Revision 1.284 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.283;r2=1.284;f=h) like the following:

Three years without a remote hole in the default install!
Two years without a localhost hole in the default install!

So the statement was always about remote holes (besides localhost holes) in the default installation. In Revision 1.305 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.304;r2=1.305;f=h) the "localhost thing" was dropped and in Revision 1.391 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.390;r2=1.391;f=h) a "Only" was added.

In Revision 1.534 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.533;r2=1.534;f=h) and 1.535 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.534;r2=1.535;f=h) the years were updated. In Revision 1.549 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.548;r2=1.549;f=h) the statement changed from "Only one" to "Only two" remote holes which is the current version.

Costed me five minutes of cvs crawling. :-)

I'm a BSD fan, but OpenBSD just changes their definition of 'exploit' everytime an exploit is found. I used to think it was impressive for their sayings on their website like 'no exploits in 10 years'. But then it happened, and it was changed to no remote exploits, then no exploits in a default install, and it appears now they've finally started admitting to it a little better.

A look at the index.html page in the CVS repository (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html) reveals that this is not true in the form you told it. As you can see, the "bragging" as the call it in the first introduction, started with Revision 1.284 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.283;r2=1.284;f=h) like the following:

Three years without a remote hole in the default install!
Two years without a localhost hole in the default install!

So the statement was always about remote holes (besides localhost holes) in the default installation. In Revision 1.305 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.304;r2=1.305;f=h) the "localhost thing" was dropped and in Revision 1.391 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.390;r2=1.391;f=h) a "Only" was added.

In Revision 1.534 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.533;r2=1.534;f=h) and 1.535 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.534;r2=1.535;f=h) the years were updated. In Revision 1.549 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.548;r2=1.549;f=h) the statement changed from "Only one" to "Only two" remote holes which is the current version.

Costed me five minutes of cvs crawling. :-)

I'm a BSD fan, but OpenBSD just changes their definition of 'exploit' everytime an exploit is found. I used to think it was impressive for their sayings on their website like 'no exploits in 10 years'. But then it happened, and it was changed to no remote exploits, then no exploits in a default install, and it appears now they've finally started admitting to it a little better.

A look at the index.html page in the CVS repository (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html) reveals that this is not true in the form you told it. As you can see, the "bragging" as the call it in the first introduction, started with Revision 1.284 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.283;r2=1.284;f=h) like the following:

Three years without a remote hole in the default install!
Two years without a localhost hole in the default install!

So the statement was always about remote holes (besides localhost holes) in the default installation. In Revision 1.305 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.304;r2=1.305;f=h) the "localhost thing" was dropped and in Revision 1.391 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.390;r2=1.391;f=h) a "Only" was added.

In Revision 1.534 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.533;r2=1.534;f=h) and 1.535 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.534;r2=1.535;f=h) the years were updated. In Revision 1.549 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.548;r2=1.549;f=h) the statement changed from "Only one" to "Only two" remote holes which is the current version.

Costed me five minutes of cvs crawling. :-)

I'm a BSD fan, but OpenBSD just changes their definition of 'exploit' everytime an exploit is found. I used to think it was impressive for their sayings on their website like 'no exploits in 10 years'. But then it happened, and it was changed to no remote exploits, then no exploits in a default install, and it appears now they've finally started admitting to it a little better.

A look at the index.html page in the CVS repository (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html) reveals that this is not true in the form you told it. As you can see, the "bragging" as the call it in the first introduction, started with Revision 1.284 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.283;r2=1.284;f=h) like the following:

Three years without a remote hole in the default install!
Two years without a localhost hole in the default install!

So the statement was always about remote holes (besides localhost holes) in the default installation. In Revision 1.305 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.304;r2=1.305;f=h) the "localhost thing" was dropped and in Revision 1.391 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.390;r2=1.391;f=h) a "Only" was added.

In Revision 1.534 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.533;r2=1.534;f=h) and 1.535 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.534;r2=1.535;f=h) the years were updated. In Revision 1.549 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.548;r2=1.549;f=h) the statement changed from "Only one" to "Only two" remote holes which is the current version.

Costed me five minutes of cvs crawling. :-)

I'm a BSD fan, but OpenBSD just changes their definition of 'exploit' everytime an exploit is found. I used to think it was impressive for their sayings on their website like 'no exploits in 10 years'. But then it happened, and it was changed to no remote exploits, then no exploits in a default install, and it appears now they've finally started admitting to it a little better.

A look at the index.html page in the CVS repository (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html) reveals that this is not true in the form you told it. As you can see, the "bragging" as the call it in the first introduction, started with Revision 1.284 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.283;r2=1.284;f=h) like the following:

Three years without a remote hole in the default install!
Two years without a localhost hole in the default install!

So the statement was always about remote holes (besides localhost holes) in the default installation. In Revision 1.305 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.304;r2=1.305;f=h) the "localhost thing" was dropped and in Revision 1.391 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.390;r2=1.391;f=h) a "Only" was added.

In Revision 1.534 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.533;r2=1.534;f=h) and 1.535 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.534;r2=1.535;f=h) the years were updated. In Revision 1.549 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.548;r2=1.549;f=h) the statement changed from "Only one" to "Only two" remote holes which is the current version.

Costed me five minutes of cvs crawling. :-)

I'm a BSD fan, but OpenBSD just changes their definition of 'exploit' everytime an exploit is found. I used to think it was impressive for their sayings on their website like 'no exploits in 10 years'. But then it happened, and it was changed to no remote exploits, then no exploits in a default install, and it appears now they've finally started admitting to it a little better.

A look at the index.html page in the CVS repository (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html) reveals that this is not true in the form you told it. As you can see, the "bragging" as the call it in the first introduction, started with Revision 1.284 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.283;r2=1.284;f=h) like the following:

Three years without a remote hole in the default install!
Two years without a localhost hole in the default install!

So the statement was always about remote holes (besides localhost holes) in the default installation. In Revision 1.305 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.304;r2=1.305;f=h) the "localhost thing" was dropped and in Revision 1.391 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.390;r2=1.391;f=h) a "Only" was added.

In Revision 1.534 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.533;r2=1.534;f=h) and 1.535 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.534;r2=1.535;f=h) the years were updated. In Revision 1.549 (http://www.openbsd.org/cgi-bin/cvsweb/www/index.html.diff?r1=1.548;r2=1.549;f=h) the statement changed from "Only one" to "Only two" remote holes which is the current version.

Costed me five minutes of cvs crawling. :-)

Okay, so list the systems which are "B" Posix compliant. ie. ps ax shows all processes, while ps -ax only shows processes from user "x"

Huh?

It's "ps -aux" (identical to "ps -a -u x") that brings user "x" into the picture. Plain "ps -ax" (identical to "ps -a -x") has a "-x" option that POSIX does not define. POSIX allows "ps -ax" to be a usage error, but requires "ps -aux" to print processes for user "x".

OpenBSD's ps man page even admits to being non-POSIX, oddly right after claiming to be compliant. (WTF?)

Compare yourself:

• POSIX and UNIX
• OpenBSD

Completely incompatible options include: -e -u

Missing options include: -A -d -f -G -g -n

Other problems are incorrect long ("-l") format, lack of support for multiple users with the -U option or multiple tty with the -t option, missing "etime" keyword... and I think I've abused the pitiful thing enough today.

After the demise of SGI, one has to wonder about the future of traditional Unix.

Sun is going the way of SGI because of traditional Unix!

Conficker Eye Chart

Conficker Eye Chart

How to interpret:

If you see this above:It probably means this:

= Normal/Not Infected by Conficker (or using proxy)
= Possibly Infected by Conficker (C variant or greater)
= Possibly Infected by Conficker A/B variant
= Image loading turned off in browser?
Any other combination= Poor Internet connection?

Explanation:

Conficker (aka Downadup, Kido) is known to block access to over 100 anti-virus and security websites.

If you are blocked from loading the remote images in the first row of the top table above (AV/security sites) but not blocked from loading the remote images in the second row (websites of alternative operating systems) then your Windows PC may be infected by Conficker (or some other malicious software).

If you can see all six images in both rows of the top table, you are either not infected by Conficker, or you may be using a proxy server, in which case you will not be able to use this test to make an accurate determination, since Conficker will be unable to block you from viewing the AV/security sites.

F-Secure and the F-Secure Logo are trademarks of F-Secure Corporation.

SecureWorks and the SecureWorks Logo are registered trademarks of SecureWorks Inc.

Trend Micro and the T-Ball logo are trademarks or registered trademarks of Trend Micro Inc.

Was this not paraphrased in mid-2007 by Theo of OpenBSD fame?

You, sir, are a troll.

"Best open source OS" my foot.