FreeBSD – a lesson in poor defaults

Some discussion here:https://www.reddit.com/r/freebsd/comments/4azhmm/freebsd_a_l...

Wow, that comment about OpenSMTPD. I highly recommend reading beyond the first message. The reddit poster links it as supporting their claim, but the rest of the picture sure doesn't.

The author writes:

   ###############################################################################
   daily_status_security_pkgaudit_enable="NO"
   ###############################################################################

   I most certainly don't want pkg (running as root, remember) going out to
   the internet every night to fetch a list of vulnerable ports.

   Who thought this was safe?

I’m confused. Why is this unsafe? Is it because the author doesn’t trust `pkg` to do the auditing job safely as root? Remember, this isn’t automatic updating/installing. This job just adds a section to the daily email that tells you which packages have security updates to them.

I'm really torn on the issue of how tightly coupled the userland configuration is to the release cycle. I'm not sure that I'd be running FreeBSD today if it hadn't been that way, because having a well tested and widely deployed base image makes adoption so much easier. The common problems that novices get discouraged by are completely sidestepped: package conflicts, library incompatibility, missing drivers, etc.

But after several years of use I find the methods used to implement those thing getting in the way:

In the interest of security I want the kernel to have the smallest attack surface possible, and this isn't just a theoretical thing. Not long ago there was a very serious remote exploit that leveraged two default kernel compile options - SCTP and IPV6, and had those not been made default (few can even take advantage of SCTP) I'm sure the number of vulnerable machines would have been tiny. So to decrease your risk for a 0 day you want to get off the GENERIC kernel config, but now you need to constantly rebuild the kernel in order to keep up with the latest security fixes - and you can't safely automate the build/install process.

Building the userland is far worse. The mk scripts handle dependency through explicitly defined, and very fragile, rules. Don't want the base version of openssl? Well have fun figuring out how to get your build working after some uefi bins that you don't even want fail to find the missing openssl headers - because somebody forget to add that dependency to the mk file. I could go on for hours, the buildworld process is a trainwreck.

But there is good news! The problem is actively being addressed, as I understand it, a lot of that is being pushed into a sort of blessed pkg repo. So hopefully we'll have the best of both worlds - easy initial base, and unlimited customization that leverages the pkg dependency code. I've been working on my own solution, using dynamically generated dependency graphs at the compiler level, but extending the pkg system seems like the right way to go.

It seems that a lot f the issues the author has they can fix by moving over to OpenBSD. I'd be curious to hear what makes them stick with FreeBSD instead considering the complaint.