Is this project dead/abandoned?

[n9]

The last commit is currently 7 months old: f672bb6
The last status update (I have found) is 12 months old: #344 (comment)

[SkyfallWasTaken]

I doubt it tbh, Cloudflare uses BoringTun pretty extensively within CF I think. My guess is just that BoringTun is "done" and doesn't really need much else

[n9]

Have you ever seen done project that is not gone?

(I would expect at least some security patches.)

[SkyfallWasTaken]

This seems to be a pattern with the official Wireguard project too:

• wireguard-linux's last commit was 2 months ago
• wireguard-go's last commit was 5 months ago
• Wireguard's official Rust implementation's last commit was 4 years ago

My guess is that Wireguard is a simpler protocol, so needs less maintenance, considering that the official implementation apparently only uses around 4,000 lines of code

[lu-zero]

There are plenty of open issues and pull requests for boringtun,

[cableguard]

I created a fork, altuntun, https://github.com/cableguard/altuntun/blob/main/README.md with several PRs applied for better performance, support of namespaces and refactored variable names for readability. I want to add credits to the authors of the PRs (todo this week) and carry on improving wireguard in Rust, and work closely with the main wireguard maintainers in the near future. Looking forward for active collaborations if you are interested.

[Zk2u]

@cableguard the fork is a good start while seemingly no one at cloudflare is responding… could be something to do with them moving to MASQUE for warp but it would be nice to have… something

[torkeldanielsson]

+1 on the need for communication from Cloudflare on what is going on here

[thomaseizinger]

I created a fork, altuntun, cableguard/altuntun@main/README.md with several PRs applied for better performance, support of namespaces and refactored variable names for readability. I want to add credits to the authors of the PRs (todo this week) and carry on improving wireguard in Rust, and work closely with the main wireguard maintainers in the near future. Looking forward for active collaborations if you are interested.

Is there a particular reason why you did not retain the git history of this project when creating your fork? I would like to switch to a more maintained version of boringtun but I don't want to re-audit your implementation. It would have been great to just audit your improvements.

[cableguard]

Hi @thomaseizinger The reason is that I created a fork that implemented very extensive changes in the way boringtun performs authentication, using NEAR Protocol non fungible tokens, I worked on this for a year and a half more or less, and I had to change the names of a large proportion of variables in order to understand and modify the code. As I could see, some people where unhappy about the maintenance of this project, so I removed all the NFT authentication code and revert it to a "vanilla wireguard" implementation, also I added all patches that were long standing and I found useful. So unfortunately I can't guarantee is flaw free, what I can guarantee is that nothing has been changed in a malicious way.

[thomaseizinger]

I see, thanks for laying this out! We'll probably maintain our own fork then in the hope that some things can actually be upstreamed.

[thomaseizinger]

Our fork is now live at https://github.com/firezone/boringtun. The aim is to keep it 100% API compatible with the current boringtun release.

Contributions welcome. We are also still interested in upstreaming those patches in case anyone at Cloudflare is following this!

[thomaseizinger]

Hi @celeste-sinead @Noah-Kennedy !

I noticed some new activity from you on this repo and was wondering if there is any interest in upstreaming any of the features and bugfixes we've been making to boringtun in our fork?

You can see the full list of changes here: master...firezone:boringtun:master

Some notable features and bug-fixes include:

• fix: remove panics from packet processing path firezone/boringtun#26
• feat: implement handshake jitter firezone/boringtun#46
• fix: time-impurity within boringtun library firezone/boringtun#45
• fix: only rekey after timeout from first unreplied packet firezone/boringtun#66
• fix: don't send packets on almost expired sessions firezone/boringtun#68

[celeste-sinead]

I'm intending to step in and maintain this. Expect me to be quite conservative for now as I get up to speed (probably just chores and simple fixes for the time being), but yes, I'm interested in upstreaming things.