WireGuard-rs – Official Rust implementation of WireGuard | Hacker News Reader

WireGuard-rs – Official Rust implementation of WireGuard

git.zx2c4.com

101 pointspopcalc25 comments

If anyone needs one of these, there is an UNofficial implementation by Cloudflare, which is used in Warp.

A high density of "things that Hacker News people dislike" in a single comment - bold!

(FWIW I personally really like Cloudflare and think that a lot of their hate is unjustified. Warp is probably a good place for a new-to-programming person to start, but doesn't offer any functionality that makes me want to transition away from my already-customized shell)

The Cloudflare Warp VPN is not the same as the Warp terminal.

Ah, I wasn't aware of Cloudflare's product of the same name - thanks!

Cloudflare is an evil company that at this point exists to a significant degree to hoover data for the US government and shelter sexual predators. Nobody should condone them or by using their technology promote their existence.

I am hesitant to use this, it appears to be basically unmaintained

https://github.com/cloudflare/boringtun/issues/344

https://github.com/cloudflare/boringtun/issues/407

I think this project is dormant right?

Looks like it? 4 years old commits

Why is that a bad thing? Maybe it just works and doesn't need further changes.

Cause it presumably has to be compatible with Wireguard upstream?

Wireguard is a pretty fixed and simple standard. Nothing needs to happen.

So the "tcp: fix incorrect undo caused by DSACK of TLP retransmit" done five weeks ago for the Linux kernel didn't need to happen for the Rust implementation?

I don't think this commit has anything to do with wireguard. It's a fix of a bug in the kernel TCP stack, which wireguard doesn't use. (Beware, the wireguard-linux repo is a "fork" of the complete linux kernel)

And even if it did, a userland TUN implementation of the wireguard protocol probably doesn't have the same bugs as the linux kernel one.

Sure, the standard is relatively straightforward, but the implementations have to keep up with their environment. Wireguard in Linux has to keep up with changes in the kernel to a degree, for example.

Looking at the supported platforms, it looks like the only one is Linux. The README has this to say about it though: "This will run on Linux; however YOU SHOULD NOT RUN THIS ON LINUX. Instead use the kernel module; see the installation page for instructions."

It's like git: you write it for linux, then leave it as is.

How do rust projects work over rust versions?

Is rust stable enough from 20-24 that the project would likely remain in a state to compile on a new rust tool chain? Do "Editions" completely solve this?

Pretty much. I've had a great deal of luck rebuilding older projects. You can lock your toolchain as an added protection, but `cargo clippy --fix` is often enough to fix 90% of those.

I think the only time I really struggled with a toolchain upgrade was with one of the crypto libraries that was bringing in a broken version of some SIMD code (cannot remember the exact details).

For kicks I cloned and build this with Rust 1.80 and it built just fine (a few reasonable warnings), and even bumped the edition up to 2021. The README suggests you need nightly but that's clearly not the case.

EDIT: the Rust code is actually unsoundly using MaybeUnit in a few places.

Thanks for the info.

Is "lock your toolchain" via rustup? It appears to be the equivalent of rbenv/pyenv/nodenv/asdf etc but part of rust.

See also https://github.com/WireGuard/wireguard-rs - also no longer maintained. Weird that this is linked on front page of HN now.

It's the same project.

What does “official” refer to in the title?

The word `official` was added by OP to hint at the fact that zx2c4 is the kernel contributor who created WireGuard.

Why do we get so many "Rust version of X" posts on HN, compared to any other language?

it is the only other language in the linux kernel besides c

no other language accomplished that from a design perspective

Reply on news.ycombinator.com