Slashdot Mirror

March 10 would be more correct: http://www.openbsd.org/cgi-bin/cvsweb/XF4/xc/progr ams/Xserver/hw/xfree86/common/xf86Init.c.diff?r1=1 .13&r2=1.14&f=h

I'm first going on the assumption that the attacker only has regular user access. If he has root, then all is lost (well, not completely, but still...). Regular users, though, might find it a bit annoying to not have any includes available when trying to compile 1337_rootkit.c. They'd have to install their own tarball, link against those headers, etc.

Would that stop a determined cracker? No! But it's an extra layer of hassle that you're making them jump through, and if it takes them an extra five minutes to figure out, then maybe that's enough. Again, it's not a solution, but a layer. It's like filtering MAC addresses: you don't use that as your sole line of defense, but it's a nice idea in addition to your other methods.

And philosophically, an ideal system is one that does not one whit more than it was designed to do. You could install X and ircd on a firewall, too, but if those don't help it fulfill its deployment goals then why do it?

Jacek Artymiak explicitly states (no less than three times) in his book, Building Firewalls with OpenBSD and PF, Second Edition, that you shouldn't install source code and a compiler on your pf box (firewall). To quote him from page 71, "There is just too much possible risk" in doing so. While he doesn't go into the minutiae of the consequences, one can guess that if the pf box were compromised, you are giving the attacker everything he/she needs to own your box. I recommend you read his book and refer to pages 71, 72, and 101 for his statements on this scenario.

In OpenBSD, the UNIX manual pages are considered authoritative. If a program or function call does not behave exactly as the manual describes, this is considered a bug. This is reflected in the development process, which does not allow any code that result in a user-visible change to be committed to the tree without an accompanying update to the documentation.

I could maintain a lot of stuff in 10GB, but given the sensitive nature of most OpenBSD installations (such as firewalls, etc.), GCC is not among the things I want to have around.

According to the FAQ, three file sets are required for installation:

• bsd
• baseXX.tgz
• etcXX.tgz

Although that gets you a complete running system, it doesn't leave you with one that can self-host source updates. Given that I run exactly one OpenBSD machine at the office, I don't want to have a separate build server sitting around just to keep it updated. So, even though I have the hardware to support the process, and the technical skills to do so, it's still a major pain in the neck.

Oh, and to those saying I should just install snapshots, the FAQ says:

Between formal releases of OpenBSD, snapshots are made available through the FTP sites. As the name implies, these are builds of whatever code is in the tree at the instant the builder grabbed a copy of the code for that particular platform. Remember, on some platforms, it may be DAYS before the snapshot build is completed and put out for distribution. There is no promise that the snapshots are completely functional, or even install.

• /pub/OpenBSD/snapshots/
  For our major architectures, we tend to build mini releases of unknown stability and quality about every month or so. This is where we place those test releases.

Ain't no way I'm going to tell my boss that my security update process involves "mini releases of unknown stability and quality". That is why I'd like to see "baseXX-r1.tgz" at ftp.openbsd.bsd (and it's mirrors) that holds nothing but the 3 or 4 binaries I'd need to upgrade on a stock system to bring it up to date. I'm not stupid or broke - just very time-challenged. I'd be happy to pay for a subscription to such a service were one available.

I could maintain a lot of stuff in 10GB, but given the sensitive nature of most OpenBSD installations (such as firewalls, etc.), GCC is not among the things I want to have around.

According to the FAQ, three file sets are required for installation:

• bsd
• baseXX.tgz
• etcXX.tgz

Although that gets you a complete running system, it doesn't leave you with one that can self-host source updates. Given that I run exactly one OpenBSD machine at the office, I don't want to have a separate build server sitting around just to keep it updated. So, even though I have the hardware to support the process, and the technical skills to do so, it's still a major pain in the neck.

Oh, and to those saying I should just install snapshots, the FAQ says:

Between formal releases of OpenBSD, snapshots are made available through the FTP sites. As the name implies, these are builds of whatever code is in the tree at the instant the builder grabbed a copy of the code for that particular platform. Remember, on some platforms, it may be DAYS before the snapshot build is completed and put out for distribution. There is no promise that the snapshots are completely functional, or even install.

• /pub/OpenBSD/snapshots/
  For our major architectures, we tend to build mini releases of unknown stability and quality about every month or so. This is where we place those test releases.

Ain't no way I'm going to tell my boss that my security update process involves "mini releases of unknown stability and quality". That is why I'd like to see "baseXX-r1.tgz" at ftp.openbsd.bsd (and it's mirrors) that holds nothing but the 3 or 4 binaries I'd need to upgrade on a stock system to bring it up to date. I'm not stupid or broke - just very time-challenged. I'd be happy to pay for a subscription to such a service were one available.

I could maintain a lot of stuff in 10GB, but given the sensitive nature of most OpenBSD installations (such as firewalls, etc.), GCC is not among the things I want to have around.

According to the FAQ, three file sets are required for installation:

• bsd
• baseXX.tgz
• etcXX.tgz

Although that gets you a complete running system, it doesn't leave you with one that can self-host source updates. Given that I run exactly one OpenBSD machine at the office, I don't want to have a separate build server sitting around just to keep it updated. So, even though I have the hardware to support the process, and the technical skills to do so, it's still a major pain in the neck.

Oh, and to those saying I should just install snapshots, the FAQ says:

Between formal releases of OpenBSD, snapshots are made available through the FTP sites. As the name implies, these are builds of whatever code is in the tree at the instant the builder grabbed a copy of the code for that particular platform. Remember, on some platforms, it may be DAYS before the snapshot build is completed and put out for distribution. There is no promise that the snapshots are completely functional, or even install.

• /pub/OpenBSD/snapshots/
  For our major architectures, we tend to build mini releases of unknown stability and quality about every month or so. This is where we place those test releases.

Ain't no way I'm going to tell my boss that my security update process involves "mini releases of unknown stability and quality". That is why I'd like to see "baseXX-r1.tgz" at ftp.openbsd.bsd (and it's mirrors) that holds nothing but the 3 or 4 binaries I'd need to upgrade on a stock system to bring it up to date. I'm not stupid or broke - just very time-challenged. I'd be happy to pay for a subscription to such a service were one available.

I think you have to run Ooo in Linux emulation mode (add kern.emul.linux=1 to /etc/sysctl.conf and pkg_add relevant packages (see OpenBSD FAQ)). This is absolutely the best (and only) way to run Ooo in OBSD for now...

One problem is that Ooo contains lots of bugs, especially those related to memory handling. These bugs cause problems with e.g. OpenBSD's new malloc(3) call. Some porting and bugfixing work has actually been done by some OpenBSD developers but as far as I know that particular port is nowhere near production quality. Apparently more developers/coders/testing guinea pigs (with proper bug reporting skills) are needed. Some information about the OpenBSD port of Ooo is available in this presentation.

3.9 adds Zaurus remote control (zrc) support.
info: http://www.openbsd.org/cgi-bin/man.cgi?query=zrc&s ektion=4&arch=zaurus

First of all, I am not a user of *BSD, although I do appreciate their goals. I am a Debian user and have been one for quite some time now.

One fact to appreciate about Debian is that it is loosing its ties to the Linux kernel and becoming more and more general, now including even BSD efforts (like the kfreebsd5 port).

So, even though I am a Debian user, I have this secret appreciation for all the work that the BSD people have done and continue to do and I am downloading the OpenBSD release from the torrent site listed in the parent post (that is http://openbsd.somedomain.net/).

We all know that these smaller projects don't have big companies supporting them financially and one thing that other people could do to help visibility (and, in the long term, more users, and, perhaps, even commercial support) is to promote OpenBSD.

This starts with being kind on their servers and helping with the serving of the release for others, keeping your torrent clients open and serving others. Please, do help others "free" their machines with Free Software.

I'm doing my small share helping others to "get their foot wet" with the support for the torrent.

Regards, Rogério Brito.

Take a look at the OpenBSD rack in Theo's basement, and you will see how popular SPARC32 kit is with the devs - I counted 5 machines in total.

As always your contributions help to continue the devlopment of this great opeating system."

That sentence about should read:

As always your contributions help to continue the devlopment of all opeating systems.

Apple's security relies on openSSH, Microsoft service's for Unix are openBSD tools, there's traces of it all over linux. In short openBSD has made everyone's lives better - you should contribute to openBSD if you're a computer user of any sort!

Thanks Theo - for releasing your work under a BSD license, you've allowed us all to benefit from it.

As always your contributions help to continue the devlopment of this great opeating system."

That sentence about should read:

As always your contributions help to continue the devlopment of all opeating systems.

Apple's security relies on openSSH, Microsoft service's for Unix are openBSD tools, there's traces of it all over linux. In short openBSD has made everyone's lives better - you should contribute to openBSD if you're a computer user of any sort!

Thanks Theo - for releasing your work under a BSD license, you've allowed us all to benefit from it.

Somehow, I don't see Linus as the 'real innovator, and leader of the Free world.' For innovation, his kernel comes close to last. It was a copy of a design that originated at AT&T twenty years earlier, and that AT&T design was based on earlier models. For innovation in kernel space, you'd do better to look at people like Matt Dillon, Andrew Morton and Andrew Tanenbaum (who, by the way, had one kernel and userland to his name when Linus started, and now has a second kernel and a programming language). Most of the innovation that has happened in Linux has come from other contributors.

Linux became popular primarily because it wasn't innovative. People wanted a system that could run the code that had been written on expensive UNIX boxes on cheap commodity hardware. BSD UNIX was still tangled up in a lawsuit and the Minix license was a little too restrictive for some people (it's now BSD-licensed, by the way) and so Linux was the answer.

As for leader of the Free world, I think you've lost it completely. Compare Linus to someone like Theo De Raadt. Linus has no problem with making his entire project depend on a piece of closed-source software (BitKeeper). Theo wrote the original anonymous CVS implementation so his project could be open (how many F/OSS projects use anonymous CVS now?). He refuses to allow binary drivers to be distributed with his kernel, although the license allows it if third parties wish to distribute their drivers separately. How many Linux distros include binary drivers, even though they technically violate the kernel's license (and has Linus ever done anything about them? He's posted to the LKLM saying that he knows they violate the license, but never tried to stop them). In fact, Linus has publicly spoken out against the Free Software ideals - hardly a fitting 'leader of the Free world.'

Just think about all the jobs and companies that exist today because Linus built the OS that could. For Every embedded device that uses Linux, for every company that spits out yet another distribution, every hosting company that uses it

And if Linus hadn't been around, you don't think those jobs would exist? The AT&T lawsuit was over shortly after the release of Linux, and BSD was ported to the 386 shortly after that. Do you think those jobs exist because of Linux, or because of a free/Free UNIX-like OS? My money's on the latter, and there are several options in that field that have nothing to do with Linus.

So what? mod_ssl is an Apache module using the OpenSSL library, but borrows code as well from OpenSSL. They do acknowledge that: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin /httpd/src/modules/ssl/ssl_engine_init.c?rev=1.27& content-type=text/x-cvsweb-markup

I bet Theo de Raadt is so proud ;) him being a Canadian & Software Security Guru an'll ..

akimbo

Microsoft is making more money by supplying insecure software, and then withholding or providing fixes.

If that is the Microsoft business model, there will never be a secure version of Windows.

I'm against piracy, but I don't like how Microsoft does business. All of us legal customers are put through a lot of hassles so that Microsoft can prevent piracy. All of us legal customers must deal with the vulnerabilities so that Microsoft will be able to make money selling the next version of Windows, that really, really, this time, will be more secure.

The only real answer I can see is software that is designed to be secure, and is open source and free.

OpenBSD vpn(8) man page
Zero to IPSec in 4 minutes
OpenBSD IPSec with Cisco HOWTO (slightly old, but may still be useful to you as a pointer in the right direction)
And don't forget to check out the mailing list archives

I use OpenBSD on my Sokeris firewalls and they run very well indeed.

Other issues:

Hamachi setup: The setup time for Hamachi is exactly what they say: A few minutes. The interface is a bit quirky, and the documentaton is limited.

Anyone using Hamachi may want to run it as a service; see this explanation from Cyberonica.

Insecurity: Hamachi uses a very sensible technique for getting around firewalls and NAT. So does Skype VOIP. Of course, that means firewalls and NAT are not really protecting us.

In no way am I saying that Hamachi itself is insecure. I don't think that. They say all traffic is encrypted, and normally none passes through their servers. I am only saying that these techniques show the insecurity of our present protections.

ZoneAlarm Security Suite: We use ZoneAlarm Security Suite, a software firewall that notifies users every time something happens that might be an indication of a security breach.

If the users don't cooperate, and don't call us every time they see a notification, there is no security. ZoneAlarm's notifications are written in pure Geek, an unusual language which is used not to communicate but to pretend to communicate, while actually trying to avoid providing any useful information. Geek is a job security language, not a language for communication.

The real answer, of course, is to have a secure operating system, not one in which there is a lot of profit to be made selling the next version by criticizing the present version. We need an OS that is designed to be secure, not one that is allowed to be sloppy so that it is insecure.

Router VPN -- Netgear: We have had an enormous amount of trouble with Netgear router VPNs. We've had a lot of trouble with Netgear technical support. The Netgear products don't seem finished. Once they are working, our experience is that they stay working, with some quirks.

(Interestingly, Netgear is the worst company for avoiding sending rebates. We almost always have to go to the management of the store from which we bought Netgear equipment and have them get our rebates for us.)

On OpenBSD it's seldom that I've to google for something that is part of the base install (and that covers alot). Most, if not all, config files are documented in man pages or other documentation available (like the excellent FAQ).

You have to keep in mind the "man-pages" package is actually a separate project on its own. It's not strictly part of the Linux realm.

This seems to part of the problem.

It is seldom I see that anyone is recommending Linux users to read man pages. I used to use Linux (SuSE, a few years ago), but quality issues and poor documentation made me move away from it. In general, the Linux man pages are of low quality (out-of-date, incomplete and buggy), if there are any man pages at all to read.

New OpenBSD users with a Linux background are unused to actually read documentation, and just post on a mailinglist without doing some research first. Considering the quality of Linux documentation, that is understandable behaviour. However, on OpenBSD, the man pages and other documentation is high quality and is expected to be read.

[/rant]

The OpenBSD project has a very clear viewpoint on this issue. In fact, it's the theme for the upcoming 3.9 release song: http://www.openbsd.org/lyrics.html#39

Below are the reasons why the OpenBSD project is strongly opposed to using binary blobs:

"OpenBSD emphasizes security. It also emphasizes openness. All the code is there for all to see. Blobs are vendor-compiled binary drivers without any source code. Hardware makers like them because they obscure the details of how to make their hardware work. They hide bugs and workarounds for bugs. Newer versions of blobs can weaken support for older hardware and motivate people to buy new hardware.

Blobs are expedient. Many other open source operating systems cheerfully incorporate them; in fact their users demand them.

But when you need to trust the system, how do you check the blob for quality? For adherence to standards? How do you know the blob contains no malicious code? No incompetent code? Inspection is impossible; you can only test the black box. And when it breaks, you have no idea why.

• Blobs can be 'de-supported' by vendors at any time.
• Blobs cannot be supported by developers.
• Blobs cannot be fixed by developers.
• Blobs cannot be improved.
• Blobs cannot be audited.
• Blobs are specific to an architecture, thus less portable.
• Blobs are quite often massively bloated.

This release, like every OpenBSD release, contains OpenBSD and its source code. It runs on a wide variety of hardware. It contains many new features and improvements. OpenBSD does attempt to convince vendors to release documentation, and often reverse-engineers around the need for blobs. OpenBSD remains blob-free. Anyone can look at it, assess it, improve it. If it breaks, it can be fixed."

I've got a Sharp Zaurus and it seems much nicer than this thing. Has a full keyboard too. Of course, its more expensive. You get what you pay for.

Dual-booting XP and OpenBSD is blissfully easy if you use the Windows bootloader (NTLDR). I'm doing just that with a Thinkpad X41.

So for OpenBSD this means that they have working installer, you can compile your own kernel on your own box and most of the basic tools exist (emphasis mine.)

It's requirement for a supported arch that not only the kernel, but userland (including thirdparty applications like perl, Apache httpd, BIND, Sendmail, gcc toolchain and more) must also be built natively: cross-compiling is not sufficient to claim support, unlike some other OS that shall be unnamed. Some archs, like vax, is limited by hardware, while others are not fully supported due to lack of documentation/hardware/resources.

In general, if an arch is supported, it is supported well.

All the ports are there in source, and they may work for you, but really, who knows?

Ports are tested on all platforms, but some ports are not supported on some platforms either due to hardware limitations or bugs in the application.

A supported arch in Debian parlance, on the other hand, means that there is a working installer, you can coompile your own kernel on your own box..

OpenBSD has higher standards than just to be able to compile a kernel natively: Userland must also be built natively and it must be a useable OS.

... and virtually every debian package can be auto-built and available in binary form.

Now, this is silly. Of course OpenBSD offers pre-compiled ports (ie packages) for every arch where it makes sense. Obviously, on vax, for instance, there will be a limited supply of applications that may run on such a platform. However, there are quite a few packages available (not cross-compiled): ftp://ftp.openbsd.org/pub/OpenBSD/3.8/packages/vax

Exactly what piece of open source sofware have you found that has really well writen documention?

I'd like to comment on two other ways (besides OpenSSH) that I am going to benefit from OpenBSD - even though I do not directly use OpenBSD.

I have two computers - each running FreeBSD. One has an nVidia ethernet device that runs klunk-ily. It times out a lot and generally lags in its response time. The other has a cheap Realtek card that behaves the same way - although when it times out it never recovers - even if I unload and reload the driver module.

FreeBSD beat OpenBSD to the development of these drivers; but when OpenBSD had them ready for release (i.e., they were sufficiently proud of the result) they produced better code and (probably) tighter performance.

I fully expect the superior code for these devices to find its way into FreeBSD very shortly.

The OpenBSD nVidia code is here:
http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/s rc/sys/dev/pci/if_nfe.c?rev=1.53&content-type=text /plain
and the FreeBSD version is here:
http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/s rc/sys/dev/nve/if_nve.c?rev=1.7.2.8&content-type=t ext/plain

Notice the comment in the FreeBSD version that the driver is linked to the nVidia proprietary driver: ...
  * In accordance with the NVIDIA distribution license it is necessary to
  * link this module against the nvlibnet.o binary object included in the
  * Linux driver source distribution. The binary component is not modified in
  * any way and is simply linked against a FreeBSD equivalent of the nvnet.c
  * linux kernel module "wrapper". ...
The OpenBSD version is self-contained and open... obviously a far more desireable approach.

The comments in the FreeBSD version of the RealTek driver:
http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/s rc/sys/pci/if_rl.c?rev=1.145.2.4&content-type=text /plain ...betray obvious programmer frustration:
  * The RealTek 8139 PCI NIC redefines the meaning of 'low end.' This is
  * probably the worst PCI ethernet controller ever made,... ... and ...
  * You know there's something wrong with a PCI bus-master chip design
  * when you have to use m_devget().

It's still nice looking code.

The OpenBSD device driver:
http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/s rc/sys/dev/pci/if_rl_pci.c?rev=1.12&content-type=t ext/plain
is real tight. The programmer agrees with the FreeBSD device programmer but he makes no excuses.

  * Default to using PIO access for this driver. On SMP systems,
  * there appear to be problems with memory mapped mode: it looks like
  * doing too many memory mapped access back to back in rapid succession
  * can hang the bus. I'm inclined to blame this on crummy design/construction
  * on the part of RealTek.

I'd like to comment on two other ways (besides OpenSSH) that I am going to benefit from OpenBSD - even though I do not directly use OpenBSD.

I have two computers - each running FreeBSD. One has an nVidia ethernet device that runs klunk-ily. It times out a lot and generally lags in its response time. The other has a cheap Realtek card that behaves the same way - although when it times out it never recovers - even if I unload and reload the driver module.

FreeBSD beat OpenBSD to the development of these drivers; but when OpenBSD had them ready for release (i.e., they were sufficiently proud of the result) they produced better code and (probably) tighter performance.

I fully expect the superior code for these devices to find its way into FreeBSD very shortly.

The OpenBSD nVidia code is here:
http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/s rc/sys/dev/pci/if_nfe.c?rev=1.53&content-type=text /plain
and the FreeBSD version is here:
http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/s rc/sys/dev/nve/if_nve.c?rev=1.7.2.8&content-type=t ext/plain

Notice the comment in the FreeBSD version that the driver is linked to the nVidia proprietary driver: ...
  * In accordance with the NVIDIA distribution license it is necessary to
  * link this module against the nvlibnet.o binary object included in the
  * Linux driver source distribution. The binary component is not modified in
  * any way and is simply linked against a FreeBSD equivalent of the nvnet.c
  * linux kernel module "wrapper". ...
The OpenBSD version is self-contained and open... obviously a far more desireable approach.

The comments in the FreeBSD version of the RealTek driver:
http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/s rc/sys/pci/if_rl.c?rev=1.145.2.4&content-type=text /plain ...betray obvious programmer frustration:
  * The RealTek 8139 PCI NIC redefines the meaning of 'low end.' This is
  * probably the worst PCI ethernet controller ever made,... ... and ...
  * You know there's something wrong with a PCI bus-master chip design
  * when you have to use m_devget().

It's still nice looking code.

The OpenBSD device driver:
http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/s rc/sys/dev/pci/if_rl_pci.c?rev=1.12&content-type=t ext/plain
is real tight. The programmer agrees with the FreeBSD device programmer but he makes no excuses.

  * Default to using PIO access for this driver. On SMP systems,
  * there appear to be problems with memory mapped mode: it looks like
  * doing too many memory mapped access back to back in rapid succession
  * can hang the bus. I'm inclined to blame this on crummy design/construction
  * on the part of RealTek.

There's equipment costs (some gets donated, some doesn't: some of the vendors who use OpenSSH produce equipment which isn't well-supported by OpenBSD - this could probably be turned around by some judicious hardware donations and maybe a bit of assistance with docs). Around $5000/year goes on electricity. More goes on hackathons. This is all easily publically-available information, and is good enough for the many many individuals and small businesses who donate. Why should larger users who stand to make much more from the software be any less-trusting than the individuals who probably donate a much higher % of their income than the larger users would donate anyway?

Sure donation's not *required*...but where's the future cool stuff these companies can bundle for free going to come from if potential developers see how the large companies treat people whose open-source work they already profit from?

There's equipment costs (some gets donated, some doesn't: some of the vendors who use OpenSSH produce equipment which isn't well-supported by OpenBSD - this could probably be turned around by some judicious hardware donations and maybe a bit of assistance with docs). Around $5000/year goes on electricity. More goes on hackathons. This is all easily publically-available information, and is good enough for the many many individuals and small businesses who donate. Why should larger users who stand to make much more from the software be any less-trusting than the individuals who probably donate a much higher % of their income than the larger users would donate anyway?

Sure donation's not *required*...but where's the future cool stuff these companies can bundle for free going to come from if potential developers see how the large companies treat people whose open-source work they already profit from?

Well, look: I could describe precisely how I know this, and you could just say I was making it up (which is what you seem to be implying above -- which is understandable, but it's not the case). Really, all I can suggest is that you ask around yourself: there are plenty of people who can confirm this kind of detail for you who no longer have quite so much of their egos tied up in OpenBSD that they'd keep their mouths shut any more.

You can quite simply confirm that the checks have to be made out to Theo personally by looking at the OpenBSD donations web page: http://www.openbsd.org/donations.html -- unless they change it again while this discussion's going on, as they seem to be doing in response to comments here.

Of course, the one thing they don't change is that the money goes to Theo, not to any kind of entity with any kind of financial controls -- like *every other major open source project* uses.

http://marc.theaimsgroup.com/?t=114312315700005&r= 1&w=2

There has been such a great soap opera on this on the OpenBSD mailing list.

It's nice to see mozilla.org donate some cash but the real money should be coming from IBM, Redhat, Cisco and all the other vendors that bundle OpenSSH into their products. Somewhere in that post is a link to an email chain where IBM demanded Theo fix a bug that was in OpenSSH. (I believe the bug was fixed in a more recent version of OpenSSH then they were bundling.)

Sure, they could change the license for OpenSSH and start making money off it but that's missing the point of what the BSD license is all about.

It costs a lot of money to run that project and keep ahead of the jerks who are trying to break into your systems every day.

If you use products from vendors that have OpenSSH bundled in them and they aren't on http://www.openbsd.org/donations.html then send them an email and ask them to give regularly. that's the only thing we can do to help keep us safe on this hostile internet!

GO PUFFY

Yes, you do, if you use any of the software that they ship as part of the base install. They've put thousands of hours into auditing all those and submitting their changes upstream.

Basically, you're donating to a team who audits and secures a lot of software, some of which they write in-house. It's not meaningful to ask them to work on only your pet project since none of it stands in isolation. For example, suppose that their new memory allocator shows an error in OpenSSH. Was the fix part of their ongoing authorship of OpenSSH, or would you credit it to the memory allocator project?

"A lot of things, including a very secure operating system, are possible and even desirable."

A very secure operating system is here now, and free: OpenBSD: "Only one remote hole in the default install, in more than 8 years!"

That contrasts with Windows, which has had more than 20 remote vulnerabilities each year since Windows 95 was released in '95.

OpenBSD is Number One in security, by design.

My theory, expressed in the grandparent post, is that Windows is deliberately vulnerable due to the manner of management of software development. When a company has a virtual monopoly, vulnerability increases profit.

"A lot of things, including a very secure operating system, are possible and even desirable."

A very secure operating system is here now, and free: OpenBSD: "Only one remote hole in the default install, in more than 8 years!"

That contrasts with Windows, which has had more than 20 remote vulnerabilities each year since Windows 95 was released in '95.

OpenBSD is Number One in security, by design.

My theory, expressed in the grandparent post, is that Windows is deliberately vulnerable due to the manner of management of software development. When a company has a virtual monopoly, vulnerability increases profit.

Security by Default! Support OpenBSD buy CD/T-shirt or donate. And remember to donate to OpenSSH.

http://www.openbsd.org/donations.html
http://www.openssh.org/donations.html

We would like to think so, however, the driving principle of many open source projects is more features:

Revision 1.75.2.1 / (download) - annotate - [select for diffs] , Wed Jul 21 16:20:07 2004 UTC (20 months, 1 week ago) by robert
Branch: OPENBSD_3_4
Changes since 1.75: +2 -1 lines
Diff to previous 1.75 (colored) next main 1.76 (colored)

Mark it as BROKEN:

Right during 3.5, it had more than
a dozen remote holes being fixed, that we shipped with. Weeks later
things have not improved, and there continue to be problems reported
to bugtraq, and respective band-aids - but it is clear the ethereal
team does not care about security, as new protocols get added, and
nothing gets done about the many more holes that exist.

requested and ok'd by brad@

For Christ sake, only those into S&M like the iptables syntax. Use something decent

Like spinning netfilter (over 100 000 lines of code) as something great when there is a much better packet filter, like pf?

The password being in the log is a TINY problem compared with what Windows has.

The password written in the install log is tantamount to write the root password since that user has unrestricted sudo privileges (i.e. "sudo su"). If this kind of errors are made in Ubuntu, one wonders what other security issues Ubuntu has.

You can currently install Linux on a computer with a direct internet connection without problems. You can't do that with Windows. Patching it fully takes hours after installation and the average time before you get infected with something is about 30 minutes -- do the math. I actually tried that with a friend. Gave up after 3 tries, and ended up bringing it to my home so that I could install it behind my Linux firewall.

It is always prudent to install Windows on a machine behind a firewall, and let it continue to run behind a firewall. For home users, a cheap DSL router will function as a simple firewall and will protect you during installation as well. If a real firewall is needed/wanted, then install OpenBSD on a machine and use pf

Please don't propagate an OS which leaves it's root password in it's installation log as an 'Ultimate Spyware/Virus Blocker'.
If your serious about security have a look at OpenBSD.

It's all in the attitude and presentation to the public. He certainly acts like there is a moral obligation for companies to give him money. It's also not clear where all the money will go to. Checks are to be made to Theo personally. I can't tell, is there a charitable organization behind OpenBSD? If so, then they need to run it like one. If not, then Theo has no right to act like one.

Now compare this to Wikipedia. There's none of this "you owe us" business. There's a very transparent budget and list of contributions. And there's a non-profit organization behind it all.

...it's always good to start from a secure base...

Fact is, Linux isn't really a secure base.

If you aren't comfortable with the command line, forget about Trustix.

Why not chose something really secure then, like OpenBSD?

...I coulda been a contendah! ;P

... It's an OpenBSD wannabee without the proven track record?

You obviously don't understand the BSD world. The BSD projects aren't different because they are better at different things; they're different (and better at different things) because they have different priorities and goals that are largely incompatible. FreeBSD targets high-stress server environments where performance and reliability are paramount, so FreeBSD can do some bizarre stuff to improve performance--a while back someone did a benchmark between Linux and the three main BSDs, and the socket() graph shows you the kind of hacks FreeBSD does to improve performance.

NetBSD makes a clean, clear codebase a top priority, and its portability is kind of a feedback loop that both results from that decision and motivates it. NetBSD also tries to be very research friendly, and its high-performance networking stack is frequently used to set Internet2 records. They are also the least vociferous about software Freedom, as they were the last of the major BSDs to adopt X.org, and the only one to still use the "four-clause" version of the CSRG license.

OpenBSD also strives for clear code, but places much greater emphasis than the others on security and strong cryptography. OpenBSD periodically audits code, checks for bugs proactively, and the same kinds of bizarre hacks FreeBSD uses to improve performance are used in OpenBSD to improve security (such as making structuring vm pages out of order to prevent malicious buffer overflows. OpenBSD is also the most strongly advocating Free Software, as they spearheaded (along with Debian) the campaign to dump Xfree86, maintain a version of Apache 1.3 because the 2.x license was less free, and include no binary drivers or otherwise unfree in the base distribution. They're kind of like a BSD version of the FSF.

DragonFly[BSD] is the newcomer of the bunch, a fork of FreeBSD. So far the over-arching goals are to improve modularity and to replace bulky structures and processes with lighter, quicker versions. The plan to replace the usual syscall table with a messaging api (apparently like a lightweight Mach-type thing, but evidently not microkernel design) make it very different from its cousins.

It's important to note that these are not just the result of a few random patches to the system approved by a czar, as in Linux, but explicit decisions by the core developers to follow a particular blueprint, to make a particular improvement, or to support (or not) an obsolete API/ABI. If you want to submit a patch out of the blue, you certainly can, and if it's competently coded it will probably be accepted, but the overwhelming majority of code contributions come from the core developers following architectural guidelines. If you tried to combine all 3-4 codebases, the incompatibility of several design decisions would end up combining a stable OS, a lightweight OS, a portable OS, and a secure OS into something that managed to preserve none of these features.

That said, however, because of the similar licensing requirements, the BSD projects all share code extensively, and are frequently source (if not binary) compatible with each other. So it's not like Linux, where packaging systems are completely different but the OS features are all the same (because they use the exact same codebase). In an odd way, the members of BSD family are both more closely related and more different from one another than the various Linux distros are.

donate the $49 and do an ftp install. if you really want 3.9 right now, grab it from CVS and do a make release

He accuses Linux developers of having "much more flexibility to their belief systems than I have", but then goes on to make an exception to their core belief regarding Full Disclosure for Sun, because they pissed him off.

They don't call him Theo The Rat just because it's an obvious pun.

Football clubs here in Melbourne get funds partly by selling annual memberships. With your membership you get a sticker for your car saying that you are a paid up member for year such and such. People get a kick out of displaying evidence of their contribution.

Or they could sell tees... oh wait

I bought the T-shirt; does that count?