On Sat, Dec 14, 2024 at 12:08:08AM +0100, Christoph Liebender wrote:
> Hello there everyone.
> 
> This is my first try at contributing to the OpenBSD ports tree:
> 
> https://liebender.dev/patches/openbsd-ports/wstunnel-port.tar.gz
> 
> wstunnel is useful in case you want to connect to your OpenBSD box, given
> that
> you are behind some firewall that restricts traffic to certain ports - for
> example, you can configure wstunnel to listen on :443 and connect to your
> box
> via that port, to then route all your traffic to the wireguard interface of
> your server. There are other usecases though, but this is my primary one.
> 
> Now, there are two patches included, even though wstunnel compiles on
> OpenBSD
> amd64 just fine. I had to apply these because the original Cargo.toml
> references a github repository as a crate: fastwebsockets. In this case, the
> developer of wstunnel made changes to the original crate which they did not
> (yet?) upstream, and their fork does not include any tags for the Cargo.toml
> to reference. This is why I am patching Cargo.toml to reference the original
> crate and then apply the changes of the wstunnel developer on top. I edited
> crates.inc manually in this case to add fastwebsockets-0.8.0. Is there a
> better
> way? `make modcargo-gen-crates` apparently only reads the unpatched,
> original
> Cargo.toml.
> 
> Anyway, I'm glad to receive any feedback or comments. Thanks.
> 
> - Christoph

New ports should be as attachments. The user.list patch should be sent
inlined.

Regarding Cargo.toml, I don't know any Rust nor its ecosystem, but it
seems to be possible to specify a Git hash, according to
https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html
in the way of

-fastwebsockets = { git = "https://github.com/erebe/fastwebsockets.git", features = ["upgrade", "simd", "unstable-split"] }
+fastwebsockets = { git = "https://github.com/erebe/fastwebsockets.git", rev = "deadbad0", features = ["upgrade", "simd", "unstable-split"] }

Also, this depends on rustls-0.23.19, which already uses aws-lc-rs as
the cryptography backend. I believe that will give issues on IBT-enabled
hardware.