> Am 28.10.2021 um 12:26 schrieb Yann Ylavic <ylavic.dev@gmail.com>:
>
> On Wed, Oct 27, 2021 at 5:50 PM stefan@eissing.org <stefan@eissing.org> wrote:
>>
>>> Am 27.10.2021 um 17:35 schrieb Ruediger Pluem <rpluem@apache.org>:
>>>
>>> On 10/27/21 4:38 PM, stefan@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.
>
> Can't we #ifdef QUICTLS or something like we do for LibreSSL
> (hopefully with less OPENSSL_VERSION==2 workaround mess..)?
> This would be all httpd and modules openssl/libressl/quictls, modules
> built against openssl vs core built against quictls (or vice versa)
> wouldn't be our issue, just like openssl vs libressl no?
Since @rsalz continuously merges all openssl changes into quictls, this
should only become necessary unless we start using quictls features.
But, as Ruediger pointed out, the question on a mixed system then is what
the ldap/curl/etc. libraries are linked against that we pull into the server.
If Debian and other distros want to avoid that pain, they could consider
going full quictls or apply the relevant patches to every openssl release
on their own. But then every distro has that problem, so the sane way seems
to be
A. ignore any quic related TLS for the next years, disabling every package
feature connected to it
B. go for quictls everywhere
For projects adding quic support, like curl or haproxy (anyone know the plans of ATS?),
option A blocks these features on major platforms. This will not be accepted, I guess.
This leaves room for major disruptions, like going away from openssl entirely.
Maybe something else or a quictls with a name change in the API to avoid
conflicts in linking? No one knows.
I have no idea why openssl chose to go along this path and what the reasons
behind their decision are. No one seems to be happy, though.
Cheers,
Stefan