"wireguard" implementation improperly merged and needs revert

[Jason A. Donenfeld]

Hi Taylor,

Thanks for your response. It seems like we both have the same goal --
a high quality WireGuard implementation in NetBSD -- but I think there
are a few subtleties I haven't conveyed right. I'll try to address
what you wrote and clarify what's up.

Sorry about not reaching out. The history is that the code has been
kicking around the NetBSD world since Ozaki-san first wrote it in
2018, without getting merged into src. It felt a shame to let it
wallow in that state indefinitely, and it seemed to be in pretty good
shape when I reviewed it this year, with a few small issues I saw, so
I dusted it off and merged it.

So that's the thing. Ozaki-san visibly didn't finish the
implementation. Writing a WireGuard implementation is a big
undertaking. You don't simply take somebody's in-progress code, dust
it off, fix a few kernel API particulars, and ship it. That's not a
WireGuard implementation; that's a slow motion disaster in the making.
I realize this might be a kind of strange idea to consider: most
kernel programming is easily evaluable if you're a kernel programmer,
and most network programming is easily evaluable if you're a network
programmer, and WireGuard involves both kernel code and network code,
and you are both an accomplished kernel programmer and an accomplished
network programmer. So this should be a "straightforward" task, right?
It turns out that this isn't the case at all. There's a decent amount
of unusual domain specific things that go into building a WireGuard
implementation, that simply takes time and patience to get right.
Sending packets that are decipherable by WireGuard implementations is
only half the picture in building an actual implementation. As I
mentioned in my earlier email, Matt spent over a year perfecting his
implementation for OpenBSD, and we did continual code reviews,
knowledge transfers, and he even showed up at my house at some point
to read code together. Now, I'm not insisting on anything as wild and
intense as that, but I mention it to illustrate that this isn't just
something you casually dust off and merge.

I would be happy to hear specific criticism of the code and its
implementation flaws and violations, and/or pointers to documentation
of the certain set of behaviours and security criteria that you expect
implementations to adhere to. Also happy to help answer questions
about and navigate the NetBSD network stack if you want to review it
yourself.
As far as I know, Ozaki-san wrote the code following the WireGuard
protocol paper. There are a few XXX comments in the code that should
be addressed, and there are some issues I know of that I have a small
TODO list for but didn't seem critical enough to block committing the
[ ] self-tests for crypto
[ ] fix libssh dependency
[ ] dtrace probes
[ ] lockless radix tree lookups for peers
[ ] take advantage of sys/crypto/chacha &c.
[ ] modularize
[ ] split sliding window out
[ ] rename wgconfig(8) -> wg(8) and make interface compatible

There's a *lot* more than that missing. What you committed is missing
whole components of WireGuard. It's not a complete implementation. And
in many places it's just plain incorrect. (I should note though -- the
code itself seems very nicely written and clean, and I have no doubt
that Ozaki-san is a brilliant programmer.) It's not productive or
reasonable to play whack-a-mole with that codebase; it's not at the
place where that makes sense.

This isn't about some random bug here or there, or a TODO list of
little errors and optimizations, or something that one would normally
say, "well, the bones are there, so let's throw this in the tree, and
we'll clean it up as a gradual evolutionary thing." Rather, the
foundation is incomplete, and its current form does not belong in a
tree. And more generally, I don't feel comfortable distributing
something that you call "wireguard" when it simply is not WireGuard,
and does not come with the same levels of scrutiny and completeness
that WireGuard implementations deliver.

For now, users have to go out of their way to enable the experimental
wg(4) interface, and I didn't have any specific timeline planned for
enabling it in GENERIC kernels -- wasn't likely to have been before
September 1st anyway and I'm happy to commit to holding off on that
until we've had a chance to discuss further in September. Does that
work?

In light of the above, I don't think that works. The right course of
action here is to revert the code, and then after we can evaluate
which direction we want to go in -- whether it's doing a full teardown
of Ozaki-san's code, or whether it's doing a simple port of the
OpenBSD code. That's something I would very much look forward to
talking to you about in September. So, can you move ahead with the
revert, and we can then evaluate our options for building an actual
WireGuard implementation? As I mentioned in my first email, my full
efforts and motivations are available in helping to make WireGuard a
reality on NetBSD; let's just do this right.

Thanks,
Jason

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[m***@NetBSD.org]

Yes, we get it, you took a trademark over the term WireGuard so we can't
use it, so you can send threatening emails about how you don't like the
changes. Why don't we just call it wg and get it over with?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Maxime Villard]

Post by Jason A. Donenfeld
Hi Taylor,
[...]

Your email more sounds like you haven't had time to look at the actual code
and try to have it reverted because you are frustrated that it was developed
without your benediction.

I understand your sentiment, but your email has obvious mischaracterizations.

To me the status is simple: Ozaki has a solid background of developing
network components, he wrote a wg implementation 2 years ago by carefully
following the spec, Taylor imported it a few days ago as a first shot, and
kept it disabled for the time being. Taylor then started making improvements.
That's how development happens.

Maybe it would have been wise to commit it to a separate branch for the time
being; but WireGuard is no very complex piece of engineering and I can
understand why Taylor decided to commit the code to the main tree right away.

I will note four things on the technical side:

(1) I am not sure we can actually import OpenBSD's code. The OpenBSD kernel
isn't remotely as MP-safe as NetBSD's, and a copy-pasta will likely add
more bugs than it fixes.
(2) I have noted some bugs in NetBSD's implementation, but they are for the
most part related to kernel API use.
(3) NetBSD has advanced bug detection features (KUBSAN, KASAN, KMSAN, KCSAN),
that simply do not exist in other OSes. These automatically detect bugs
and vulnerabilities at run time. That's a very strong capability we have
developed. You and Matt having reviewed code physically together sounds
nice and all; but humans can miss memory corruptions, the above features
do not.
(4) Considering the overall poor quality of code coming out of OpenBSD, I
wouldn't feel confident with us importing their code, whether it be wg,
or anything else at large.

All of this being said, I believe we are all interested in getting the best
possible WireGuard implementation, so let's not argue over unimportant
matters.

You and Taylor should definitely talk in September (in one week). Meanwhile
reverting the code altogether sounds like a very big step that so far has
received little technical justification. However, moving it to a development
branch would probably be a good move; it would eliminate the confusion as to
whether it is production-ready (which it isn't yet), while still allowing
people to make changes and development to happen. Jason/Taylor, does that
sound good to you?

Cheers,
Maxime

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Tom Ivar Helbekkmo]

[Very reasonable arguments, with which I agree]
However, moving it to a development branch would probably be a good
move; it would eliminate the confusion as to whether it is
production-ready (which it isn't yet), while still allowing people to
make changes and development to happen.

While there are certainly improvements that could be made (Taylor has
pointed some out, and I would add making it possible to do traffic
shaping in the tunnels using ALTQ), I have been happily using our wg
implementation for two years. While ozaki-r was writing the code, I
helped him debug it, and I've been using it since, communicating between
several instances of NetBSD on amd64 and aarch64, Linux on amd64, and
Android phones. It's been performing perfectly -- not surprising, as
ozaki-r very carefully implemented it to the published specification.

-tih

[Jason A. Donenfeld]

Hi Maxime,

Post by Maxime Villard
Your email more sounds like you haven't had time to look at the actual code
and try to have it reverted because you are frustrated that it was developed
without your benediction.
I understand your sentiment, but your email has obvious mischaracterizations.

No, actually, that isn't the case at all. I've spent several hours
with the code and have a few pages of notes, should Taylor decide that
going with Ozaki-san's code is preferable to the OpenBSD route. This
has nothing to do with spilled grapes or benediction anything like
that. Rather, what you've put in the tree isn't WireGuard; it's not a
correct or a complete implementation, and that's not something that
will be trivially fixed with a few fixes here and a few features
there. We need to take a big fundamental look at how the mechanics of
this are operating.

Post by Maxime Villard
To me the status is simple: Ozaki has a solid background of developing
network components, he wrote a wg implementation 2 years ago by carefully
following the spec, Taylor imported it a few days ago as a first shot, and
kept it disabled for the time being. Taylor then started making improvements.
That's how development happens.

I addressed this notion of "solid background" in my previous email to
Taylor. It seems very clear from reading his code that Ozaki-san is
indeed a terrific network programmer. That's a lot different, though,
from getting a WireGuard implementation secure and complete. For that
reason, I'm here offering to jump into this in basically boundless
capacity so that NetBSD can have an implementation. To be clear, I
come to this mailing list volunteering my own time and energy.

Post by Maxime Villard
Maybe it would have been wise to commit it to a separate branch for the time
being; but WireGuard is no very complex piece of engineering and I can
understand why Taylor decided to commit the code to the main tree right away.

A proper implementation of WireGuard *is* quite complex, actually. And
that misunderstanding is what's gotten us here. Again, see my previous
reply to Taylor. This isn't a matter of dusting off some old code that
sends packets or something; that simply won't cut it with WireGuard,
and pretending otherwise is incredibly irresponsible. I'll address
your other point about a separate branch below when it comes up again.

Post by Maxime Villard
(1) I am not sure we can actually import OpenBSD's code. The OpenBSD kernel
isn't remotely as MP-safe as NetBSD's, and a copy-pasta will likely add
more bugs than it fixes.

We tried to make the locking pretty granular and correct, and also
most of the crypto we've fully cordoned off into separate stand-alone
components. You might wind up being right in the end, though. This is
one of the things I wanted to look at with Taylor (and you, if you're
interested) in September. It may very well be the case that porting
the OpenBSD code is more arduous, though I suspect it will be less so.
We'll see, and I'm fully open to pursuing either possibility.

Post by Maxime Villard
(3) NetBSD has advanced bug detection features (KUBSAN, KASAN, KMSAN, KCSAN),
that simply do not exist in other OSes. These automatically detect bugs
and vulnerabilities at run time. That's a very strong capability we have
developed. You and Matt having reviewed code physically together sounds
nice and all; but humans can miss memory corruptions, the above features
do not.

I'm not sure this is a relevant technical point. The entire intent of
me writing to Taylor has nothing to do with fixing the inevitable slow
trickle of kernel programming bugs or network programming bugs, but
everything to do with the realities of WireGuard. I have no doubt that
the various instrumentation features in NetBSD will go a long way
toward resulting in a better codebase, and I look forward to
developing with those for whatever path we take.

Post by Maxime Villard
(4) Considering the overall poor quality of code coming out of OpenBSD, I
wouldn't feel confident with us importing their code, whether it be wg,
or anything else at large.

Again, I'm not sure this is a relevant technical point, and I *really*
don't want to wade into BSD political rivalries on a mailing list like
that. But I will say that neither Matt nor myself are actual OpenBSD
developers, so maybe you don't need to really have concern about the
pedigree.

Post by Maxime Villard
All of this being said, I believe we are all interested in getting the best
possible WireGuard implementation, so let's not argue over unimportant
matters.
You and Taylor should definitely talk in September (in one week). Meanwhile
reverting the code altogether sounds like a very big step that so far has
received little technical justification.

If you haven't noticed, I'm trying very hard not to get bogged down in
classic mailing list errors of secumbing to, "oh, there's a problem?
make a list of bugs for us and we'll prioritize them and then fix them
one by one," because that _entirely_ misses the point here, and the
current issues won't be coherently addressed in that manner.
Similarly, "but the code works for me for years, it sends packets"
also misses the point entirely. The right thing to do is back up the
truck a bit and reapproach the problem space more carefully.

Post by Maxime Villard
However, moving it to a development
branch would probably be a good move; it would eliminate the confusion as to
whether it is production-ready (which it isn't yet), while still allowing
people to make changes and development to happen. Jason/Taylor, does that
sound good to you?

Actually, yes, sure. If you want to put this in a "wgdev" branch, or
some such name, and move it out of the master development branch,
that'd be productive and also give us some more room to unpack things
-- specifically, a wg-specific feature branch, rather than a "next
version" branch or something. When I asked that you revert the code, I
didn't mean, "revert it and place it in the dumpster", but was more
thinking of moving it to a development tree somewhere, because with
Linux development, things usually work with individual developer
trees. If NetBSD has feature-development branches within its main
repository, that works well.I wouldn't want to totally discard
Taylor's improvements on Ozaki-san's code, especially as that might
wind up being the basis of our work on this moving forward. In other
words, wherever it makes sense to develop it, let's do that, so long
as we merge it to the master tree *not before* it's ready. (With that
said, is a cvs branch what you had in mind? Or does NetBSD have a
pretty established flow for git/hg feature development branches
instead?)

Jason

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Hello,

Post by Jason A. Donenfeld
[...]
A proper implementation of WireGuard *is* quite complex, actually. And
that misunderstanding is what's gotten us here. Again, see my previous
reply to Taylor. This isn't a matter of dusting off some old code that
sends packets or something; that simply won't cut it with WireGuard,
and pretending otherwise is incredibly irresponsible. I'll address
your other point about a separate branch below when it comes up again.

Maybe you should give more specific examples of what is missing or wrong
with the current code. You keep saying there are things wrong or missing but
you don't give examples, so for us followers, not familiar with the feature
(I didn't know about wireguard before taylor's commits), your mails looks
more rants than anything else.

Post by Jason A. Donenfeld
[...]

Post by Maxime Villard
However, moving it to a development
branch would probably be a good move; it would eliminate the confusion as to
whether it is production-ready (which it isn't yet), while still allowing
people to make changes and development to happen. Jason/Taylor, does that
sound good to you?

Actually, yes, sure. If you want to put this in a "wgdev" branch, or
some such name, and move it out of the master development branch,
that'd be productive and also give us some more room to unpack things
-- specifically, a wg-specific feature branch, rather than a "next
version" branch or something. When I asked that you revert the code, I
didn't mean, "revert it and place it in the dumpster", but was more
thinking of moving it to a development tree somewhere, because with
Linux development, things usually work with individual developer
trees. If NetBSD has feature-development branches within its main
repository, that works well.I wouldn't want to totally discard
Taylor's improvements on Ozaki-san's code, especially as that might
wind up being the basis of our work on this moving forward. In other
words, wherever it makes sense to develop it, let's do that, so long
as we merge it to the master tree *not before* it's ready. (With that
said, is a cvs branch what you had in mind? Or does NetBSD have a
pretty established flow for git/hg feature development branches
instead?)

Actually, in NetBSD, HEAD *is* the main developement branch.
We occasionally create dev branches for things that impact a large portion
of the tree or touch critical subsystems, but for things that are
self-contained and not enabled by defaut (and it looks like wg falls in
this category) a specific branch is usually not needed.

[Maxime Villard]

Post by Jason A. Donenfeld

Post by Maxime Villard
(4) Considering the overall poor quality of code coming out of OpenBSD, I
wouldn't feel confident with us importing their code, whether it be wg,
or anything else at large.

Again, I'm not sure this is a relevant technical point, and I *really*
don't want to wade into BSD political rivalries on a mailing list like
that. But I will say that neither Matt nor myself are actual OpenBSD
developers, so maybe you don't need to really have concern about the
pedigree.

I've given a 5-minute look at OpenBSD's if_wg.c file considered "production-
ready". 40 lines of code into the wg_input() entry point it looks like there
is already a vuln:

- if (m_defrag(m, M_NOWAIT) != 0)
+ if (m_defrag(m, M_NOWAIT) != 0) {
+ m_freem(m);
return NULL;
+ }

M_NOWAIT means the allocation can fail, if it fails 'm' needs to be freed,
otherwise it is leaked. The leak here means remote DoS of the kernel,
triggerable without authentication.

Post by Jason A. Donenfeld
[...]
If you haven't noticed, I'm trying very hard not to get bogged down in
classic mailing list errors of secumbing to, "oh, there's a problem?
make a list of bugs for us and we'll prioritize them and then fix them
one by one," because that _entirely_ misses the point here, and the
current issues won't be coherently addressed in that manner.
[...]

Sure, I understand. However, it is good to put some substance in the
criticism, at least as a clue, for people not to dismiss your remarks
as uninformed rant.

Post by Jason A. Donenfeld
[...]
Similarly, "but the code works for me for years, it sends packets"
also misses the point entirely. The right thing to do is back up the
truck a bit and reapproach the problem space more carefully.
[...]

I understand your concern.

Post by Jason A. Donenfeld
[...]
Actually, yes, sure. If you want to put this in a "wgdev" branch, or
some such name, and move it out of the master development branch,
that'd be productive and also give us some more room to unpack things
-- specifically, a wg-specific feature branch, rather than a "next
version" branch or something. When I asked that you revert the code, I
didn't mean, "revert it and place it in the dumpster", but was more
thinking of moving it to a development tree somewhere, because with
Linux development, things usually work with individual developer
trees. If NetBSD has feature-development branches within its main
repository, that works well.I wouldn't want to totally discard
Taylor's improvements on Ozaki-san's code, especially as that might
wind up being the basis of our work on this moving forward. In other
words, wherever it makes sense to develop it, let's do that, so long
as we merge it to the master tree *not before* it's ready. (With that
said, is a cvs branch what you had in mind? Or does NetBSD have a
pretty established flow for git/hg feature development branches
instead?)

Our main tree is cvs, but we are migrating to hg (anonhg.netbsd.org), and
also mirror our tree on github. So three options exist, but Taylor will
probably know better than me what's the best option.

As Manuel said, generally, for subsystems that are small and self-contained,
CVS-HEAD is the preferred development branch, which is why wg went there in
the first place.

But I don't think there is difficulty in moving the code to a separate
branch if you like it better there. What do Taylor/Ryota think?

Maxime

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Taylor R Campbell]

Date: Mon, 24 Aug 2020 16:37:36 +0200
Our main tree is cvs, but we are migrating to hg (anonhg.netbsd.org), and
also mirror our tree on github. So three options exist, but Taylor will
probably know better than me what's the best option.
As Manuel said, generally, for subsystems that are small and self-contained,
CVS-HEAD is the preferred development branch, which is why wg went there in
the first place.
But I don't think there is difficulty in moving the code to a separate
branch if you like it better there. What do Taylor/Ryota think?

Ozaki-san's wg(4) code was in a git branch for two years. As the
NetBSD network stack evolved, the wg(4) git branch was getting stale.
Having it in HEAD -- but not in any GENERIC kernels -- ensures it at
least stays tested and visible to anyone working on the network stack,
but users still have to go out of their way to use it. This makes it
less likely to accrue NetBSD-specific bugs, without endorsing it as
ready for serious deployment. And reverting and replaying would be a
big pain for me (not just a matter of `git revert' equivalent, for
certain technical reasons).

So, it is easy to read your (Jason's) request that we revert the
commits as the message -- whether you intended it this way or not --
that you want to parachute in to micromanage how we do development,
without actually engaging with how we do development first.

That's why you're getting some rather surprised pushback, and multiple
questions about the technical basis for your objection -- normally if
there's a dispute requesting a revert, it's over technical grounds
(and typically only if it affects users who are not going out of their
way to try experimental features), presented on a public mailing list.
If the parties don't come to an agreement then they can ask the core
team for a decision. But that decision often takes a couple of weeks.
(Disclosure: I'm on the core team, but I recuse myself from any
decisions about disputes involving me.)

So it strikes us as weird -- and, perhaps, rude -- that you're asking
us to urgently revert something that's been kicking around for two
years, just so that you can discuss in one week why it has to be
reverted and/or how it should be fixed.

I'm still happy to have that discussion! I am definitely curious to
hear what whole components are missing from the implementation and, as
far as I can tell, from your protocol documentation. But until then,
I don't think this thread is going anywhere, so I think it would be
better for us to all just wait until next week to discuss further when
you have time to go into technical details. NetBSD 10 is not going to
be released before then, let alone with wg(4) enabled.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

[..] NetBSD 10 is not going to
be released before then, let alone with wg(4) enabled.

Wearing my release engineering hat: I can definitively assert that
HEAD is *by far* not in a state that would allow us to branch for
netbsd-10 (the next upcoming release branch) in the next months.

Which is a sad story by itself, but gives you plenty of time to sort wg(4)
out properly before we even neeed to decide whether to enable it in the
release branch or not.

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jason A. Donenfeld]

Hi Taylor,

Post by Taylor R Campbell

Date: Mon, 24 Aug 2020 16:37:36 +0200
Our main tree is cvs, but we are migrating to hg (anonhg.netbsd.org), and
also mirror our tree on github. So three options exist, but Taylor will
probably know better than me what's the best option.
As Manuel said, generally, for subsystems that are small and self-contained,
CVS-HEAD is the preferred development branch, which is why wg went there in
the first place.
But I don't think there is difficulty in moving the code to a separate
branch if you like it better there. What do Taylor/Ryota think?

Ozaki-san's wg(4) code was in a git branch for two years. As the
NetBSD network stack evolved, the wg(4) git branch was getting stale.
Having it in HEAD -- but not in any GENERIC kernels -- ensures it at
least stays tested and visible to anyone working on the network stack,
but users still have to go out of their way to use it. This makes it
less likely to accrue NetBSD-specific bugs, without endorsing it as
ready for serious deployment. And reverting and replaying would be a
big pain for me (not just a matter of `git revert' equivalent, for
certain technical reasons).
So, it is easy to read your (Jason's) request that we revert the
commits as the message -- whether you intended it this way or not --
that you want to parachute in to micromanage how we do development,
without actually engaging with how we do development first.
That's why you're getting some rather surprised pushback, and multiple
questions about the technical basis for your objection -- normally if
there's a dispute requesting a revert, it's over technical grounds
(and typically only if it affects users who are not going out of their
way to try experimental features), presented on a public mailing list.
If the parties don't come to an agreement then they can ask the core
team for a decision. But that decision often takes a couple of weeks.
(Disclosure: I'm on the core team, but I recuse myself from any
decisions about disputes involving me.)
So it strikes us as weird -- and, perhaps, rude -- that you're asking
us to urgently revert something that's been kicking around for two
years,

For the record, the right thing to do would be to have sought input
from the WireGuard project during those two years, which we would have
enthusiastically provided, and maybe NetBSD would have this ready to
go years ago. It strikes the project as rude that you'd write some
halfbaked code and try to pass it off as "wireguard", ruining what to
date has been a uniform experience for users in using WireGuard across
platforms. The fact is, you jumped the gun and didn't reach out beyond
your community.

Post by Taylor R Campbell
I'm still happy to have that discussion! I am definitely curious to
hear what whole components are missing from the implementation and, as
far as I can tell, from your protocol documentation. But until then,
I don't think this thread is going anywhere, so I think it would be
better for us to all just wait until next week to discuss further when
you have time to go into technical details. NetBSD 10 is not going to
be released before then, let alone with wg(4) enabled.

So it sounds like you're unwilling to revert this or move it to a
development branch, for reasons I don't quite understand -- presumably
because of CVS limitations, but I guess it doesn't really matter. So
that means you've lit the so-called fire under my butt to do
everything I can to get this up to snuff before NetBSD 10 ships. I'll
do my best, then. How much time do we have? On the order of 2 or 3
months? A year?

Another question is -- since you're unwilling to revert, will you
still be okay with the situation if we wind up making _big_ changes to
what's there? Or even if we wind up replacing the implementation all
together?

Again, while I'm not happy with this situation and the inflexibility
here, my end goal is probably pretty similar to yours -- to have an
excellent WireGuard implementation on NetBSD. So I'll very willingly
follow your lead on the development processes to make that happen,
whatever they are. "Micromanag[ing]", as you charged, certainly isn't
something I'd like to inadvertently sign up for here.

Jason

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Jason A. Donenfeld
[...]
So it sounds like you're unwilling to revert this or move it to a
development branch, for reasons I don't quite understand -- presumably

What you seem to not get is that it *is* on a developement branch.

[Kamil Rytarowski]

Some input from me and answer to the raised questions. Generally
NetBSD-10 won't be branched in a few months (according to martin@).
After branching there is a period of a few months of stabilization and
bug fixes. We have got at least 6 months to do wireguard support
properly. Finishing this work before branching is beneficial and will
reduce the cost of backporting newer implementation to the branched
NetBSD-10. If you can present a list of advantages of your work in a
feature branch, show progress in the development process we are open for
coordination of the branching point after finishing your work.

Meanwhile it's not much gain to revert the code in HEAD. It's available
only to people using the development branch. Feel free to clone
https://github.com/netbsd/src, start a branch, revert locally what you
want to revert and introduce new support for NetBSD.

Once you will be done, just reach us with a patchset and we will review
it and merge.

One tricky part is that I don't know how much time Taylor or Ozaki can
invest into repeated process of development.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Taylor R Campbell]

Hi, Jason! NetBSD 10 is not likely to be released by the end of the
year -- if it is even branched by then. I'm happy to commit to
hearing you out when you have time to go into technical details in
September. Let's talk again when you're ready?

Thanks,
-Riastradh

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jason A. Donenfeld]

Hi Taylor,

Post by Taylor R Campbell
Hi, Jason! NetBSD 10 is not likely to be released by the end of the
year -- if it is even branched by then. I'm happy to commit to
hearing you out when you have time to go into technical details in
September. Let's talk again when you're ready?

Alright, it seems like that is what we shall do. Looking forward to
speaking with you in September. Poke me on IRC perhaps? I'm zx2c4 on
Freenode.

Jason

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jason A. Donenfeld]

Hi Maxime,

Post by Maxime Villard

Post by Jason A. Donenfeld

Post by Maxime Villard
(4) Considering the overall poor quality of code coming out of OpenBSD, I
wouldn't feel confident with us importing their code, whether it be wg,
or anything else at large.

Again, I'm not sure this is a relevant technical point, and I *really*
don't want to wade into BSD political rivalries on a mailing list like
that. But I will say that neither Matt nor myself are actual OpenBSD
developers, so maybe you don't need to really have concern about the
pedigree.

I've given a 5-minute look at OpenBSD's if_wg.c file considered "production-
ready". 40 lines of code into the wg_input() entry point it looks like there
- if (m_defrag(m, M_NOWAIT) != 0)
+ if (m_defrag(m, M_NOWAIT) != 0) {
+ m_freem(m);
return NULL;
+ }
M_NOWAIT means the allocation can fail, if it fails 'm' needs to be freed,
otherwise it is leaked. The leak here means remote DoS of the kernel,
triggerable without authentication.

Thanks, I'll pass that onto the OpenBSD networking guys if you haven't
already done so.

It wouldn't surprise me if there are kernel programming bugs of that
sort; that code is new, and stabilization is happening in the OpenBSD
tree (I hope?). Bugs like that are squarely within the realm of issues
that are incrementally fixed with successive code reviews. Were
NetBSD's "wireguard" implementation in that situation, I'd feel fine
about it, and just put my time into doing usual security audits and
submitting boring patches and such. But that's not my concern here

Post by Maxime Villard

Post by Jason A. Donenfeld
[...]
If you haven't noticed, I'm trying very hard not to get bogged down in
classic mailing list errors of secumbing to, "oh, there's a problem?
make a list of bugs for us and we'll prioritize them and then fix them
one by one," because that _entirely_ misses the point here, and the
current issues won't be coherently addressed in that manner.
[...]

Sure, I understand. However, it is good to put some substance in the
criticism, at least as a clue, for people not to dismiss your remarks
as uninformed rant.

But rather, this is my concern -- that the issue isn't just a TODO
list of little bugs here and there. I really don't want to get drawn
into that kind of mailing list rabbit hole. And I don't think that
anybody here seriously considers me "uninformed" on the particulars of
WireGuard. These mailing list discussions are windy and thorny, and
asking people to revert stuff is already a huge party foul. And as you
can see, I got baited into responding to totally irrelevant discussion
on "Mozilla's lawyers" or something? Rather, I'm trying to keep this
really focused: I think the code was merged prematurely, but if you're
serious about having a WireGuard implementation, I'm serious about
helping, so let's move this to a development branch and revert it from
the main one, and then we can go head first into that.

Post by Maxime Villard
Our main tree is cvs, but we are migrating to hg (anonhg.netbsd.org), and
also mirror our tree on github. So three options exist, but Taylor will
probably know better than me what's the best option.

Cool. Whatever the SCM particulars wind up being is fine with me. I
was mostly just curious at the mention of branches in this context
because I know a lot of cvs-based projects avoid them.

Anyway, it seems like this thread is at risk of veering dangerously
off course into something a lot more disruptive and provocative than
initially planned. I hope we can just throw this in a branch, and then
Taylor and I can dive into it heads-down come September, and deliver
something that works great for everyone.

Jason

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jason A. Donenfeld]

Hi Maya,

Post by m***@NetBSD.org
Yes, we get it, you took a trademark over the term WireGuard so we can't
use it, so you can send threatening emails about how you don't like the
changes. Why don't we just call it wg and get it over with?

Huh? What's a trademark have anything to do with this at all? The name
is trademarked so that some rogue company doesn't make "wireguard
antivirus" or something and confuse the heck out of everyone, the same
way that "Linux" is trademarked by Linus, and the way that "NetBSD" is
trademarked by the NetBSD Foundation. It's not something meant to have
any effect on projects like NetBSD, let alone those I have immense
respect for, again like NetBSD. So, please leave that stuff out of it.
It's really entirely unrelated, a red herring, and something that's
sure to kick up lots of flames here without good reason.

No, this discussion here is motivated by precisely the opposite
concern: I *care* about NetBSD, and I want it to have an
implementation that I would be proud to send WireGuard users to use,
and encourage people to build things on, and hold it up and say, "this
here is a WireGuard implementation; use it!" I observed that the haste
of the integration here is not likely to yield that result, so I'm
asking to put the breaks on, and volunteering my development time to
make that happen.

So, before you direct others to go crazy with the legal-baiting,
please consider that this is motivated out of a respect for the NetBSD
project, not some other weird motivation involving trademark law.

Jason

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[nia]

The best way to have avoided this would have been to do some
research into how NetBSD is developed - asking for a revert doesn't
make sense and was bound to produce a flame war.

It's turned off in default builds, we're far off a stable release,
this code has been around for years already, etc etc. Developers should
have been contacted directly with any concerns, rather than this
being crossposted to 3 of our lists.

Post by Jason A. Donenfeld
Huh? What's a trademark have anything to do with this at all? The name
is trademarked so that some rogue company doesn't make "wireguard
antivirus" or something and confuse the heck out of everyone, the same
way that "Linux" is trademarked by Linus, and the way that "NetBSD" is
trademarked by the NetBSD Foundation. It's not something meant to have
any effect on projects like NetBSD, let alone those I have immense
respect for, again like NetBSD. So, please leave that stuff out of it.
It's really entirely unrelated, a red herring, and something that's
sure to kick up lots of flames here without good reason.
No, this discussion here is motivated by precisely the opposite
concern: I *care* about NetBSD, and I want it to have an
implementation that I would be proud to send WireGuard users to use,
and encourage people to build things on, and hold it up and say, "this
here is a WireGuard implementation; use it!" I observed that the haste
of the integration here is not likely to yield that result, so I'm
asking to put the breaks on, and volunteering my development time to
make that happen.
So, before you direct others to go crazy with the legal-baiting,
please consider that this is motivated out of a respect for the NetBSD
project, not some other weird motivation involving trademark law.
Jason

We went down this road because of your usage of the word ""wireguard""
(in quote marks). Combined with some casual reading of the Wireguard
trademark policy, it makes it seem like you do not believe things
may call themselves Wireguard until you are personally happy with
them (or are involved with them in some way).

The NetBSD trademark exists to stop people from selling branded
NetBSD merchandise with nothing going back to the Foundation, and
similar situations. There are reimplementations of NetBSD APIs
such as in MINIX and it would not make sense to restrict those
from referencing NetBSD(tm) in their documentation or source code.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de