5 ms·
I you read the thread on NetBSD mailing list I linked to, that was exactly my concern: the spec does not seem to be enough to implement the protocol according t
by throwaway-jeN0S 6y ago
I you read the thread on NetBSD mailing list I linked to, that was exactly my concern: the spec does not seem to be enough to implement the protocol according to the original author but he seems reluctant to give details.
And I do not consider NetBSD core team as amateur, frankly.
- atonse 6y agoI actually just got done reading the thread. That was an interesting read. This has happened a few times. First with TunSafe, I think it also happened with CloudFlare's WG implementation, etc. The idea that a third party unsupported implementation shouldn't count. I think this is a case of the message being lost in the tone. As a user of Wireguard, I definitely don't want to think about whether this is an official implementation. But having many competing implementations is exactly what would cause confusion (imagine a news article talking about how someone overcame a Wireguard exploit to get into a network). It's like having 20 different apps that claim to be compatible with Signal. I'd have no idea which ones have gotten the same amount of rigorous testing. Fragmentation in these kinds of areas (especially when the original project is itself open source and hasn't stagnated) can often make things worse by causing even a little bit of doubt or hesitation.
- tptacek 6y agoFine? The spec is not enough to implement the protocol. Right now, it's not meant to be implemented from its spec. The spec documents what the protocol is doing, because you want to know that in order to analyze it. It's not meant to facilitate clean-room interop. WireGuard isn't an IETF protocol. In fact, it's a repudiation of IETF protocol design. Right now, you should use WireGuard implementations Jason endorses, and avoid implements he expresses concerns about.