[axaxs]

Yeah, same.

Even if all of the above is true, it reads like an elaborate insult. And that's fine if that what the author set out to do for some reason. Pretending it wasn't after the fact isn't being honest, in my opinion.

A more professional and neutral announcement could just talk about code that needs to be refactored due to some incompleteness and vulnerabilities.

[tptacek]

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're building a kernel WireGuard implementation for a major open source OS without taking advantage of the WireGuard implementation design concepts, you're not really building WireGuard; you're building a compatible fork and calling it "WireGuard".

The "ask" here from Jason was for everyone to slow their roll, take the flawed WireGuard implementation out of the tree, and give everyone a chance to make it more resilient. Considering the amount of work Jason had to go through to get WireGuard into the Linux tree, that seems like a very reasonable request.

Instead, the WireGuard project seems to have been put into a position where they had to scramble to fix up an implementation that was being pushed into FreeBSD, as WireGuard qua WireGuard. I can imagine that being a frustrating experience. It certainly didn't generate the most political response ever, but I think you'd be reaching to call it a deliberate insult.

[kbenson]

> 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: "The first step was assessing the current state of the code the previous developer had dumped into the tree. We noticed some quality problems, some unimplemented protocol sections and more concerning, security issues with the code. Given these issues, we considered asking they remove the code, but instead Matt convinced me that we should rework it slowly and carefully for the next release cycle."

Notably, I think omission of the following inflammatory statements would have prevented a lot of problems:

- "It was not pretty."

- "I imagined strange Internet voices jeering, “this is what gives C a bad name!”"

- "the most spectacular buffer overflows"

- "the whole litany of awful things that go wrong when people aren’t careful when they write C."

Whether those entirely subjective statements are accurate, they are not the things you say about someone else's work output when you expect a useful dialogue with them, which is exactly why they are considered unprofessional.

I'm not defending Netgate's code here, or even the vehemence of their reaction and how they went about it, but merely noting that not only can I see how it devolved into this, I would go so far as to say it's obvious that this is why that type of language is avoided by most people trying to work professionally. Jason wrote some very unkind things, and Netgate blew up about it. There's enough blame here that they can both share some.

> The "ask" here from Jason was for everyone to slow their roll, take the flawed WireGuard implementation out of the tree, and give everyone a chance to make it more resilient. Considering the amount of work Jason had to go through to get WireGuard into the Linux tree, that seems like a very reasonable request.

Err, wasn't that actually not the ask, because he thought they wouldn't do so, so instead they worked it over in a short time-frame, only for it then to be removed when this argument broke out and it came to light?

[zx2c4]

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.

[jamal-kumar]

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 irony of this.

[deadbunny]

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

[jamal-kumar]

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

[donmcronald]

I can see how someone could be insulted by that one paragraph on a personal level, especially if it had been the person that wrote the code. I can't think of a nice way to say it though.

However, on a professional level, when a core maintainer of a protocol tells you your code is bad, it's time to sit down, eat some humble pie, and start taking notes. I think that's especially true if you're offering help or are willing to address online communities with positive messaging to help them save face.

I think you handled it really well. I almost feel sorry for Netgate that they lashed out at someone so good at managing the technical (code), social (community), and political (bullshit) sides of a software project. Almost.

[kaliszad]

May I ask, how is it possible the previous code was in the code base at all when it was of so poor quality?

Btw. thank you (and all the people that probably help you here and there) for Wireguard. I put a lot of trust into You/ Wireguard and I am hardly the only one. So I am all for quality and security even if it takes as long as it takes. It is really a huge progress we have a useable and _simple_ VPN protocol and widespread implementations of it.

[kbenson]

> The idea wasn't to be _insulting_

Sure, I didn't really interpret it as you attempting to be insulting, more that you were accidentally insulting through your explanation of what you found.

> but rather to accurately and vividly describe the state of the code, as a motivating factor for the rewrite

Sure, but is any of that really needed beyond "there were numerous security problems we had to address"? When talking about shipping crypto, I think most involved would agree not shipping it is better than shipping something possibly exploitable.

I think the core of what I was trying to express is that words should be crafted with care when expected to be read in a public forum like this, just like any code expected to be used by many should be crafted with care. For the same reason it's useful to remove quadratic algorithms from places where the input is somewhat not entirely vetted, it's useful to take care with words to reduce the chance of misinterpretation.

That doesn't mean scour your statements for the smallest possible misinterpretation, but there's a lot of room to improve things like "I imagined strange Internet voices jeering, “this is what gives C a bad name!”" while still expressing your point constructively. The low hanging fruit is easy to pick, so you might as well pick it.

To be clear, I feel for you with regards to this situation. Nobody really expects weird accusations like you got from simple emails, and that's on Netgate, but a less extreme response that also publicly notes the soured relationship would also be a negative outcome from this in my opinion, if one of lower magnitude.

[tptacek]

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.

[kbenson]

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

[justaj]

If the criticism is about the code instead of the person, it should never be interpreted as an insult. Proper developers have learned to split their ideas from their ego, and as such are able to receive harsh yet justified criticism concerning their code without being offended.