Removing WireGuard Support From FreeBSD Base

[Gordon Bergling]

Hi Gordon,

I am not sure, if the removal is a great idea, a removal from
releng/13 and stable/13 - possibly yes, but from main?
This is still -CURRENT and -CURRENT should be central place for development,
even if we have phabricator for review.

It looks like Kyle has gone ahead with the revert anyway, so
https://git.zx2c4.com/wireguard-freebsd/
https://lists.zx2c4.com/pipermail/wireguard/2021-March/006518.html
As for your objections, and the question of what -CURRENT should or
shouldn't be used for, I really have no idea as a community outsider.
But I do look forward to submitting it for proper inclusion in
-CURRENT after a few more cycles of development and refinement.
https://lists.freebsd.org/pipermail/freebsd-hackers/2021-March/057076.html

If the complete backout is happening, please don't forget the manual
page. I have spend a lot of time on it, while OpenBSD made a good
template.

Thanks for bringing this up; I had actually forgotten about that. Do
you want to re-add it and keep that current as we develop? If you
email me your SSH key, you can just commit it directly.
Jason

Thanks for the reply. I still think that the removal from main was a mistake,
but it has happened.

I'll create a port for WireGuard tomorrow so that FreeBSD isn't losing WireGuard
support at all, for whatever reason.

--Gordon

[Jason A. Donenfeld]

Hi Jeffrey,

In the next day or so, I will be committing a removal of all WireGuard
related bits from our 'main' branch, including the work that I recently
committed. It will be followed up by a removal of the implementation
from stable/13, and we will seek appropriate approval to remove it
from releng/13.0 as well. Please, do not be concerned by any of this;
this is being done with mutual support from all parties.

The thing I find unusual is, the move appears to lack technical
justification. The best I can tell, the reasons seem to be political.
But like I said, maybe my feeds are missing something...
As a naive outsider, if you are going to yank it, then the technical
reasons for the action should be clearly enumerated. Everything else
is just chatter or noise. The move just looks like a bunch of bruised
egos and sour grapes.

I'd just like to chime in and point out that although this is
happening in a political context as you've pointed out, this is in my
opinion the *best possible technical situation*, and the one I would
have preferred in the beginning anyway if it were presented as a
choice.

Here's the technical background you asked for:
- We found tons of issues with the original code base.
- We spent a week rewriting that codebase.
So here's the rationale:
- Merging a week-old codebase into an operating system kernel is a bad idea.

It's really not more complicated than that. I'm *sure* we'll find more
things to fix. That's just the nature of it.

And from a practical perspective, it's a lot easier for me, anyway, to
casually push fixes as I code to a normal repo on git.zx2c4.com. When
there's a lot of potential code churn, sometimes it's easiest to be
able to move fast at first. When we get it to a place where we feel
extra good about it, then we can do the full review process on what
we've got, which has the added benefit of even more eyeballs and ways
of looking at things. I think the code will benefit from this type of
process.

Maybe a good middle ground would be to take the existing code and put
it in a Wireguard branch. Those who wish to keep Wireguard out of
FreeBSD mainline have done so. FreeBSD users who wish to use Wireguard
can build the Wireguard branch. And those who wish to improve
Wireguard have a working branch for patches. Later, the branch can be
re-merged back to master.

We're actually going to do something like that already. We'll have it
as an out-of-tree module, since it's fairly standalone anyway. And
then when it's ready, we'll send that for merging back into the
FreeBSD main branch. Also, from a technical perspective, dealing with
out of tree modules on FreeBSD seems way, way easier than on Linux.
There's not nearly as much API churn, as far as I can see. We probably
can even offer prebuilts at some point for people who want to test out
snapshots. So I'm really not very worried (at least at the moment; I'm
still new to FreeBSD kernel development).

Jason

[Jason A. Donenfeld]

Hi Kyle,

I think what you describe is a great plan. I think everybody realizes
at this point that the original code base from the original author
never should have been merged. We went head first in trying to fix it
in a week because we thought that was our only choice. But knowing now
that we can simply remove it, and get back to coding it carefully and
deliberately, is just a huge relief. So that's great. And while it's
under development, we can have an out-of-tree repo for folks to test
out intermediate snapshots and provide feedback, just like the
WireGuard project has always done. In other words, we'll follow the
tried and true formulation of: slow, careful coding + regular
snapshots to receive testing and feedback.

So, I'm quite happy there. And when it is ready, I'm confident it'll
get a thorough review from FreeBSD core developers, which is terrific.
More review ==> better code.

I also want to thank you for your words about Netgate and the various
parties involved. I think nobody wants animosity and tension, and I
imagine your email has helped to calm the tone quite a bit. That's
just the type of reset we need, so that we can get back to what we do
best: writing and refining code.

To others reading, with regards to actual project logistics, I think
what I wrote in the original announcement still stands: we'll have
instructions for module building and such online and we'll announce it
here. And for developers interested, Kyle, MattD, and I have been
coordinating code writing on IRC; if you'd like to join in, ping one
of us there and we'll get you up to speed on repos and ssh keys
whatnot.

Regards,
Jason

[Jason A. Donenfeld]

Hi Kyle,

involved with this announcement that I'm leaving it for now. There's
been too much press surrounding this, and it's distracting me from the
work that I like to do and what I'm typically known for.

Makes sense and is understandable. It's been pretty miserable for all of us.

It looks like we'll eventually find somebody on the FreeBSD side of
things to take over where you left off, but hopefully for now in the
coming weeks things can just level out to some tranquility, so we can
get back to distraction-free coding without all the drama.

Jason