WireGuard-rs – Official Rust implementation of WireGuard(git.zx2c4.com)
git.zx2c4.com
WireGuard-rs – Official Rust implementation of WireGuard
https://git.zx2c4.com/wireguard-rs/
28 comments
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
https://github.com/cloudflare/boringtun/issues/344
https://github.com/cloudflare/boringtun/issues/407
[deleted]
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)
(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)
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 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.
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?
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.
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.
Is "lock your toolchain" via rustup? It appears to be the equivalent of rbenv/pyenv/nodenv/asdf etc but part of rust.
[deleted]
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.
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.
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.
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
no other language accomplished that from a design perspective
https://github.com/cloudflare/boringtun