The comment I left on a Reddit thread four years ago still applies:
> This link gets shared around every now and then, and my response is always the same: there is some useful insight, but there's also information that's so outdated it provides no value, outright misinformation, and self-contradiction. Some of the technical points are fair, and should be and are being addressed. But the commentary is often laughably wrong. The document seems more focused on advancing an agenda than a good-faith effort at improving security in FreeBSD.
If anyone is actually interested in discussing mitigations and improved security posture on FreeBSD I'd suggest starting a thread on one of the mailing lists, but I'll also keep an eye out for feedback here and on the Fediverse.
A lot of Linux kernel drivers are permissively licensed, or dual-licensed with a choice of GPL and a permissive license. This is especially common for vendor-developed drivers. From a hardware vendor’s perspective, broad license compatibility directly supports adoption: the more operating systems, hypervisors, and embedded environments that can incorporate the driver code, the wider the potential market for the hardware itself.
32-bit x86 CPUs haven't been made in years, companies building products based on FreeBSD switched to 64-bit x86 or to other architectures long ago. It's not that work on i386 is being done but kept in private repos and not upstreamed -- work on i386 just isn't being done at all.
Note that the bug that is the topic of discussion here predates OpenZFS. Whether or not there has been a slide in disciplined development in OpenZFS, this bug does not support that assertion.
I suspect your question is essentially "why is this 14.0, and not 13.3?" And the answer to that question is that this is a new release from our development branch, not an update to an existing branch used for the 13.x releases.
FreeBSD 14.0 represents over two and a half years of feature development, stability and security improvements, and bug fixes. Some of these changes were cherry-picked into the stable/13 branch and were included in the FreeBSD 13.1 and FreeBSD 13.2 minor releases built from there.
A sibling comment notes that APIs or ABIs may change between major versions. This is true, but this is not the reason for a new major version. Rather, ABI and API changes are allowed during the development cycle on the main branch, but are not cherry-picked into the existing stable branches.
I have a proposed change to include in the release notes some significant changes that happened to have been merged into 13.x already, and so far have been excluded from 14.0's notes: https://reviews.freebsd.org/D42546
I'm sure Colin's results can be reproduced, but it will take some effort. Colin has been doing a lot of work so that Firecracker can boot FreeBSD -- see https://www.daemonology.net/blog/2022-10-18-FreeBSD-Firecrac... for an introduction -- and that is not yet all available in Firecracker "out of the box."
The FreeBSD Foundation and FreeBSD Project members have been investing in and working on improving FreeBSD security for at least the last several years. Much of that "FreeBSD – A Lesson in Poor Defaults" blog post is outdated/incorrect/conjecture.
> The only orgs that tend to use BSD tend to not want to give back.
This isn't true. Looking at the last year of git commits I see significant contributions from a large number BSD-using companies and organizations. Looking at the top of the list (roughly sorted by commit count) we have:
The FreeBSD Foundation
Netflix
Rubicon Communications, LLC ("Netgate")
Klara, Inc
Juniper Networks, Inc.
Beckhoff Automation GmbH & Co. KG
NVIDIA Networking
Chelsio Communications
DARPA
AFRL
NetApp, Inc.
Arm Ltd
Axcient
Microsoft
Intel Corporation
Amazon, Inc.
vStack
UKRI
Innovate UK
Stormshield
Modirum MDPay
iXsystems, Inc
Instituto de Pesquisas Eldorado (eldorado.org.br)
Citrix Systems R&D
Dell EMC Isilon
There are a couple of (admittedly high-profile) companies that use FreeBSD in their proprietary products with limited contribution to the community, but they are very much in the minority.
The blog post offers the linked reply to support the claim that FreeBSD "blatantly disregards security in favor of performance and appeasing their enterprise consumers."
If you actually read the thread that response is taken from (starting at https://lists.freebsd.org/pipermail/freebsd-arch/2020-May/01...) you'll see a wholly different picture: a FreeBSD developer proposed a change, there was general agreement with a small amount of opposition including the cherry-picked message, and the change was made.
The FreeBSD src git repo has hundreds of thousands of commits, and anyone can post to mailing lists, so of course it's possible to find examples of mistakes being made, or misguided posts from developers or users.
I very much welcome constructive criticism and ideas for improving the security landscape within FreeBSD.
tcp_wrappers is still there because it provides functionality not otherwise available that is still used, and has a relatively small impact on the attack surface.
The linked blog post gives the impression that little has changed, but it is very much not the case.
Taking a look at the first section, "OpenSSH Modifications" - rather little of it is current. With respect to ciphers disabled by default in upstream we may follow along in main but leave them enabled in a stable/release branch, in an attempt to avoid breaking existing users while deprecating increasingly insecure options over time. We do indeed add support for tcp_wrappers back in. With respect to the base system I think the rest of the section is not applicable.
It used to have a section at the bottom that described changes made in FreeBSD (negating some of the points made above), but it has since been deleted.
> This link gets shared around every now and then, and my response is always the same: there is some useful insight, but there's also information that's so outdated it provides no value, outright misinformation, and self-contradiction. Some of the technical points are fair, and should be and are being addressed. But the commentary is often laughably wrong. The document seems more focused on advancing an agenda than a good-faith effort at improving security in FreeBSD.
If anyone is actually interested in discussing mitigations and improved security posture on FreeBSD I'd suggest starting a thread on one of the mailing lists, but I'll also keep an eye out for feedback here and on the Fediverse.