Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

arstechnica.com

Post reply on HN
Print view View original

81–90 of 167 posts

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

#81

Post by kbenson »

tw04 wrote: post #57
kbenson wrote: post #28

Earlier quoted context omitted.

That was my impression too, then I went back a couple prior messages, and looked at the earlier announcement. Wihle Netgate looks to have overreacted (at least from the info we have), I can understand why they would be upset. This was in the original announcement: The first step was assessing the current state of the code the previous developer had dumped into the tree. It was not pretty. I imagined strange Internet…

Keep in mind, back in February of 2020 when Kip Macy first announced that Netgate had hired him to port Wireguard, Jason offered to help. First Kip declines the offer, then seems to warm slightly to it, but ultimately appears to have not actually engaged Jason. If I'm Jason and I offer my help (for free), they don't take me up on my offer, then try to release code that would make my baby look quite ugly, I would prob…

> Could Jason have been slightly more professional? Absolutely. But we're all human and I can't entirely blame him

Oh, I don't entirely blame him. I just partially blame him for not seeing the obvious way this could devolve into a problem, even if it would (justifiably) seem unlikely to go to this level so fast. That is, he shouldn't be surprised there was a problem with what he said, although the scope of the problem is a bit more than I think most would expect.

Professionalism isn't just about making others feel good, it's about optimizing for useful outcomes, which includes covering yourself. Not taking care with your words is just like not taking care with your code. Sometimes there's a weird interaction and things go boom.

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

#82

Post by frankharv »

WarOnPrivacy wrote: post #22
tw04 wrote: post #12

Earlier quoted context omitted.

Community Edition will diverge from Pfsense+ with the 2.6 release. They have also made no commitments there will be any releases after that - "it's up to the community". They will, however, gatekeep what features the community is allowed to add. Community Edition is more or less a dead man walking at this point, they just refuse to come right out and say that. Someone asked if they'd allow one of the REST API project…

In my case, I don't readily find hostility toward a group that has busted tail to provide me tremendous value while I have contributed very little in return. My interactions over the years have been - perhaps not exclusively positive but overwhelmingly so. History says one day pfSense will no longer fill my needs. Okay. I'll raise an imaginary glass move on with gratitude.

Well instead of pfSense no longer fulfilling your needs than maybe its time to beam up to the mothership. FreeBSD can do everything pfSense does without a web interface.

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

#83

Post by darkwater »

kevans91 wrote: post #50

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

Came here to post that, looks like they are pulling out the recent effort

EDIT: removed the "and revert to the original freebsd (broken?) implementation"

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

#84

Post by api »

JStanton617 wrote: post #46
sschueller wrote: post #33

Im confused, pfsense 2.5 is out and has wireguard support. Is that version full holes I should be aware off?

Yes. The code you're running is described as having "random sleeps added to “fix” race conditions, validation functions that just returned true, catastrophic cryptographic vulnerabilities, whole parts of the protocol unimplemented, kernel panics, security bypasses, overflows, random printf statements deep in crypto code, the most spectacular buffer overflows" This is a kernel RCE just waiting to happen.

> random sleeps added to “fix” race conditions

That's just horrifying. It shows someone who knows next to nothing about multithreaded code and is kludging their way through. Not someone you want within a hundred feet of anything other than maybe front-end web, and even there they're going to be the kind of person who blocks the node.js event loop (because async coding is like the junior cousin of multithreading).

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

#85

Post by tw04 »

ksec wrote: post #75
tw04 wrote: post #58

Earlier quoted context omitted.

> it surely isn't in a professional and business world especially when the work is sponsored ( being paid ). To play devil's advocate: Netgate isn't paying Jason, and they're taking his open source code to create a proprietary commercial project. I'd say Jason owes them exactly nothing in the way of courtesy or consideration. Could he have been more polite for the sake of being polite and community goodwill? Probably…

>and they're taking his open source code to create a proprietary commercial project. I am not sure if that is the case. Netgate seems to have used their old crappy sponsored work for their Pfsense. That is judging from the two pieces of information here. Jason doesn't need to be of consideration for Netgate. There could be other communication we dont know about. I can certainly understand why Scott is frustrated.

>I am not sure if that is the case. Netgate seems to have used their old crappy sponsored work for their Pfsense.

Their sponsored work was based off of the Linux and OpenBSD code that Jason and others wrote. And even if it didn't utilize that code, you literally can't write a wireguard client without building on Jason's work.

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

#86

Post by stonogo »

Jonnax wrote: post #11
andrius4669 wrote: post #4

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...

Wow. Netgate come off as incredibly unprofessional. According to the article linked and the info here in that email you linked this is my conclusion: * Netgate tried to ship flawed code that has multiple security issues. * Jason Donenfeld, one of the lead Wireguard developers, went out of his way to work on rewriting it to be better in time for the 13.0 release of FreeBSD * This Netgate employee is angry that they we…

NetGate spends a lot on FreeBSD development, which is great, but they also spend a lot of time running smear campaigns against people who offend them, which is ridiculous. They even started /r/opnsense on Reddit just to post shit-talking memes, and camp on the namespace to this day.

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

#87

Post by kbenson »

tptacek wrote: post #79
kbenson wrote: post #74

Earlier quoted context omitted.

> It's not an elaborate insult. My read on it wasn't that it was an elaborate insult, but more that it was far more denigrating than it needed to be, if he was trying to be professional. That doesn't mean it was purposeful, sometimes people just don't really associate the statements they make with how it may be perceived. I think it could have been communicated clearly and succinctly with something along the lines of…

Sure, but it's easy to clinically examine any communication and refine it with the benefit of both hindsight and low cortisol levels. My read of this situation is that everyone involved was stuck in a shitty situation; it got very briefly heated, and ended up where it should have: with another dev cycle to iterate on FreeBSD WireGuard.

I agree on both counts, but I think (constructive) criticism is warranted in a mistake. To absolve Jason of all responsibility would be to possibly not provide that useful feedback of why not to do this the same way next time.

Hopefully I accurately expressed that as what I was trying to convey. I don't think Jason is close to even half the problem in this case, just the small spark that allowed it to continue and explode (continue because is started with a substandard implementation to begin with). At the same time, he's also the one easier to critique constructively because the other party is hard to relate to (I'm not one to jump to conspiracy theories about implicit efforts to defame).

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

#88

Post by anoki »

annoyingnoob wrote: post #9
lambda_obrien wrote: post #3

I'll have to take a look at freebsd, does anyone have a good reference to the differences in a bsd versus Linux?

If it helps, OSX is based on BSD. I've had great success with pfSense. I found great tuning advice here: https://calomel.org Edit: Not sure why I'm getting down votes for trying to provide info. I didn't down vote anything in this thread.

I didn't downvote but it could be you got some downvotes because calomel has a bad reputation among BSD people. They have put bad and dangerous advice in their tuning and performance posts. People who follow this advice and shoot themselves in the foot sometimes come to the mailing lists looking for help, and it turns out their problems were caused by copy pasting from an unofficial source instead of reading and understanding the documentation.

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

#89

Post by cperciva »

darkwater wrote: post #83
kevans91 wrote: post #50

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

Came here to post that, looks like they are pulling out the recent effort EDIT: removed the "and revert to the original freebsd (broken?) implementation"

WireGuard is gone from the kernel in 13.0-RELEASE. Given the choice between "buggy" and "less than a week old", we're going with the third option of "you can ship a kernel module via the ports tree".

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

#90

Post by zx2c4 »

kbenson wrote: post #74
tptacek wrote: post #67

Earlier quoted context omitted.

It's not an elaborate insult. To a much greater extent than in other security protocols, implementation security is a goal of WireGuard. The protocol itself was designed to support secure kernel implementations; for instance, it's designed in such a way as to not require on-demand dynamic memory allocation. It's part of the premise of the security model of WireGuard that it has secure kernel implementations. If you'r…

> It's not an elaborate insult. My read on it wasn't that it was an elaborate insult, but more that it was far more denigrating than it needed to be, if he was trying to be professional. That doesn't mean it was purposeful, sometimes people just don't really associate the statements they make with how it may be perceived. I think it could have been communicated clearly and succinctly with something along the lines of…

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 comes up in that context is, "how is it possible that having a last minute rewrite would be better than the code that was there before? You've only looked at this for a week." And that's a really good and important question.

That much code churn is not something I wanted when I set out to get started with this, but it's ultimately where things wound up. Why? For exactly the reasons I described in my email. The idea wasn't to be _insulting_, but rather to accurately and vividly describe the state of the code, as a motivating factor for the rewrite. I see how perceptions could view that instead as denigrating, but that wasn't really the motivation. And it's not as though anybody really is rushing to defend that code either; it doesn't take a lot to look at that and make up your mind that it was probably unfinished stuff, not coded with much love, that was committed prematurely.

It also had the, I think, positive effect of leading to more scrutiny of the review process. A few people have piped up and mentioned to me that their concerns during that review weren't addressed. And as a consequence of everything, all of the code, including the rewrite, is being removed from FreeBSD until it can be carefully examined and completed, which is really the best of conclusions.

Post reply on HN