Toward the end he suggests NetBSD "dropped the ball" by not issuing patches and reports.

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.