Skip to content

Conversation

thomaseizinger
Copy link
Member

@thomaseizinger thomaseizinger commented Oct 2, 2025

Unfortunately, both rand and x25519-dalek are "exposed" dependencies of boringtun. In other words, they are part of our public API and thus bumping them by a minor version is a backwards-incompatible Rust API change. The wire format is unaffected.

In order to bump to the latest version of rand in Firezone, we need to update boringtun to the latest rand first.

For our purposes, this is fine because we only directly depend on boringtun. Hence, we can adapt our call-sites to these new APIs easily. I don't know how many other users of our fork are out there because if they want to replace their version of boringtun deep down in their dependency tree, then going forward, this will no longer work for them.

We've been delaying making any kind of breaking changes to the API for a while even though it would be nice to e.g. improve the errors and remove some of the unused ones.

Once this PR is in, we can do that because the version bump to 0.7 now allows breaking changes.

@thomaseizinger thomaseizinger force-pushed the chore/bump-dependencies branch from 69c1ca0 to d2ae1b5 Compare October 2, 2025 05:00
@thomaseizinger
Copy link
Member Author

thomaseizinger commented Oct 2, 2025

I need to do another audit as to when these new randomness functions can fail.

@thomaseizinger
Copy link
Member Author

thomaseizinger commented Oct 2, 2025

I need to do another audit as to when these new randomness functions can fail.

So it seems like that these can only fail when OS-rng is used which it is for some of the crypto aspects of WireGuard. I don't know about the old behaviour but the new one will panic.

I've inquired with upstream: dalek-cryptography/curve25519-dalek#731 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants