feat(noise): add WebTransport certhashes extension

[thomaseizinger]

Description

The extension for WebTransport certhashes was added and can be configured via Config::with_webtransport_certhashes.

In case of initiator, these certhashes will be used to validate the ones reported by responder. In case of responder, these certhashes will be reported to initiator.

Resolves #3988.

Co-authored-by: Yiannis Marangos yiannis@eiger.co

Notes & open questions

This is exactly #3991 but pushed to a branch of this repository so we can stack them.

Change checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• A changelog entry has been made in the appropriate crates

[thomaseizinger]

@oblique I've added a Co-authored-by line in the description. We automatically create the commit message from that, meaning it will still attribute to you. Does that work for you?

[oblique]

@thomaseizinger If my GitHub profile will be shown as a contributor then I'm fine with it yes.

BTW, I'm curious what is the reasoning behind this.

[oblique]

@thomaseizinger To be honest, I never encountered Co-authored-by and squash merge during my contributions, and I prefer to be shown as author. I can open new PRs if you want. I noticed that #4064 merges validate-certhashes in master and #4065 merges webtransport-wasm-ext in validate-certhashes . I can open two PRs and do that if you prefer.

[thomaseizinger]

Sure, no worries at all :)

If you activate GitHub actions for your fork, we can achieve the same collaboration if @zvolin opens his PR with the tests against the branch in your fork!

[thomaseizinger]

What I want to achieve is that we have a passing CI with the interop tests before we merge anything into master.

The certhashes PR is relatively low risk though so we can probably merge that as is.

[thomaseizinger]

Sure, no worries at all :)

If you activate GitHub actions for your fork, we can achieve the same collaboration if @zvolin opens his PR with the tests against the branch in your fork!

Closing this as a result then.

[mergify]

⚠️ The sha of the head commit of this PR conflicts with #3991. Mergify cannot evaluate rules on this PR. ⚠️

[zvolin]

Hi :) @thomaseizinger I'm wondering if that won't put me in the situation which @oblique is trying to avoid. Could you help me understand what's the issue and why we can't just merge our PR's the usual way?

[thomaseizinger]

Hi :) @thomaseizinger I'm wondering if that won't put me in the situation which @oblique is trying to avoid. Could you help me understand what's the issue and why we can't just merge our PR's the usual way?

Here is an example of what this looks like: 159a10b

GitHub attributes the commit to all listed authors.

The "issue" I am trying to solve is that I don't want to merge the webtransport implementation without a passing interop test because I don't want to those things to be an after-thought.

If we merge your tests into @oblique's PR, we can achieve that. Using Co-authored-by, we can then correctly attribute the implementation to both of you :)

An alternative is to close @oblique's PR and attribute them in your PR, given that you are building on top of their commits. I don't really mind either way.

Does this make sense?

[zvolin]

I just can't see why it would be different from getting both PR's to mergable state and then merging them one by one but I'm fine with opening a PR to @oblique

[thomaseizinger]

They also semantically belong together, i.e. should be a single, atomic commit. This has additional advantages when bisecting or reverting them for example.

Thank you for understanding! :)