Thanks! Forking boringtun over this is not worth the added maintenance cost unfortunately. Could you please try to get upstream boringtun to include your changes? I'm happy to track a git rev between releases, but not a fork.

Understood. I'll create a pull request to the upstream boringtun.

It appears that maintainers of boringtun aren't actively reviewing pull requests, so it's likely that my changes won't be merged in the near future.

I'd like to propose an alternative approach: to use a .patch file with the changes on top of the upstream boringtun, with rust's build.rs script taking care of seamlessly cloning the repo, applying the changes and building boringtun. The interference of the new changes with the existing code of boringtun can be minimized to reduce the risk of merge conflicts with new versions of boringtun.

What do you think about this approach?

What do you think about this approach?

That actually sounds worse than tracking a fork. As much as I understand that you would like to have this shipped, I think for now the approach should be:

1. For now, whoever wants to log WireGuard secrets, needs to build mitmproxy_rs from this PR.
2. If Log handshake keys into a keylog file to allow WireGuard traffic decryption with Wireshark cloudflare/boringtun#427 gets merged upstream, we continue here (understanding that this may take time).
3. If, at some point in the future, we require more changes for (still unmaintained) boringtun, we fork and incorporate this patch as well.

Sorry if this is disappointing. I agree it's a cool feature, but for now users wanting to do this need to jump through one extra hoop (install from this PR) to reduce our maintenance burden going forward.