Package: libqt5network5
Version: 5.15.4+dfsg-4
Severity: serious
Justification: Policy 3.5

I have libssl 3.0.4-2 (satisfying the dependency of libqt5network5),
but libssl-dev 1.1.1n-0+deb11u3.

Starting QT applications gets on stdout/stderr stuff like

07-26 20:08:33:071 [ warning qt.network.ssl ]:  QSslSocket: cannot resolve 
SSL_get1_peer_certificate
07-26 20:08:33:071 [ warning qt.network.ssl ]:  QSslSocket: cannot resolve 
EVP_PKEY_get_base_id
07-26 20:08:33:071 [ warning qt.network.ssl ]:  QSslSocket: cannot resolve 
SSL_CTX_load_verify_dir
07-26 20:08:46:405 [ warning qt.network.ssl ]:  QSslSocket: cannot call 
unresolved function SSL_CTX_load_verify_dir
07-26 20:08:46:405 [ warning qt.network.ssl ]:  An error encountered while to 
set root certificates location: ""
07-26 20:08:46:409 [ warning qt.network.ssl ]:  QSslSocket: cannot call 
unresolved function SSL_get1_peer_certificate
07-26 20:08:46:409 [ warning qt.network.ssl ]:  QSslSocket: cannot call 
unresolved function SSL_get1_peer_certificate

and then the application fails to recognise any certificate as valid,
since it doesn't recognise any root CA.

An strace shows that it loads (my guess if with dlopen())
/usr/lib/x86_64-linux-gnu/libssl.so

That file is _not_ provided by _any_ direct or indirect dependency of
libqt5network5 but by libssl-dev.

So from a policy standpoint:

 * libqt5network5 _must_ _not_ require that file to function since it
   does not depend on libssl-dev; formally that is fulfilled since it
   will fallback to libssl.so.3 when libssl.so is not found.

 * libqt5network5 _must_ _not_ be broken by the presence of any
   particular version of that file since it does not conflict with any
   particular version of libssl-dev; that is the policy requirement
   that is not fulfilled.


In my opinion the best solution is to _never_ dlopen("libssl.so"), but
only every dlopen("libssl.so.3") since that is the ABI that you
expect, and what the package depends on.

>From a policy standpoint, it would also be acceptable (as in non-RC
buggy) to instead conflict on any version of libssl-dev that one is
not compatible with, but IMO that would be a pity.


-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (400, 'testing'), (300, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-15-amd64 (SMP w/8 CPU threads)
Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libqt5network5 depends on:
ii  libc6                             2.33-8
ii  libgssapi-krb5-2                  1.18.3-6+deb11u1
ii  libqt5core5a [qtbase-abi-5-15-4]  5.15.4+dfsg-4
ii  libqt5dbus5                       5.15.4+dfsg-4
ii  libssl3                           3.0.4-2
ii  libstdc++6                        12.1.0-7
ii  zlib1g                            1:1.2.11.dfsg-2+deb11u1

libqt5network5 recommends no packages.

libqt5network5 suggests no packages.

-- no debconf information

-- 
Lionel Mamane
Tél: +352 46 67 74
Fax: +352 46 67 76

This message and any attachments may be intended to be confidential,
intended solely for the addressee and/or contain legally privileged
information. Any unauthorised use or dissemination is prohibited.
Unless cryptographically protected, emails are susceptible to
interception, alteration and spoofing, so in case of doubt, please
check by independent means.

We do not make any commitment by email, ever; if this emails appears
to contain a commitment, we will not recognise the latter as valid,
nor as engaging our liability. We make commitments only by a written
paper document signed by at least one person entitled to engage our
liability.

Reply via email to