Hacker News Reader

Comment by jimmar | Hacker News Reader

I'd read that WireGuard was supposed to be easier to implement because it supports fewer distinct crypto protocols and has fewer features overall compared to OpenVPN. But now this code is being pulled. Was it just a rushed implementation? Or is WireGuard harder to implement than initially thought?

View on HN

There was concern about code quality, and accusations of what amounted to amateur mistakes in Netgate's particular implementation. I don't know how accurate those accusations are, though.

They were made by Jason Donenfeld, the author of WireGuard which is of exemplary quality so I take it pretty seriously :)

It's possible to browse the before-changes-started version of the FreeBSD code, through either CVS or the FreeBSD Git mirror. To save people the effort of finding the right git revision and the path, the kernel module starts here: https://github.com/freebsd/freebsd-src/tree/95331c228a39b44c...

On a casual inspection, there are at least kernel printfs in crypto code in __chacha20poly1305_decrypt (in module/crypto/zinc/chacha20poly1305.c) that were not in the original version of this from Linux.

The original version would be GPL v2 right? If that's the case it'd make sense that the two don't match because you can't reuse the code for FreeBSD. You'd want a completely clean implemention just to avoid any appearance of impropriety, unless the new implementation was done by the copyright holder themselves.

That particular file seems to have been taken from Jason A. Donenfeld's original, which was dual-licensed GPLv2 or MIT and so legal to import (under MIT) into FreeBSD. I don't know which upstream version of the file it comes from, but it's definitely very close to the version in https://github.com/WireGuard/wireguard-monolithic-historical .

Wireguard works really well in OpenBSD since like November. I find it WAY less painful to use than openvpn. I switched clients over to this implementation and they're happy as clams. Incredibly easy to set up and use, all out of a base install of a rock solid operating system that got this introduced without any kerfuffle. I think one of the weirdest sticking points about how ridiculous this whole situation is how they didn't even try to write this with that already-done implementation in mind, even after this was suggested by jason... It would have made their job a lot easier

> I think one of the weirdest sticking points about how ridiculous this whole situation is how they didn't even try to write this with that already-done implementation in mind, even after this was suggested by jason... It would have made their job a lot easier

Absolutely Agree.

The whole thing is pretty crazy and makes me lose even more respect for Netgate than I had already[1].

Also, as a long time FreeBSD user, it also makes me worried about the quality of other things in FreeBSD now, if this was _almost_ allowed to get shoehorned in, in such bad condition. Not sure if this is just an unlucky one-off, or a sign of deeper problems in FreeBSD development (not enough devs, process problems, etc).

[1]: the whole opnsense stuff was super distasteful https://en.wikipedia.org/wiki/OPNsense#cite_note-7

Someone from netgate implemented it poorly and then the original authors tried to fix it in a hurry but ran out of time. There was also some mailing list drama I think.

See https://news.ycombinator.com/item?id=26475519

Reply on news.ycombinator.com