I think there could be bug in he_internal_send_auth_userpass when it copies the strings because when calculating the string lengths it uses the size of he_conn->username and he_conn->password which are "HE_CONFIG_TEXT_FIELD_LENGTH +1" whereas the sizes of the destination fields in he_msg_auth_t are "HE_CONFIG_TEXT_FIELD_LENGTH" so .
Take it with a grain of salt, I just took a very quick look mostly to see if I liked the coding style and it's far too early for my brain to be functional but it seemed that way to me. Other than that I didn't hate the code which is cool!
Thanks for opening it!
The specific reason for the size disparity is that we require he_conn->{username,password} to be null-terminated, whereas we do NOT require he_msg_auth->{username,password} to be null-terminated. I remember raising the same point and being convinced that we had a good reason for doing so, but I also haven't had enough coffee to remember what the good reason was!
Regardless of whether this is a "bug" or not I do think that the disparity points to something that unnecessarily causes confusion, will have a think about making it more consistent.
Regarding style -- I also ~hate if(x==0) without the space after the if but we committed to consistency instead of arguing over it via clang-format. To quote Rob Pike, "Gofmt's style is no one's favorite, yet gofmt is everyone's favorite."
Thanks for taking the time to reply!
In particular, I wonder why they made all new protocol instead of adding a nice wrapper over Wireguard.
Wireguard is a great VPN protocol, but it was designed for a very different use case.
Edit: My apologies, I should have first introduced myself as the creator of Lightway at ExpressVPN :)
You say WireGuard was designed “for a different use case”.. that’s an extremely cryptic (buh dum tiss) thing to say. Do you seriously envision Mullvad or other VPN service providers adopting your protocol? At face value, I will conjecture and come from pessimistic point-of-view: this more of a niche feature of your product, appealing to a type of techy mindset where shiny new tools are somehow better.. which is playing with fire when it comes to encryption for privacy..
For anyone reading this, don’t listen to anyone here. Just go to https://privacytools.io and use those providers.
I would love to see Lightcore and ExpressVPN listed on that site someday.. good luck
Also I don't really get this? This to be looks like just the core library that details the protocol and nothing else around it.
Like this is really just wolfSSL + wire format. You'd still have to write the code for getting the data to the server (Handle all retransmission and other stuff), write clients (possibly kernel modules for layer 3 performance) for all major OS, write a server to handle traffic forwarding. And if you're doing all that, one might as well make their own format. Are there plans to release the other parts separately?
No CLA needs to be signed to contribute to WireGuard.
The reason we have a CLA is that we want to be upfront and transparent about what happens when someone contributes code to the project. It is important to note that the author maintains ownership of their contribution at all times and that we will immediately release the contribution under the GPL 2.0 license. This helps to protect the project by ensuring that any code in the repository can be released under the GPL 2.0 license both now and in the future. This is why the Apache Foundation requires a CLA for all contributions - the intent is to protect everyone's interests.
As part of any code contribution, we will list the author's name and what was contributed so that the author will get full recognition for their work.
