20.11.2016 в 22:35:26 +0100 Jan Niehusmann написал:
> On Mon, Nov 21, 2016 at 01:03:19AM +0400, Stepan Golosunov wrote:
> > So far I do not know why using libssl1.1 together with a
> > libssl1.0.2-using Qt wouldn't work.
>
> Well I don't know enough about the dynamic linker and about the internals
> of openssl to know if (indirectly) linking to both libraries at the same
> time is fine.
Indirectly linking with both libraries is supposed to work due to
symbol versioning. If it wasn't than OpenSSL transition wouldn't have
started. And parts of Qt are already linked with libssl1.1 (via
libpq5). Problems could (and did in previous transition) arise if
code (Qt or application) is initializing one libssl while parts of
application are using another but this is supposed to be fixed for
libssl1.1.
And the problem with Qt is that it is not actually linked with OpenSSL
but uses it via dlopen. My reading of dlsym(3) suggests that it
should work but I could be misreading the documentation or it can be
incorrect.
> If it was, that would be great news. Many mails in the thread "OpenSSL
> 1.1.0" on debian-devel seem to be based on the assumption that such
> linking could cause bugs, and therefore packages can only transition in
> clusters of packages linking to the same version of openssl.
If application passes OpenSSL objects between the two libraries than
it won't work.
> Still, qt is only an example - the same holds true for other libraries
> linking to openssl1.0-dev. There may be cases where your 2nd case
> ('Application passes OpenSSL objects from libssl1.1 to ...') is more
> probable than with qt.
I expect that if libcurl3 is linked with libssl1.0.2 there would be more
problematic applications (as applications need to link with
libssl1.0.2 and run initialization in this case) than if curl is
linked with libssl1.1 (as applications not using
CURLOPT_SSL_CTX_FUNCTION-like functionality are free to link with
whatever libssl they want or not to link with it at all).
> The safest way to avoid hidden bugs would still be changing SONAME and
> package name, so package maintainers would be aware of the change and
> could check their packages for compatibility.
>
> But yes, it may be less work to somehow identify affected packages and
> handle them directly instead of forcing all packages depending on curl
> through a transition. Identifying those packages in a reliable way could
> be difficult, though.
If libcurl3 is linked with libssl1.1 then maintainer needs to
explicitly break his application (like happened with zurl 1.7.1-1).
The rest just need to be recompiled (and they need to be recompiled in
any case).
The part of the bug where dependencies are insufficiently tough and
libcurl does not change its SONAME exists independently of which
libssl it is linked to (as long as that libssl is different from the
one used in jessie).
