Buffer overruns, license violations, and bad code: FreeBSD 13’s close call

When I was younger and had more time, I loved the BSDs. FreeBSD seemed so coherent, I loved the ports collections etc. And FBSD had a reputation for good code. From 2000-2004 I ran FBSD exclusively on my servers. Then slowly, FBSD seemed to start to splinter. First Matt Dillon took off for DragonflyBSD and then I started using Linux more. When I needed a firewall, I chose OpenBSD because Theo seemed to have a tight (some would say too tight) grip on the project.<p>When FBSD integrated ZFS, I took a look and decided that while I love that file&#x2F;storage system, FBSD itself had turned more into a lesser version of itself. Perhaps this was due to more pressure from Linux, and fewer developers&#x2F;contributors.<p>This entire Wireguard debacle has pretty much turned me off ever using FBSD again. From the inclusion of Sendmail as the default MTA (really? over Postfix) to the lack of development control outlined in this article, I can&#x27;t trust it.<p>Perhaps Theo&#x27;s strategy was the better path.

This is an incredibly good piece of journalism. It gives tangible examples of the issues found, puts it in context of prior work done by the developer, features first-hand verification of the claims made against the code; the author reached out for comment to all the parties involved.<p>I&#x27;m also consistently impressed by the quality of comments at Ars Technica whenever I visit the site.<p>This convinced me to subscribe. We need more journalism of comparable quality.

This does not paint FreeBSD in a good light.<p>“you either have a commit bit (enabling you to commit code to FreeBSD&#x27;s repositories) or you don&#x27;t. It&#x27;s hard to find code reviews, and there generally isn&#x27;t a fixed process ensuring that vitally important code gets reviewed prior to inclusion. This system thus relies heavily on the ability and collegiality of individual code creators.”<p>From my perspective, this whole thing is due to a severe failure of the development process. The sub-standard code should never have been committed. But if there is no process, is it really a failure? Or is this just how it is on FreeBSD?

Having deployed Netgate PFsense hardware at my last 3 startups words cannot express how disappointed I am in this. I have also recommended them to others. I understand that mistakes happen, but I feel their response was utter garbage. Unfortunately I am done with them and will have to find another option for the future. We need a project to put a web GUI on PF on OpenBSD (while I can sort the .conf files, not everyone can).<p>Thank you to Jason Donenfeld (Wireguard), Kyle Evans (FreeBSD) and Matt Dunwoodie (OpenBSD) for jumping in and fixing this in a week!

A note on the article it lists as one of the code flaws &quot;Validation functions which simply return true&quot;.<p>That got me thinking what&#x27;s so bad about returning true? What should they be returning?<p>Then I realized that what article must is trying to complain about is: &quot;Validation functions which ALWAYS return true&quot;.

Good that folks on FreeBSD have proper controls that stopped the problem before it was released, and shame on Ars Technica for bringing completely irrelevant 10+ year old eviction dispute into an article about technical issues as if it were relevant. This bullshit needs to stop. I mean I get that the guy may have some issues, and burnout is a very real thing, and if the code is low quality then it needs to be addressed, but it shouldn&#x27;t be &quot;oh and also his code is bad because of 10-year old story that has nothing to do with the code in question&quot;. We really can do without this stuff, and if they just dropped that whole section, the article would be much improved.

FreeBSD shipped <i>sendmail</i>, for how many years? Is it actually still in ports?

LWN had a good story on this too: + [WireGuard bounces off FreeBSD—for now (LWN.net)](<a href="https:&#x2F;&#x2F;lwn.net&#x2F;SubscriberLink&#x2F;850098&#x2F;3daef578513bff15&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lwn.net&#x2F;SubscriberLink&#x2F;850098&#x2F;3daef578513bff15&#x2F;</a>)

So some Twitter grand inquisitors, whose names always seem to appear if individuals are targeted, discovered some unpleasant details about someone&#x27;s past.<p>Code quality (especially when written under pressure) is unrelated to that and I&#x27;ve seen horrible code from from model citizens who check all the Twitter boxes of goodness.<p>It seems very dangerous to contribute to open source these days if you are not in the right Twitter cliques.<p>The nice thing is that the FreeBSD developers who were interviewed apparently remained fair and said that the target had produced high quality code before.