FreeBSD's Close Call: How Flawed Code Almost Made It Into the Kernel

"40,000 lines of flawed code almost made it into FreeBSD's kernel," writes Ars Technica, reporting on what happened when the CEO of Netgate, which makes FreeBSD-powered routers, decided it was time for FreeBSD to enjoy the same level of in-kernel WireGuard support that Linux does. The issue arose after Netgate offered a burned-out developer a contract to port WireGuard into the FreeBSD kernel (where Netgate could then use it in the company's popular pfSense router distribution): [The developer] committed his port — largely unreviewed and inadequately tested — directly into the HEAD section of FreeBSD's code repository, where it was scheduled for incorporation into FreeBSD 13.0-RELEASE. This unexpected commit raised the stakes for WireGuard founding developer Jason Donenfeld, whose project would ultimately be judged on the quality of any production release under the WireGuard name. Donenfeld identified numerous problems...but rather than object to the port's release, Donenfeld decided to fix the issues. He collaborated with FreeBSD developer Kyle Evans and with Matt Dunwoodie, an OpenBSD developer who had worked on WireGuard for that operating system... How did so much sub-par code make it so far into a major open source operating system? Where was the code review which should have stopped it? And why did both the FreeBSD core team and Netgate seem more focused on the fact that the code was being disparaged than its actual quality? There's more to the story, but ultimately Ars Technica confirmed the presences of multiple buffer overflows, printf statements that are still being triggered in production, and even empty validation function which always "return true" rather than actually validating the data. The original developer argued the real issue is an absence of quality reviewers, but Ars Technica sees a larger problem. "There seems to be an absence of process to ensure quality code review." Several FreeBSD community members would only speak off the record. In essence, most seem to agree, you either have a commit bit (enabling you to commit code to FreeBSD's repositories) or you don't. It's hard to find code reviews, and there generally isn'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. Ars Technica published this statement from the FreeBSD Core Team: Core unconditionally values the work of all contributors, and seeks a culture of cooperation, respect, and collaboration. The public discourse over WireGuard in the past week does not meet these standards and is damaging to our community if not checked. As such, WireGuard development for FreeBSD will now proceed outside of the base system. For those who wish to evaluate, test, or experiment with WireGuard, snapshots will be available via the ports and package systems. As a project, we remain committed to continually improving our development process. We'll also continue to refine our tooling to make code reviews and continuous integration easier and more effective. The Core Team asks that the community use these tools and work together to improve FreeBSD. Ars Technica applauds the efforts — while remaining concerned about the need for them. "FreeBSD is an important project that deserves to be taken seriously. Its downstream consumers include industry giants such as Cisco, Juniper, NetApp, Netflix, Sony, Sophos, and more. The difference in licensing between FreeBSD and Linux gives FreeBSD a reach into many projects and spaces where the Linux kernel would be a difficult or impossible fit."

Read more of this story at Slashdot.



from Slashdot https://ift.tt/2NX7Cq0

SUBSCRIBE TO OUR NEWSLETTER

“Work hard in silence, let your success be your noise"

0 Response to "FreeBSD's Close Call: How Flawed Code Almost Made It Into the Kernel"

Post a Comment

ad

Search Your Job