On Wed, Oct 27, 2021 at 5:50 PM ste...@eissing.org <ste...@eissing.org> wrote: > > > 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.
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? Regards; Yann.
