Removing WireGuard Support From FreeBSD Base

[Jason A. Donenfeld]

Hi Jeffrey,

On Tue, Mar 16, 2021 at 11:16 AM Jeffrey Walton <noloader at gmail.com> wrote:
> > 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