Slashdot Mirror

You seem to think that this is a theoretical argument. Please find one bug in the original DJB qmail code and then you will be worthy of taking this discussion further. The OpenBSD people have lead the way and shown that even starting with a messy entire operating system you can seriously move in the direction of secure, bug free code.

The point is that there is a choice; one which becomes very visible when you have a security vulnerability found. Do you fix that one single bug or do you pay a little more and go through your code base looking for every single one like it? Many proprietary vendors choose to do the one single minimal fix, which is wrong and is part of what is driving the visceral reaction to your post which reads, to some of us, like an excuse for them.

You seem to think that this is a theoretical argument. Please find one bug in the original DJB qmail code and then you will be worthy of taking this discussion further. The OpenBSD people have lead the way and shown that even starting with a messy entire operating system you can seriously move in the direction of secure, bug free code.

The point is that there is a choice; one which becomes very visible when you have a security vulnerability found. Do you fix that one single bug or do you pay a little more and go through your code base looking for every single one like it? Many proprietary vendors choose to do the one single minimal fix, which is wrong and is part of what is driving the visceral reaction to your post which reads, to some of us, like an excuse for them.

I think the grandparent was right. MS now is hugely better than the MS of 10-15 years ago. I'm not going to try and objectively prove that as I don't care enough about MS and probably couldn't anyway.

But the NT4 to XP/2003 era was appalling security wise - but they changed that. IIS went from swiss cheese to one of the tougher web servers to break. You just don't hear any more about the kinds of problems they used to have. If you endured those days or just laughed from the sidelines, you don't need any hard data to see that they have improved a lot.

I found this paper from Theo de Raadt illuminating though. He steps through 10+ years of OS hardening techniques OpenBSD has put in place to prevent badly written applications misbehaving. Towards the end he summarises how other platforms do this stuff - the only other platform that did it all by default was Windows (yikes!).

Obviously since OpenBSD is running their fork of OpenSSL 0.9.8 which essentially doesn't have this exploit, this is just a shameless plug.

OpenBSD 5.3 - 5.5 was affected: see their Security Advisories

Oh, you mean they should be auditing everybody else's code too?

Umm, yeah? Since that's what they claim to do:

The process we follow to increase security is simply a comprehensive file-by-file analysis of every critical software component.

http://www.openbsd.org/securit...

Or are you going to claim that OpenSSL is not a critical software component?

Wow, a code audit. What a great idea for a FOSS project.

"All software has defects, it's the nature of the beast."

There is a HUGE difference between the situation that Microsoft is in, in which defects are allowed to be a way to make more money, and a healthy arrangement. Why has OpenBSD had so few defects? Because that organization looks for defects before they release software.

"... since you're so convinced that MS is outright evil". First, that is not a logical argument against what I said. Second, I don't say that Microsoft is "outright evil".

Also, it surprises me that you don't know what is generally being said about Microsoft: Steve Ballmer, former CEO of Microsoft, was fired for abuse! Bill Gates, a board of directors member, agreed that he should be fired! A magazine called him the worst CEO in the United States! Another magazine called Steve Ballmer "Monkey Boy" on its cover. Several years ago, it was common that people called Bill Gates "Satan". For links to all that, see my article.

Unless the mmap/malloc combo on the O/S you're using was able to purposely put guard pages after mmaped blocks so many malloced objects would end in such guard pages. Unfortunately...

Apparently OpenSSL uses its own allocator on top of the libc's (malloc). I.e. it only occasionally allocates a large chunk of memory from the C heap and then does its own allocations/reallocations in that (without anything like ASLR or guard pages of course). And apparently the particular sequence in which the OpenSSL library code allocates bits of memory using this allocator leads to a situation where the private key is always deterministically located behind the heartbeat packet space in memory. AFAICT this is why this bug is so remarkably portable and "works" reliably on all platforms.

Unless the mmap/malloc combo on the O/S you're using was able to purposely put guard pages after mmaped blocks so many malloced objects would end in such guard pages. Unfortunately...

correct not their project but OpenBSD does use openssl and if you run OpenBSD 5.4 you can apply patch here:

http://ftp.openbsd.org/pub/Ope...

5.3 here:
http://ftp.openbsd.org/pub/Ope...

5.5 (to be released next month!) patch is here:
http://ftp.openbsd.org/pub/Ope...

correct not their project but OpenBSD does use openssl and if you run OpenBSD 5.4 you can apply patch here:

http://ftp.openbsd.org/pub/Ope...

5.3 here:
http://ftp.openbsd.org/pub/Ope...

5.5 (to be released next month!) patch is here:
http://ftp.openbsd.org/pub/Ope...

correct not their project but OpenBSD does use openssl and if you run OpenBSD 5.4 you can apply patch here:

http://ftp.openbsd.org/pub/Ope...

5.3 here:
http://ftp.openbsd.org/pub/Ope...

5.5 (to be released next month!) patch is here:
http://ftp.openbsd.org/pub/Ope...

iptables fucking sucks and everybody knows it. Heres a nickel kid, get yourself a real firewall. http://www.openbsd.org/faq/pf/...

You have not seen OpenBSD, have you? It is not perfect, but quite close to it.

http://www.openbsd.org/securit...

The ports tree has had package signing capability for some years, but it was left to users to implement.

New with 5.5 will be both signed kernels and filesets for the base OS, and signed packages, using a simple public/private key pair system with a newly developed signify(1) tool and related infrastructure and install/upgrade/sysmerge changes.

Just as a side-note, OpenSSL is not at all affiliated with the people working on OpenBSD/SSH/SMTPD... and other projects listed on the official OpenBSD website.

This is on the OpenBSD site, but I'm not sure when it was taken: http://www.openbsd.org/images/...

Judging by the fact that the 2009 pic has less old shit racked I would have to say that the one you linked to is undoubtedly older, probably by a few years.

This is on the OpenBSD site, but I'm not sure when it was taken: http://www.openbsd.org/images/...

Stockpiling them instead of helping the vendors fix them. So were our systems cracked by an enemy using an exploit that we knew of?

This is an interesting question; it's still not enough. Experience in OpenBSD's audit process shows that a single vulnerability is an entry to finding other bugs. If you fix all of the similar bugs in your code then you very likely fix vulnerabilities you will never realise you had. The NSA (and the GCHQs) should be using it's government purchasing power to

• insist that the source code to all software used by their nation is availble to them; recommend against code without the source code
• actively identify and report vulnerabilities
• build automatic tools which identify all similar bugs in the vendor's code
• offer support to vendors in building their own tools to do similar things
• again; recommend against and (for networks where they have access) insist on replacing software where the vendor doesn't then rapidly fix those similar bugs

This kind of work would make the internet safer for everyone. It would interfere slightly with some of their spying work, however the benefit of having a safe, stable, secure internet would vastly outweigh that. Even so they would find plenty of space in a) software targeted to other nations and b) systems yet fully upgraded to be able to able to continue that work.

When they fail to do this they are failing in their duties.

USA would be worst place possible for hosting project with focus of openbsd, that's a country that claimed encryption was a munition in the past, and still restricts it now. Modernizing? some platforms don't have any current system to modernize to, it's a question of getting used systems. the openbsd project does have a list of desired donation equipment: http://www.openbsd.org/want.ht...

For what it's worth, it would seem like [a different kind of?] a package signature system was actually supported since 2010, it's just that the official packages were never signed.

http://www.openbsd.org/faq/faq15.html#PkgSig

Revision 1.71:
Sat Jul 17 09:02:47 2010 UTC (3 years, 6 months ago) by ajacoutot
Changes since revision 1.70: +65 -1 lines

Add a "Package signatures" section to teach people how to create and use
signed packages. Still opened for enhancement but all info is there now.

Wrong. The OpenBSD FAQ expressly recommends packages over ports.
http://www.openbsd.org/faq/faq15.html#PkgVsPorts

http://openbsd.org/faq/faq15.html#Ports

"Everyone is encouraged to use the pre-compiled binary packages."

What the heck? What you say makes sense, but it's wrong.

Looking closer, the FAQ is wrong here.

A "package" is defined as a binary executable, and a "port" is defined as the source (using OpenBSD's terminology).

Yes. This is about who builds the package, though. It's a bit vague terminology, but for my purposes, 'using a port' means building it yourself and installing the resulting package, while 'using a binary package' means fetching the prebuilt package from somewhere else.
With this out of the way..

And, I quote, http://www.openbsd.org/faq/faq15.html#PkgVsPorts

"In general, you are highly advised to use packages over building an application from ports.

Well frankly I have no idea why there's such utter BS in the FAQ.
It essentially tells us we're ``highly advised'' to fetch unsigned tarballs over plaintext ftp, when the alternative way is the admittedly antiquitated but at least secure cvs-over-ssh checkout.
Every security-minded person with half a brain can figure.

Maybe using a binary package isn't the actually right/secure way, but it definitely is "considered" to be "the right away to do things", exactly in contrast to your statement.

Your argument is essentually argument-by-authority, although I admit I usually trust official FAQs, too. This seems really odd.

On the upside, when signify is done, they at least don't need to update the FAQ, since then using binary packages will be equivalently secure.

Kudos for contributions = http://www.openbsd.org/donations.html

Limited editions (whatever) = http://www.openbsd.org/older.html

And, yes, I am going to donate soon - and not request anything in return - simply because I like OpenBSD.

Kudos for contributions = http://www.openbsd.org/donations.html

Limited editions (whatever) = http://www.openbsd.org/older.html

And, yes, I am going to donate soon - and not request anything in return - simply because I like OpenBSD.

I tried to do the math on this too. First of all, I'm not sure if the number is 20,000 USD or CAD (Since OpenBSD is based in Canada not the US). Next up is the fact that many of the machines are older non x86 machines that are not power efficient. For example when the SGI/AlphaStations/VAX/SparcStations were produced, focus was on MHz not power utilization. Finally, I think the project might use some type of uninterruptible power supply (UPS) as well as network switches, etc.

So by your math you're looking at CAD 20,000 = EUR 13,500 which at EUR 0.20 per kWh would buy you 67500 kWh = 7.7 kWh.

Now the project has supports about 20 architectures. And there are dedicated machines used to build the base system and dedicated machines used to build ports so at least 2 of each machine. On top of that there's probably an NFS server to host the source code, some UPS, network switches, etc, etc. So say about 50 machines total.

So 7.7kWh / 50 machines gets you to 154 watts per machine. I do believe they are on 24x7 as there are daily builds for many architectures, etc, etc. 150 watts is not unreasonable power consumption in my opinion.

Not only is 150 watts not unreasonable, it is actually far better than I would expect. average server draw for some of the older stuff I would expect to be double that. People don't seem to realise how quickly power consumption adds up when you need to run a whole bunch of computers, switches and UPS to support them and most likely some cooling on top of that.

I tried to do the math on this too. First of all, I'm not sure if the number is 20,000 USD or CAD (Since OpenBSD is based in Canada not the US). Next up is the fact that many of the machines are older non x86 machines that are not power efficient. For example when the SGI/AlphaStations/VAX/SparcStations were produced, focus was on MHz not power utilization. Finally, I think the project might use some type of uninterruptible power supply (UPS) as well as network switches, etc.

So by your math you're looking at CAD 20,000 = EUR 13,500 which at EUR 0.20 per kWh would buy you 67500 kWh = 7.7 kWh.

Now the project has supports about 20 architectures. And there are dedicated machines used to build the base system and dedicated machines used to build ports so at least 2 of each machine. On top of that there's probably an NFS server to host the source code, some UPS, network switches, etc, etc. So say about 50 machines total.

So 7.7kWh / 50 machines gets you to 154 watts per machine. I do believe they are on 24x7 as there are daily builds for many architectures, etc, etc. 150 watts is not unreasonable power consumption in my opinion.

Problems with donating to OpenBSD

(1) The donations are being requested after the end of the tax year

Most charitable donations occur in October/November/December for tax reasons. This is true of both deductible and non-deductible donations.

(2) Donations are not tax deductible

This isn't a huge problem, if the OpenBSD Foundation were willing to invoice the company for the amount; then it could still be deducted as a business expense, but then the OpenBSD Foundation would have to claim it as income and pay tax on it. This isn't terrifically onerous for them in any case, as they are not a charity, and thus have to pay tax anyway, unless they can just get someone to pay their power bill directly instead (something they've requested).

Another option would be to have a U.S. OpenBSD non-profit that could then support work by OpenBSD under contract, even if that work were something like "provide nightly builds of OpenBSD binaries in exchange for grant funds". They don't seem interested in/able to utilize, this approach.

(3) Invoicing would not exactly require some measure of editorial control, but...

There would be at least an implied expectation of quid-pro-quo, even if none exactly existed, since an audit of the company that was invoiced could require at least a paper justification for the value obtained in exchange for the invoiced amount. It doesn't have to be a great deal for the company, and it could actually be a completely lopsided deal, but there would need to be a token exchange of goods and/or services for the invoiced amount.

(4) If someone is willing to pay their power, they demand they be a Canadian company

I can understand the ramifications for this coming from a non-Canadian company; OpenBSD needs to understand the ramifications of "any port in a storm". There really aren't that many Canadian technology companies in this sector, compared to the U.S.; the highest percentage of OpenBSD-based products are in fact German.

(5) There are not a large number products based directly on OpenBSD

The companies that do have products based on it are generally not hugely profitable, and the small number that there are are listed here: http://www.openbsd.org/products.html which gives you some indication of their market penetration.

(6) The OpenBSD folks don't have the most stellar relationship with the rest of the Open Source community

Without assigning specific blame, this should probably be addressed sooner, rather than later.

--

All in all, it's rather difficult to set up a legal fiction that would let it be advantageous to a business to donate.

It's not that they do not provide valuable software, it's just that most of the value they provide is not in the OpenBSD OS itself, it's in the ancillary projects that are associated with the same people.

This is Slashdot, we should be automating the increase in electricity bills.

watch -n 5 wget --delete-after http://www.openbsd.org/images/rack2009.jpg

Yes, I know that's a sort of "attack" and wouldn't actually do it.

Here's a link to a photo on OpenBSD Journal of the build server racks and all the great (some quite old) machines being used:

http://www.openbsd.org/images/rack2009.jpg

Lots of memories looking at some of those machines... I'd be a bit concerned about the longevity of some of those.

I found this one a pretty mind-blowing entry. ...

The program wears many hats (not literally). It is

* a web server
* a PNG encoder
* a ray tracer
* a clock

Unlike the PC emulator entry, it does not require a binary blob and all the code and data fit within the 4 kilobyte limit.

And this is why I'm a big fan of OpenBSD's continuous code audits and general outlook regarding security.

I found this one a pretty mind-blowing entry. ...

The program wears many hats (not literally). It is

* a web server
* a PNG encoder
* a ray tracer
* a clock

Unlike the PC emulator entry, it does not require a binary blob and all the code and data fit within the 4 kilobyte limit.

And this is why I'm a big fan of OpenBSD's continuous code audits and general outlook regarding security.

Thank goodness for OpenBSD and a bit of elbow grease.

You mean like practically everyone?

Not quite like everyone, stupid.

I really like the BSDs, especially Tinfoil. There will always be standalone servers. But we think that the future is partially about router/server hybrids with eg. big LRU caches. A great example of this. A busy router can easily download the same image file, 100K times a day. That's waste. In a perfect world we'd have a completely finished software system, that works everywhere, without hacks, and doesn't have to leverage the convenience of an OS that seems to have most of the market share out there. If it's any consolation anything we do should be trivially portable to the BSDs. But at the moment it doesn't seem like there is a big market for what we are doing.

tl;dr Premature optimization is the root of all evil.

Was he far from true? yes, openbsd is secure... but security objective makes many parts almost unusable...

That is untrue: I use OpenBSD daily as a workstation and as a server, on virtual and physical machines. It is very usable, stable and certainly as easy to use as most Linux distributions (I will grant you it is not as polished, as, say OpenSUSE or Ubuntu, for instance).

Need something that already exists?! lets do it all over, because now it will be "secure" (not that the original was insecure, it was just NIH).

Again, that is untrue: OpenBSD borrows liberally from other BSD (NetBSD/FreeBSD) and also from Linux. Most of the time, when OpenBSD decides to create a new solution, it is because the existing ones are not that good, in terms of security and stability.

Helping others fix the problems on their code? no, never! just use our unix and tools.

Again, this is completely untrue: check out the presentation Theo gave recently about the techniques OpenBSD pioneered and many other OS have adopted, including Linux: http://www.openbsd.org/papers/ru13-deraadt/mgp00001.html -- Particularly this slide: http://www.openbsd.org/papers/ru13-deraadt/mgp00030.html

Remember: OpenBSD is open-source - everything that is created under OpenBSD can (and maybe should?) be ported under other OSes... Case in point: OpenSSH.

many BSD developers, specially Theo, just use the security flag as a way to show off how good they are, and how everyone else should thank then for the universe.

But forget Linus, imagine a flame war between Theo De Raadt and Daniel J. Bernstein about security!!! that would be FUN!!

NOW, you have got a point! ;-)

Was he far from true? yes, openbsd is secure... but security objective makes many parts almost unusable...

That is untrue: I use OpenBSD daily as a workstation and as a server, on virtual and physical machines. It is very usable, stable and certainly as easy to use as most Linux distributions (I will grant you it is not as polished, as, say OpenSUSE or Ubuntu, for instance).

Need something that already exists?! lets do it all over, because now it will be "secure" (not that the original was insecure, it was just NIH).

Again, that is untrue: OpenBSD borrows liberally from other BSD (NetBSD/FreeBSD) and also from Linux. Most of the time, when OpenBSD decides to create a new solution, it is because the existing ones are not that good, in terms of security and stability.

Helping others fix the problems on their code? no, never! just use our unix and tools.

Again, this is completely untrue: check out the presentation Theo gave recently about the techniques OpenBSD pioneered and many other OS have adopted, including Linux: http://www.openbsd.org/papers/ru13-deraadt/mgp00001.html -- Particularly this slide: http://www.openbsd.org/papers/ru13-deraadt/mgp00030.html

Remember: OpenBSD is open-source - everything that is created under OpenBSD can (and maybe should?) be ported under other OSes... Case in point: OpenSSH.

many BSD developers, specially Theo, just use the security flag as a way to show off how good they are, and how everyone else should thank then for the universe.

But forget Linus, imagine a flame war between Theo De Raadt and Daniel J. Bernstein about security!!! that would be FUN!!

NOW, you have got a point! ;-)

You don't know anythin about OpenBSD, do you?

Just read this and learn something: http://www.openbsd.org/papers/ru13-deraadt/mgp00001.html

Let's start with the premise of TFA, which cites the article on Ars that was covered here a few days ago and was complete nonsense about the new random number infrastructure in FreeBSD. We are not moving away from using the hardware random number generator directly, we have never used the hardware random number generator. The new code that the Ars article was talking about is to allow the PRNG to be easily switched. In 10 we're shipping both Fortuna and Yarrow and the infrastructure allows more to be added. The code has been reviewed by two cryptographers that I know of and possibly others. Neither the old nor the new implementation is vulnerable to the attack against random number generators that was published a couple of months ago (Linux was the subject of the paper, not sure if OpenBSD was vulnerable).

If Theo is going to make such remarks as this, he should think more carefully first:

"Basically, it is 10 years of FreeBSD stupidity. They don't know a thing about security. They even ignore relevant research in all fields, not just from us, but from everyone."

He'd be advised to take a look at the transactions for the IEEE Symposium on Security and Privacy over the last 10 years and see how many papers are describing techniques that were both originally implemented on FreeBSD and are now part of the default install. Let's take a look at the two systems, from a security perspective. Both FreeBSD use SSP and non-excutable stack by default, so I'll skip those. To begin with, OpenBSD features missing on FreeBSD:

W^X enforcement. Definitely a nice idea, but it breaks some things (JITs mostly). The default memory map in FreeBSD is W^X, but it is possible to explicitly mmap() memory both writeable and executable. It's generally considered a bad idea though, and we don't ship any code that allows it. We permit third-party code to shoot itself in the foot if it really wants to and provide mitigation techniques to reduce the risk.

Then there's ASLR. This is a pretty nice technique, which is currently not implemented on FreeBSD. We do support PIE, so it would not be a horrendously difficult thing to add, but current implementations (including OpenBSD) use a surprisingly small amount of entropy in the address layout and so don't provide as much mitigation as you'd hope (which, of course, Theo knows, because he's very familiar with 'relevant research'). This is especially true on 32-bit systems.

And that's it for OpenBSD. Well, unless you want to count , but since that's vulnerable to a timing attack (still not fixed), which was published in the USENIX Workshop on Offensive Technologies, and Theo is aware of all 'relevant research' in security then it can't really still be there.

Now let's look at FreeBSD security mechanisms:

First up, jails. Jails are somewhere between a chroot and a VM: a shared kernel, but all of the global namespaces (filesystems, IP addresses, users) are separated and so you can completely isolate a service, such as a web browser, from the rest of the system. Scripts like ez-jail in the ports tree make it easy to set up lightweight service jails.

Then there's the MAC framework, which allows modular access control policies. This is used by a couple of FreeBSD derivatives: JunOS uses it to implement code signing, OS X and iOS use it for application sandboxing. You can also use it for traditional type enforcement policies, as in SELinux and a variety of other things.

And then there's Capsicum, which adds a capability model on top

I googled it:

http://www.openbsd.org/crypto.html#hardware
https://lobste.rs/s/gbe1zl/we_cannot_trust_intel_and_via_s_chip-based_crypto_freebsd_developers_say

I don't know whatever that actually mean, how it is or how reliable anything else is. Maybe someone with some actual knowledge can provide the answers :) (My thought was that one could likely use different randomizers.)

You mean like these? http://www.openbsd.org/lyrics.html#54

Well you can find out for yourself at the OpenBSD home page, which explains their approach to security: http://www.openbsd.org/security.html OpenBSD is definitely an educate yourself then ask questions sort of OS. I'm not slagging on you, just saying it makes more sense for me to post a link than try to recreate the contents of the webpage it goes to. Check it out. Decide for yourself.

I'd suggest starting here as a beginning: 9 - Migrating to OpenBSD
One thing I find OpenBSD is head and shoulders above other *nix OSs at: the documentation. Virtually every service, binary, config, library, /etc/*, what-have-you has a thorough manpage included. The emphasis on security and "correctness" shows everywhere: pf is fantastic (iptables is a cancer by comparison), the built-in IPSec is great, it's OpenSSH's "home OS", etc.

Everything fits very well together (as is also the case with FreeBSD and NetBSD). All the OpenBSD users could post replies to your question but the only way to see for yourself is to try it out.

Enjoy!

Rather than paying gigabucks for a hardware router/firewall, take an ancient machine, add a second ethernet card to it and install OpenBSD onto it.OpenBSD will do you as well as anything hardware based, in terms of protecting your network -- even if it is bit more work to get properly configured. You can also then install stuff like Snort and wireshark to REALLY watch what your system is doing.

It won't take much in terms of hardware -- even a sub 1Gz machine will be more than sufficient for a 20 megabit feed.

Should Google fire the OpenSSH developers they employ (Like this guy)? Should they stop donating to OpenBSD as shown here?

The "only" problem - and not really a little one - with OpenBSD for the specific purpose of acting as a wireless access point is that the state of its 802.11 drivers and stack is far from desirable.

First and foremost, there are currently only two WiFi chipsets worth looking at in the case of being used in "Host AP" mode on OpenBSD, and both of them have problems: the athn(4) driver for the Atheros family of chipsets is the only 802.11 driver in OpenBSD that supports powersaving clients when in Host AP mode - and believe me, this is very important for the routers' quality of service - but it suffers some as-of-yet resolved problem causing a notable amount of transmission errors for UDP traffic (no problems with TCP traffic, though). The ral(4) driver supporting the Ralink family of chipsets DOES NOT support powersaving clients currently, and it's a major problem, but the ral(4) driver is otherwise perfect, and in my personal experience the Ralink chipsets have the absolutely best signal quality, lowest transmission latency and least problems with signal distortion of all WiFi hardware I've used.

Secondly, there is the smaller problem of OpenBSD's 802.11 stack not yet having 11n support. For most users, me included, this won't matter at all.

I've been using OpenBSD profesionally and personally at home for about 14 years now, of which the past 7 years it has seen use in mine and friends' homes as a home router, often with WiFi capabilities. The OS itself is excellent for this and I'm most pleased with it for this particular purpose, but the 802.11 drivers' current state is plain and simply underdeveloped.

My advice to the original poster, or anyone else who is considering OpenBSD for a WiFi router, is to go with a card supported by the ral(4) driver ( incomplete device list here: http://www.openbsd.org/cgi-bin/man.cgi?query=ral&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html ), and try to live with the problems of lacking support for powersaving clients, or work around them by either disabling PSM on your clients if this is possible, or preventing the client devices' 802.11 chip from entering PSM. I've been using a ral(4) device for my OpenBSD router for a bit more than 5 years now, and, despite of its problems, it's for the moment definitely a better choice than an athn(4) device.

My money is on OpenBSD for projects like this. You get very compact base system that still has all the stuff you need in there for a project like this. And even my old PF tutorial has enough info to get you up and running.

But with the man pages and the OpenBSD FAQ you really have all the information you need at your fingertips.

My money is on OpenBSD for projects like this. You get very compact base system that still has all the stuff you need in there for a project like this. And even my old PF tutorial has enough info to get you up and running.

But with the man pages and the OpenBSD FAQ you really have all the information you need at your fingertips.

things tend to go slow. Real slow. If you want things now, now, now, pay the man/men. It is free, as in someone-else-will-do-it, so you get what you, that's right, didn't pay for.

Fortunately, eventually people found this hobby project worth paying for, although I think it proved its worth before the big money started pouring in.

There are, of course, some other hobby projects that also manage to support a little more hardware than the Hurd does without huge amounts of money poured into them.