I like to think the majority of NetBSD users either track -current, compile their own custom kernels or can learn to do as much. The project certainly makes it easy enough.
The flipside of the "many eyes" argument is that the Linux kernel has substantial financial backing and teams of paid developers behind it. NetBSD is relatively small and most contributors are not paid. I think they do an admirable job considering the number of active contributors and maintainers they have. (That is really an understatement but I do not want to appear too biased.) This is not the first time I have seen them immediately fix stuff when it is reported1.
Unfortunately, even though the presenter mentioned loc several times, he did not try to calculate a bugs:loc ratio.
Having a highly educational "history of BSD UNIX" and a large quantity of source code that allows hobbyists to run old hardware in their tree makes NetBSD not only unique and useful but also an easy target for any contemporary security researcher.
I only wish more would take on the challenge. Because sometimes things get fixed fast when this happens.
But comparing one project that has SVR4 compatibilty code to another project that has no such compat code, is that really an apt comparison? The old code is there for a reason. IMO, it does not imply many users will ever need it, that every user is actively using it, or that any user should have it in their kernel if they do not need it.
It is very easy for NetBSD users to compile kernels without code that will not be used, e.g., compatibility code. Easier than in any other OS I have tried. IMO, by making custom kernels so effortless to create (incl. best cross-compilation experience, IMO), it encourages users to compile smaller kernels without the drivers, compat code and other stuff they do not need.
But the presenter here was focused only on the assumption of a "default" kernel config. Not the potential to create small custom kernels with minimal attack surface.
Also: When the presenter was discussing filesystems, I wondered if he knew about rump. I think NetBSD was the first to have a such an innovative, safe way to mount filesystems using kernel drivers in userspace, without risk of crashing the kernel.
very few people ever bother to change them unless a specific, user visible problem is occuring
due to the first point, non-defaults receive little or no testing, and are highly likely to be broken, and stay broken because the catch 22 of nobody cares so its broken, and because its broken nobody cares.
Off by default is very much the status of mitigation technologies in FreeBSD atm, its a shame that the author did not touch on this as its one area OpenBSD is miles ahead of FreeBSD in particular (mitigations on by default, breakage exposed and fixed due to it, they remain mostly unusable on FreeBSD due to them).
To the "X86BSD" user who commented here: you are shadow banned so your comments are showing up as dead by default so most users can't see or reply to them. Just thought you should know.
For the record, if you see a shadow banned comment that shouldn't be shadowbanned, you can click on the timestamp and then click "vouch". I don't know if there are karma restrictions to this, though.
I would bet that this is not the case for NetBSD users. I'm pretty sure most of them change the defaults and have a pretty good of what's running where. I'm not insinuating that all of them are security researchers, but to the very least are above-average UNIX users.
It’s worth also mentioning that as far as I am aware the OpenBSD folks also almost universally eat their own dog food. Most of not all the developers run -current. The bleeding edge. So they can find and fix any issues. I’m not sure how many of the other developers for FreeBSD or NetBSD do that.
I'm a netbsd developer and run netbsd. I think most active netbsd developers do.
a lot of former netbsd developers are still hanging around and contributing to pkgsrc while using it on OS X or linux, I don't think that's a thing to be ashamed of.
The "many eyes" theory needs to go away, it is completely false when egregious bugs exist into their teenage years. That doesn't mean closed source fairs any better, but "many eyes" are largely blind to sophisticated bugs
I have a modification to many eyes that makes it relevant, which is many eyes make bugs shallow when the code is simple enough. I think over-complexity is at the heart of the issue here, and the path forward in the future will be in reducing complexity of codebases and increasing readability.
The comparison I like to use, though not completely fair, is that the linux kernel is now at what... 14mil+ loc, while minix is at more like 14k loc. As we have seen with the intel ME debacle... minix is production ready. This is also why I still think a microkernel is going to be the future.
GNU+HURD and half-life 3 release on the same day I think though.
> I have a modification to many eyes that makes it relevant, which is many eyes make bugs shallow when the code is simple enough.
Many eyes would make many bugs shallow if there only were said eyes.
The problem is that very few people lift a pinky to help audit & secure the software they use. Nobody reads the code. And then when disaster strikes a particular well known & widely used project and people start paying attention, they notice the code is full of low-hanging fruit that anyone could've fixed (nobody did).
Even when people read code and find bugs (as I often do), they're too busy to actually report let alone fix them.
It's so comfortable to pretend that someone else must've audited the code for you because it's open sauce. So you don't have to :-)
They can be protected after the fact with "You thought there were enough eyes, but there actually weren't." and "You thought the code was simple, but it actually wasn't."
Fully agree. I work on a large open source project and in 8 years I have encountered one person who found a bug by actually reading the code.
Many projects are stable only because the massive numbers of users that find bugs by running the software.
On the other hand there are virtually zero-fault small projects that no one is interested in because they are finished, bug-free and the author/maintainer would like to keep it that way.
"On the other hand there are virtually zero-fault small projects that no one is interested in because they are finished, bug-free and the author/maintainer would like to keep it that way."
Interesting that this statement did not trigger the usual mindless, meme-like HN syllogisms:
"Software is never finished."
"All software has bugs."
They try to discredit the truth that such small projects exist and might have something to offer.
The criticism seemed to be mostly about not issuing security advisories. Letting users know when there's something they need to upgrade is generally good practice
netbsd hasn't dropped the ball wrt backporting the changes, they are all in there, even for netbsd-6. here's one of the requests for the old stable netbsd-6 branches: http://releng.netbsd.org/cgi-bin/req-6.cgi?show=1482
it does have an issue with making advisories, though.
I am not sure about others but I have never considered what is reported at http://www.netbsd.org/support/security/ as comprehensive.
I like to think the majority of NetBSD users either track -current, compile their own custom kernels or can learn to do as much. The project certainly makes it easy enough.
The flipside of the "many eyes" argument is that the Linux kernel has substantial financial backing and teams of paid developers behind it. NetBSD is relatively small and most contributors are not paid. I think they do an admirable job considering the number of active contributors and maintainers they have. (That is really an understatement but I do not want to appear too biased.) This is not the first time I have seen them immediately fix stuff when it is reported1.
1 http://bulk.fefe.de/scalability/
Unfortunately, even though the presenter mentioned loc several times, he did not try to calculate a bugs:loc ratio. Having a highly educational "history of BSD UNIX" and a large quantity of source code that allows hobbyists to run old hardware in their tree makes NetBSD not only unique and useful but also an easy target for any contemporary security researcher.
I only wish more would take on the challenge. Because sometimes things get fixed fast when this happens.
But comparing one project that has SVR4 compatibilty code to another project that has no such compat code, is that really an apt comparison? The old code is there for a reason. IMO, it does not imply many users will ever need it, that every user is actively using it, or that any user should have it in their kernel if they do not need it.
It is very easy for NetBSD users to compile kernels without code that will not be used, e.g., compatibility code. Easier than in any other OS I have tried. IMO, by making custom kernels so effortless to create (incl. best cross-compilation experience, IMO), it encourages users to compile smaller kernels without the drivers, compat code and other stuff they do not need.
But the presenter here was focused only on the assumption of a "default" kernel config. Not the potential to create small custom kernels with minimal attack surface.
Also: When the presenter was discussing filesystems, I wondered if he knew about rump. I think NetBSD was the first to have a such an innovative, safe way to mount filesystems using kernel drivers in userspace, without risk of crashing the kernel.