9 ms·

Link to relevant announcement email: https://lists.zx2c4.com/pipermail/wireguard/2021-March/006494.html https://lists.zx2c4.com/pipermail/wireguard/2021-March/0

Link to relevant announcement email: https://lists.zx2c4.com/pipermail/wireguard/2021-March/006494.html 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/006499.html https://lists.zx2c4.com/pipermail/wireguard/2021-March/00649...

Jonnax 6y ago
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 weren't able to ship their bad code and starts throwing accusations of a smear campaign. Am I understanding what happened correctly? Because it really makes this Firewall/Router look really bad.
- kbenson 6y ago
  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 voices jeering, “this is what gives C a bad name!” There were 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, and the whole litany of awful things that go wrong when people aren’t careful when they write C. Or, more simply, it seems typical of what happens when code ships that wasn’t meant to. It was essentially an incomplete half-baked implementation – nothing close to something anybody would want on a production machine. Matt had to talk me out of just insisting they pull the code entirely, and rework it more slowly and carefully for the next release cycle. I can understand being upset if that's how you're portrayed publicly.
  - Jonnax 6y ago
    Well if it's true, then they were trying to put flawed code into freebsd which they would then ship to customers in their security product. They're not some random person but are representing their company with their code. If there was a security exploit with their Wireguard implementation, would Netgate get blamed or Wireguard?
  - deleted 6y ago
    [deleted]
  - ksec 6y ago
    Similar reaction here. My first impression was Netgate being an arse. But then when you read the announcement I kind of understand why Scott is angry. Because while the post may have been in "good faith" in an Open Development and Open Source world, it surely isn't in a professional and business world especially when the work is sponsored ( being paid ). Jason should have informed Netgate the quality of the code is shit in private and FreeBSD dev should have told Netgate will not be shipping any of it in Rel 13. It is then up to Netgate to decide What to do with their Rel 2.5
    - tptacek 6y ago
      WireGuard is an open-source project, and an important one. It seems to me that if you want to push to create the authoritative WireGuard implementation for a major open source OS, the commercial norms need to take a back seat.
    - tw04 6y ago
      > 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.
      - ksec 6y ago
- stonogo 6y ago
  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.
seany 6y ago
Netgate is weirdly hostile to a lot of opensource stuff, which should be strange given what all their tech is built on top of. This has been going on for years. (see opnsense etc)
- cperciva 6y ago
  Netgate funds a lot of FreeBSD work, and employs FreeBSD committers. I certainly wouldn't describe them as hostile to open source.
  - WarOnPrivacy 6y ago
    I didn't know that. That's kind of awesome.
  - droopyEyelids 6y ago
    It seems clear to me this is a case of passionate coders with different personalities struggling with the difficult work of human communication in a world with limited resources and time. No one has to be the bad guy here or end up hostile to open source.
  - tomxor 6y ago
    Perhaps entitled is the right word then.
    - cperciva 6y ago
      Maybe. It's not necessarily without reason -- if you make a lot of contributions and they are generally very well received, it's quite sensible to anticipate that further contributions will be equally well received and to be surprised if they're not. This was made worse by the unfortunate timing -- the final release candidate is just 3 days away. Any other time, we would have gone slower, had more discussion, et cetera; unfortunately this turned into an emergency.
  - tedunangst 6y ago
    They can be a touch snotty towards developers who aren't freebsd committees.
megous 6y ago
Good read, I saved crypto.{c,h} for later use. Nice and tidy crypto code.
bjustin 6y ago
Jason's reply is an impressive display of de-escalation. The NetGate person's message has a lot of hostility and Jason really doesn't return any of it. Hope NetGate comes around to working with the WireGuard maintainers more in the future.
Arnavion 6y ago
Damage control: https://www.netgate.com/blog/painful-lessons-learned-in-security-and-community.html https://www.netgate.com/blog/painful-lessons-learned-in-secu...
- geofft 6y ago
  tl;dr: "The developer of the project whose protocol I'm reimplementing and whose trademark I'm using to sell things is an attacker with ulterior motives. Anyway, everyone should be respectful and leave their egos at their door. Everyone else, that is.'
1vuio0pswjnm7 6y ago
The patch, showing the fixes made: https://cgit.freebsd.org/src/commit/?id=74ae3f3e33b810248da19004c58b3581cd367843 https://cgit.freebsd.org/src/commit/?id=74ae3f3e33b810248da1...
- loeg 6y ago
  It's a rewrite from scratch in many respects; the diff isn't meant to be meaningful.
secondcoming 6y ago
> But perhaps this is a good moment to step back and ask how we got here, and what WireGuard itself really is. > Traditionally, network protocols are specified in a document of protocol behaviors. Then different organizations implement that specification. Then everybody interoperates and all goes well. In practice, it often doesn’t go well (see IPsec woes), but this at least has been the traditional way of doing this on the Internet, and in some ways it works. > But that is not the approach taken by the WireGuard project. In contrast, WireGuard is both a protocol and a set of implementations, implemented with a particular set of security and safety techniques. That’s a radical departure from the traditional model, and one surely to raise some grumbles amongst graybeards. But I believe this is a necessary and beneficial quality for having the types of high assurance software that is needed for core Internet security infrastructure. When you use WireGuard, you’re not just using some protocol that is capable of producing packets that are legible by others. You’re also using an implementation that’s been designed to avoid security pitfalls, and that provides interfaces for using it that mitigate footguns. In that way, the WireGuard project is more expansive than a mere protocol project or a mere software project or a mere cryptography project or a mere specification project or a mere interface project. It combines all of those things into a single unified approach. (For this same reason, the original WireGuard paper [2] has been difficult for folks to categorize. Is this a systems paper? A networking paper? A crypto paper?) > Because of that, I think this was an understandable predicament. After all, why shouldn’t a company be able to task a developer with writing some ring-0 WireGuard code in C? And why does it matter to me whether the code is garbage if it can at least produce protocol packets? The reason is that the WireGuard project’s mission is wider than that. We deeply care about code quality and implementation particulars. > While we now have the FreeBSD code in a maintainable state, there are other projects too that could use some attention from us. I get that WireGuard is his baby, but sweet jesus...
- tptacek 6y ago
  It's not clear what your objection is here.
jchw 6y ago
This isn’t even the only NetGate debacle. There is also the mess that lead to OPNsense. All in all, I’ve sworn off buying NetGate hardware despite it looking great in theory.

Jonnax 6y ago

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 weren't able to ship their bad code and starts throwing accusations of a smear campaign. Am I understanding what happened correctly? Because it really makes this Firewall/Router look really bad.

kbenson 6y ago
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 voices jeering, “this is what gives C a bad name!” There were 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, and the whole litany of awful things that go wrong when people aren’t careful when they write C. Or, more simply, it seems typical of what happens when code ships that wasn’t meant to. It was essentially an incomplete half-baked implementation – nothing close to something anybody would want on a production machine. Matt had to talk me out of just insisting they pull the code entirely, and rework it more slowly and carefully for the next release cycle. I can understand being upset if that's how you're portrayed publicly.
- Jonnax 6y ago
  Well if it's true, then they were trying to put flawed code into freebsd which they would then ship to customers in their security product. They're not some random person but are representing their company with their code. If there was a security exploit with their Wireguard implementation, would Netgate get blamed or Wireguard?
- deleted 6y ago
  [deleted]
- ksec 6y ago
  Similar reaction here. My first impression was Netgate being an arse. But then when you read the announcement I kind of understand why Scott is angry. Because while the post may have been in "good faith" in an Open Development and Open Source world, it surely isn't in a professional and business world especially when the work is sponsored ( being paid ). Jason should have informed Netgate the quality of the code is shit in private and FreeBSD dev should have told Netgate will not be shipping any of it in Rel 13. It is then up to Netgate to decide What to do with their Rel 2.5
  - tptacek 6y ago
    WireGuard is an open-source project, and an important one. It seems to me that if you want to push to create the authoritative WireGuard implementation for a major open source OS, the commercial norms need to take a back seat.
  - tw04 6y ago
    > 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.
    - ksec 6y ago
stonogo 6y ago
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.

seany 6y ago

Netgate is weirdly hostile to a lot of opensource stuff, which should be strange given what all their tech is built on top of. This has been going on for years. (see opnsense etc)

cperciva 6y ago
Netgate funds a lot of FreeBSD work, and employs FreeBSD committers. I certainly wouldn't describe them as hostile to open source.
- WarOnPrivacy 6y ago
  I didn't know that. That's kind of awesome.
- droopyEyelids 6y ago
  It seems clear to me this is a case of passionate coders with different personalities struggling with the difficult work of human communication in a world with limited resources and time. No one has to be the bad guy here or end up hostile to open source.
- tomxor 6y ago
  Perhaps entitled is the right word then.
  - cperciva 6y ago
    Maybe. It's not necessarily without reason -- if you make a lot of contributions and they are generally very well received, it's quite sensible to anticipate that further contributions will be equally well received and to be surprised if they're not. This was made worse by the unfortunate timing -- the final release candidate is just 3 days away. Any other time, we would have gone slower, had more discussion, et cetera; unfortunately this turned into an emergency.
- tedunangst 6y ago
  They can be a touch snotty towards developers who aren't freebsd committees.

megous 6y ago

Good read, I saved crypto.{c,h} for later use. Nice and tidy crypto code.

bjustin 6y ago

Jason's reply is an impressive display of de-escalation. The NetGate person's message has a lot of hostility and Jason really doesn't return any of it. Hope NetGate comes around to working with the WireGuard maintainers more in the future.

Arnavion 6y ago

Damage control: https://www.netgate.com/blog/painful-lessons-learned-in-security-and-community.html https://www.netgate.com/blog/painful-lessons-learned-in-secu...

geofft 6y ago
tl;dr: "The developer of the project whose protocol I'm reimplementing and whose trademark I'm using to sell things is an attacker with ulterior motives. Anyway, everyone should be respectful and leave their egos at their door. Everyone else, that is.'

1vuio0pswjnm7 6y ago

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

loeg 6y ago
It's a rewrite from scratch in many respects; the diff isn't meant to be meaningful.

secondcoming 6y ago

> But perhaps this is a good moment to step back and ask how we got here, and what WireGuard itself really is. > Traditionally, network protocols are specified in a document of protocol behaviors. Then different organizations implement that specification. Then everybody interoperates and all goes well. In practice, it often doesn’t go well (see IPsec woes), but this at least has been the traditional way of doing this on the Internet, and in some ways it works. > But that is not the approach taken by the WireGuard project. In contrast, WireGuard is both a protocol and a set of implementations, implemented with a particular set of security and safety techniques. That’s a radical departure from the traditional model, and one surely to raise some grumbles amongst graybeards. But I believe this is a necessary and beneficial quality for having the types of high assurance software that is needed for core Internet security infrastructure. When you use WireGuard, you’re not just using some protocol that is capable of producing packets that are legible by others. You’re also using an implementation that’s been designed to avoid security pitfalls, and that provides interfaces for using it that mitigate footguns. In that way, the WireGuard project is more expansive than a mere protocol project or a mere software project or a mere cryptography project or a mere specification project or a mere interface project. It combines all of those things into a single unified approach. (For this same reason, the original WireGuard paper [2] has been difficult for folks to categorize. Is this a systems paper? A networking paper? A crypto paper?) > Because of that, I think this was an understandable predicament. After all, why shouldn’t a company be able to task a developer with writing some ring-0 WireGuard code in C? And why does it matter to me whether the code is garbage if it can at least produce protocol packets? The reason is that the WireGuard project’s mission is wider than that. We deeply care about code quality and implementation particulars. > While we now have the FreeBSD code in a maintainable state, there are other projects too that could use some attention from us. I get that WireGuard is his baby, but sweet jesus...

tptacek 6y ago
It's not clear what your objection is here.

jchw 6y ago

This isn’t even the only NetGate debacle. There is also the mess that lead to OPNsense. All in all, I’ve sworn off buying NetGate hardware despite it looking great in theory.