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
>> We still need to protect the unique identity and reputation of >> WireGuard (our "brand"). If someone feels this way about it, in my opinion it should be summarily yanked out and never, ever, EVER let back in - at least if there is any legal force behind that attitude. NetBSD's users already have enough of legal morass to navigate; making it worse only, well, makes it worse. Maybe unbranding is enough. Personally, I'm not confident that it is, and it's NetBSD's users' necks - in many jursidctions - on the legal line, not the Foundation's or the Project's. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
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
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 &c. [ ] 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
