Re: "wireguard" implementation improperly merged and needs revert
Hi Nia, On Mon, Aug 24, 2020 at 5:57 PM nia wrote: > > Hi Jason, > > > We still need to protect the unique identity and reputation of > > WireGuard (our "brand"). This ensures that when people see the > > WireGuard name or logo, they know it is something we, the > > WireGuard developers, have worked on." > > Personally, I would be in favour of entirely rebranding the NetBSD > implementation to avoid this, because it's only introducing ourselves > to potential legal problems. > > It's important that the NetBSD tree remains as free as possible, and > that nobody introduce themselves to potential legal pain by modifying > any part of it. > > We have also had a similar discussion with Mozilla's lawyers and > simply opted to unbrand all of their software which we distribute. > > If only certain people can develop implementations of this protocol, > this is not an open protocol. Please read the reply I just wrote to Maya on tech-net: https://mail-index.netbsd.org/tech-net/2020/08/24/msg007855.html where I basically covered this already. I think you've been misled by others' comments into somehow thinking this is related to trademark stuff, when it isn't at all. And this isn't a situation with "Mozilla's lawyers" or something either; there's no comparison, simply because a "trademark" is simply not part of this discussion here -- i.e. were the question to come up when we're all ready to go here about NetBSD using the name WireGuard to describe its implementation, the answer would be an "of course" and if the question were then, "can you put that in writing?" the answer would be, "yea, sure, why not." This also doesn't have anything to do with "who implements the protocol". Rather, the issue here is that NetBSD doesn't actually implement WireGuard and its protocol. There's a lot more to WireGuard than just crafting some packets that sometimes have the right crypto. I'm afraid that Ozaki-san's code has been picked up with too much haste and not enough study, and we're going to get into an ugly situation if we don't put the breaks on now, before expectations run too high, and reevaluate/restudy. And just to put this discussion back into perspective, I *like* the NetBSD project and I *want* to have everything work as smoothly as possible, and I'm volunteering my *own development time* into helping to make that happen. All I'm asking is that this trajectory here is slowed so that we can do it right. Because I care about getting it right. Jason
Re: "wireguard" implementation improperly merged and needs revert
Hi Jason, > We still need to protect the unique identity and reputation of > WireGuard (our "brand"). This ensures that when people see the > WireGuard name or logo, they know it is something we, the > WireGuard developers, have worked on." Personally, I would be in favour of entirely rebranding the NetBSD implementation to avoid this, because it's only introducing ourselves to potential legal problems. It's important that the NetBSD tree remains as free as possible, and that nobody introduce themselves to potential legal pain by modifying any part of it. We have also had a similar discussion with Mozilla's lawyers and simply opted to unbrand all of their software which we distribute. If only certain people can develop implementations of this protocol, this is not an open protocol.
Re: "wireguard" implementation improperly merged and needs revert
On Sat, Aug 22, 2020 at 08:35:39PM +0200, Jason A. Donenfeld wrote: > > In its current form, there are implementation flaws and violations > that I do not consider acceptable, and deploying this kind of thing is > highly irresponsible and harmful to your users. Can you please explain what these (heck, what even _one_ of these) are? As far as I know the code was written following the published documentation. That's how Internet protocol development works, is it not? Thor
"wireguard" implementation improperly merged and needs revert
Hi Taylor/Ozaki-san/NetBSD developers, I'm very excited that NetBSD is enthusiastic about WireGuard. Having more deployment of WireGuard is always great to hear. And NetBSD is really a terrific project. I've been enthusiastic about using it for rump kernels for many years, and adding WireGuard capability there sounds great. WireGuard is not just a protocol; the project also comprises a set of implementations that meet a certain set of behaviors and security criteria. I would be very happy to have a proper WireGuard implementation inside of NetBSD. However, I think you've gravely jumped the gun attempting to add "wireguard" support to NetBSD. It's with great sadness that I ask you to revert those commits from yesterday that added it, until we can actually work on this together to make a real WireGuard implementation. I've had no communication with Taylor/Ozaki-san or other NetBSD developers about this, and can't find any record of anyone reaching out to me, which is a bummer. But now that we're in touch, I'd like to offer full support of these efforts, from myself and from the project in general. In about a week (~Sept 1), I'll be back at my desk full time, and will have tons of energy to throw at this, in order to get this code up to snuff. In its current form, there are implementation flaws and violations that I do not consider acceptable, and deploying this kind of thing is highly irresponsible and harmful to your users. Rather than playing never ending whack-a-mole misery with this -- which is not a path I'm willing to go down here -- I'd like to re-examine how this is built from the ground-up and do some serious code study. Some background: recently, as I'm sure you're aware, WireGuard shipped for OpenBSD. This was a year+ effort, with Matt and I working closely together to get a high quality WireGuard implementation. And actually, we wrote that to be as reusable by other BSDs as possible. It seems like it might be possible to inherit a lot of that code, which has already been refined and debugged, for NetBSD. This is, for example, what we're currently working on for the upcoming FreeBSD implementation. On the other hand, if Ozaki-san is wedded to his codebase, and believes there are distinct and important advantages to its structure, I have no objection to working with him on that as a starting point. In other words, I have no desire to impose anything unwanted on NetBSD engineering trajectory in this, but if you're going to land a WireGuard implementation, it needs to be done right, and I gladly volunteer my time and energy into helping to make that happen. So, it's a bit of a shame that this is my "hello, " email to the NetBSD community -- I would have liked to meet you all more jovally -- but I feel very strongly about not ruining WireGuard. And what you committed yesterday simply is not a WireGuard implementation. Could you please move ahead with reverting that, and starting on Sept 1, I'll make myself available to work with you on actually getting things rolling properly? I can be available as much as is needed on IRC or video chat or whatever other form works best for working together. I would really appreciate that, and it would get us off on the right foot, instead of the current rocky road we're staring down. Thanks, Jason
Re: "wireguard" implementation improperly merged and needs revert
[followups to tech-net to reduce cross-posting noise] Hi, Jason! 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. 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 initial work: [ ] self-tests for crypto [ ] fix libssh dependency [ ] dtrace probes [ ] lockless radix tree lookups for peers [ ] take advantage of sys/crypto/chacha [ ] modularize [ ] split sliding window out [ ] rename wgconfig(8) -> wg(8) and make interface compatible 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? Thanks, -Riastradh
Re: "wireguard" implementation improperly merged and needs revert
> On Aug 22, 2020, at 11:35 AM, Jason A. Donenfeld wrote: > > it needs to be done right, Can you be specific about what is wrong? -- thorpej
