> Am 27.10.2021 um 17:35 schrieb Ruediger Pluem <rpl...@apache.org>:
>
>
>
> On 10/27/21 4:38 PM, ste...@eissing.org wrote:
>> Willy Tarreau made a case on the Debian openssl-dev package list to consider
>> adding the openssl fork quictls, so that software that wants to use QUIC/H3
>> finds a way forwards:
>>
>> https://alioth-lists.debian.net/pipermail/pkg-openssl-devel/2021-October/007668.html
>>
>> I added my support to this idea as a maintainer of apache httpd. But I am
>> just
>> single member of the team here. That's why I mention this here, so you can
>> add your voice to this, should you feel like it.
>
> I am not sure if this is really a good idea. I fear that there will be symbol
> name conflicts
> if you load modules that have been compiled against plain openssl as the
> library names of quictls and openssl are different (they
> use a different version in the filename). In turn this would mean that you
> need to recompile all these modules and possible
> support libaries e.g. openldap against quictls. This does not sound very
> appealing to me.
The situation is a mess, everyone agrees, I think.
> But I guess without having the SSL library providing an API for this purpose
> it will not be possible to implement a quic solution
> that leaves the SSL stuff to the SSL library.
> Difficult to decide.
Afaik, every quic related development of the last years is based on that API.
Like ngtcp2 and, based on that, nghttp3. They are now blocked from becoming
part of distributions. Linking quictls statically is not a sane approach. This
then blocks features in curl, for example, from being enabled. etc. etc.
BoringSSL would solve those problems, but who wants to rely only on that for
its OS distro?
Kind Regards,
Stefan
> Regards
>
> Rüdiger
