[Pkg-openssl-devel] Any intent to maintain quictls ?
Sebastian Andrzej Siewior
sebastian at breakpoint.cc
Sun Jan 16 21:04:40 GMT 2022
Hello everyone,
I meant to write back a long while ago but it got delayed for various
reasons. Mostly because I wanted to get some technical background first
and didn't managed to do so… Still didn't read up on the quic patche so…
On 2021-10-27 16:02:55 [+0200], Daniel Stenberg wrote:
> Willy Tarreau wrote:
>
> > Given that quictls is provided as a constantly rebased patchset on top
> > of the regular openssl tree, wouldn't it make sense for distro packagers
> > to provide them both
>
> Hello,
>
> As the lead maintainer of curl, I think this makes a lot of sense and I
> support this idea. We need a networking ecosystem that can move ahead with
> QUIC and HTTP/3, and unfortunately the OpenSSL project has decided that they
> rather block process than be part of it.
>
> With quictls present, we (as in a greater collective) can move ahead and we
> might actually start to get QUIC-using code merged into debian sooner rather
> than (many years) later.
Please correct when I am wrong. My understanding is that openssl needs
quic patches. This is not the QUIC protocol itself but some kind of API
plumbing that the individual toolkit builds on top of it. It is not
possible (or makes sense) to use openssl for crypto and implement quic
independently.
This then sounds reasonable. However my problem is that this code is
neither maintained (the pull request went nowhere) and is also not
widely tested and audited.
When updates happen in the 3.0.x line (either regular updates or CVE
related fixes) then this code may need to be touched.
What are the chances to get more eyes on it? Say to get it shipped in
Fedora/ Suse/ Gentoo/… and so on so it is not just Debian that is
shipping it?
Is there a plan in case this patchset collides greatly with the final
patchset that ends up in openssl (in years) or is this unlikely to
happen.
Sebastian
More information about the Pkg-openssl-devel
mailing list