Live data from Hacker News

In-kernel WireGuard is on its way to FreeBSD and the pfSense router

arstechnica.com

131–140 of 167 posts

Re: In-kernel WireGuard is on its way to FreeBSD and the pfSense router

#131
post #73

Earlier quoted context omitted.

He did trademark the name. I don't think Jason is going to tell the FreeBSD project that they can't use the name "wireguard" for their implementation of "wireguard" just because Netgate put out shoddy code. It's not the FreeBSD project's fault. https://www.wireguard.com/trademark-policy/

I don't think this is an accurate description of the responsibility hierarchy. If in fact the code by Netgate or associates/ contractors/ employees of Netgate is not of professional quality, it has no place in the FreeBSD codebase ready for a stable release. Ultimately, the FreeBSD core community/ developers are together responsible for the codebase even if you cannot hold them legally accountable because of the lice…

I think this is my favorite comment in the whole thread. The reasons you outline are exactly how I feel when it comes to priorities here, and how I feel his conduct was -- Despite everything maintaining friendliness while being attacked for making technical criticisms was incredibly commendable.

Re: In-kernel WireGuard is on its way to FreeBSD and the pfSense router

#132
post #68
post #66

Earlier quoted context omitted.

LOL, my first thought was that you were talking about Theo.

I think he was. :)

Btw. great gathering of people with a *BSD background or friends :-)

I think, we all should be way more cool headed. Email doesn't contain the tone and it is very easy to formulate something in a bad way when exhausted or upset. Some people use very strong words that considering their usual style aren't nearly as strong in reality.

In this case, the great question is, how did such a bad code (according to Jason) land in the code base at all? Don't other people look at it? Do the FreeBSD developers ignore concerns of other fellow developers until it blows up to beyond community communication circles?

Re: In-kernel WireGuard is on its way to FreeBSD and the pfSense router

#133
post #68

Earlier quoted context omitted.

I think he was. :)

Btw. great gathering of people with a *BSD background or friends :-) I think, we all should be way more cool headed. Email doesn't contain the tone and it is very easy to formulate something in a bad way when exhausted or upset. Some people use very strong words that considering their usual style aren't nearly as strong in reality. In this case, the great question is, how did such a bad code (according to Jason) land…

It makes sense to me. As I understand the FreeBSD mailing list posts, it was commissioned commercially, to add a feature to NetGate products.

Must have: in-kernel WireGuard for NetGate products.

Nice-to-have: a general-purpose FreeBSD kernel WireGuard.

The scope crept, and a piece of code that might have been fit for some purpose (whatever limitations NetGate has for its network stack, like "no jumbo frames", etc) was recast as fit for all purposes.

I guess Colin would have some insight about the process by which a ports-grade kernel module gets put on track for release in the kernel itself.

My take on this is that absolutely no part of the development process that led up to this is Jason's problem. It is not Jason's job to understand or assist or comply with NetGate's product development process; his concern seems to have been, justifiably, exclusively the proposed FreeBSD OS feature. I get the sense that a lot of the friction here comes from pfSense-types thinking that any part of pfSense is everyone's problem.

Re: In-kernel WireGuard is on its way to FreeBSD and the pfSense router

#134
post #90

Earlier quoted context omitted.

I get your point about perceptions, but there's also another aspect of why I found it important and necessary to describe just how poor the code was: When you're talking about replacing and rewriting the implementation on the eve of release, you better have a good reason for doing so. Stuffing a rewrite of security critical code into the kernel at the last minute is a big red flag. The main question that immediately…

You did good, Jason. Honestly after this streissand effect from them taking technical criticism personally and threatening you, I'm probably just going to avoid anything using code they might have written... that's on them. Responding to a perceived non-professionalism by talking like that to you -- from their COMPANY EMAIL at that? If I were their boss I'd definitely start making some considerations regarding the ir…

> If I were their boss I'd definitely start making some considerations regarding the irony of this.

Unfortunately this type of behaviour is par for the course for Netgate/pfSense.

Re: In-kernel WireGuard is on its way to FreeBSD and the pfSense router

#135

Earlier quoted context omitted.

I'm not sure that over 10 years later is "as soon as they could". NetGate has made a huge number of open source releases, and while they have not held exactly to the platonic ideal of open source (literally every bit on the disc comes from an open repo) I think we can all agree that the vast majority of the existing CE code remains open. I also think that they get a lot of shade because some of their developers have…

> At this time, which future will develop is anyone's guess; I suspect even NetGate don't really know. Even if they're planning on effectively abandoning CE in place, a backlash in the community could cause that to reverse. It seems like a certainty that users will shift over to the free version of pfSense Plus for the eventual performance advantages, if not for the REST API alone, and then pfSense CE will slowly wit…

A possibility, sure. Not a very likely one, but don't let me keep you from your doom-and-gloom :)

Re: In-kernel WireGuard is on its way to FreeBSD and the pfSense router

#136

Earlier quoted context omitted.

You did good, Jason. Honestly after this streissand effect from them taking technical criticism personally and threatening you, I'm probably just going to avoid anything using code they might have written... that's on them. Responding to a perceived non-professionalism by talking like that to you -- from their COMPANY EMAIL at that? If I were their boss I'd definitely start making some considerations regarding the ir…

> If I were their boss I'd definitely start making some considerations regarding the irony of this. Unfortunately this type of behaviour is par for the course for Netgate/pfSense.

Yeah we don't let them in to the fun defcon parties

Re: In-kernel WireGuard is on its way to FreeBSD and the pfSense router

#137

Earlier quoted context omitted.

Btw. great gathering of people with a *BSD background or friends :-) I think, we all should be way more cool headed. Email doesn't contain the tone and it is very easy to formulate something in a bad way when exhausted or upset. Some people use very strong words that considering their usual style aren't nearly as strong in reality. In this case, the great question is, how did such a bad code (according to Jason) land…

It makes sense to me. As I understand the FreeBSD mailing list posts, it was commissioned commercially, to add a feature to NetGate products. Must have: in-kernel WireGuard for NetGate products. Nice-to-have: a general-purpose FreeBSD kernel WireGuard. The scope crept, and a piece of code that might have been fit for some purpose (whatever limitations NetGate has for its network stack, like "no jumbo frames", etc) wa…

Thank you for the reply. Yes, I understand Jason is basically only involved as "I have looked at this thing you propose/ have in FreeBSD and I don't like what I see, let me improve/ discuss further plans".

My question basically is: "How is it possible, the code of such quality was even seriously included in a branch of FreeBSD that would have been released if nobody would step in?" (That is if I understand the whole thing correctly and Jason's assessment is correct.)

Re: In-kernel WireGuard is on its way to FreeBSD and the pfSense router

#138

Earlier quoted context omitted.

It makes sense to me. As I understand the FreeBSD mailing list posts, it was commissioned commercially, to add a feature to NetGate products. Must have: in-kernel WireGuard for NetGate products. Nice-to-have: a general-purpose FreeBSD kernel WireGuard. The scope crept, and a piece of code that might have been fit for some purpose (whatever limitations NetGate has for its network stack, like "no jumbo frames", etc) wa…

Thank you for the reply. Yes, I understand Jason is basically only involved as "I have looked at this thing you propose/ have in FreeBSD and I don't like what I see, let me improve/ discuss further plans". My question basically is: "How is it possible, the code of such quality was even seriously included in a branch of FreeBSD that would have been released if nobody would step in?" (That is if I understand the whole…

I also think, if you dedicate something like 5 years of your life solely to kernel C implementations of a single protocol, it's probably a lot easier for you to spot problems than it is for an arbitrary FreeBSD developer.

Re: In-kernel WireGuard is on its way to FreeBSD and the pfSense router

#139

Note that there's additional follow-up available here: https://lists.freebsd.org/pipermail/freebsd-hackers/2021-Mar...

Absolutely the best outcome. BSDs has always been ( to me at least ) about getting things right, take time to get it baked before committing. The old, out of fashion style of getting things done properly and not shipping for the sake of it. Which is both a good thing and a bad thing in the modern world. But it is a trade off.

I also hope FreeBSD sort of look into why it was committed in the first place.

Hopefully this also set the tone for Scott and Netgate. Even having mild scepticism of the one sided bash to them on HN had me downvoted into oblivion.

Re: In-kernel WireGuard is on its way to FreeBSD and the pfSense router

#140

Link to relevant announcement email: https://lists.zx2c4.com/pipermail/wireguard/2021-March/00649... There's also Jason's reply to apparently not-nice feedback of someone from NetGate: https://lists.zx2c4.com/pipermail/wireguard/2021-March/00649...

The patch, showing the fixes made: https://cgit.freebsd.org/src/commit/?id=74ae3f3e33b810248da1...

It's a rewrite from scratch in many respects; the diff isn't meant to be meaningful.
Post reply on HN