[ech] ECH PR split/progression

Hugo Landau hlandau at openssl.org
Mon Jan 22 08:53:39 UTC 2024


> 
> Hiya,
> 
> Before the holidays, I submitted a PR for ECH [1]. That's
> a whopping 17KLOC big, so understandably daunting in terms
> of getting review and working towards a merge.
> 
> On the PR discussion, a couple of maintainers suggested a
> functional split into smaller PRs might be a more tractable
> way to aim for progress.
> 
> For me, that implies splitting into 3 PRs, each building
> on the eariler, as follows:
> 
> - server - code that's needed to operate an OpenSSL server
>   that supports ECH
> - client - the above plus code that provides client-side
>   functionality
> - extras - probably most test code and ancillary functions
> 
> The logic for the above is mostly that the server code
> requires far fewer state machine changes and low level
> design decisions, and is more immediately useful (given
> that web servers using OpenSSL could make use of the 1st
> PR).
> 
> Doing that will require a pile of work on my side, so
> before going ahead with that, I'd like to get a bit of
> reassurance that a) that's seems like a sane plan to more
> maintainers, and b) that maintainers are happy to spend
> review effort if we follow that plan.
Seems reasonable to me.

> So, I'd love to get that reassurance, whatcha think?
> 
> FWIW, I'm unclear if following this plan would mean that
> (all going well) each PR would be merged with master before
> the next is processed, or if the plan is really to help with
> more tractable reviews before ending up again with one PR
> that has all the functionality. I'm assuming the former, but
> would appreciate confirmation that that's feasible. (E.g.
> the 1st "server" PR would have to omit lots of test code
> that exists and works today, but that wouldn't work if the
> client code is temporarily omitted.)
This sounds OK to me.



More information about the ech mailing list