Re: OpenSSL 1.1.0
On Thu, Nov 24, 2016 at 07:23:22PM +0200, Adrian Bunk wrote:
> If both b-dev and c-dev would depend on the libssl*-dev they use,
Which is not always the case, now.
qtbase5-private-dev exposes lots of internal OpenSSL structures, but
doesn't depend on any OpenSSL package.
libcurl4-openssl-dev only suggests libssl-dev. And it provides access to
an SSL_CTX via:
typedef CURLcode (*curl_ssl_ctx_callback)(CURL *curl, /* easy handle */
void *ssl_ctx, /* actually an
OpenSSL SSL_CTX */
void *userptr);
It's working around a dependency by using a (void *) instead.
So, at least in theory, a package using both qtbase5-private-dev and
libcurl4-openssl-dev could relay an SSL_CTX between two different
versions of OpenSSL.
In practice, of course, its highly unlikely that a package links to two
different libraries, accesses SSL-related functions in both of them,
passes structures around, and does not depend on libssl-dev, itself.
Therefore I think this is a red herring.
The more important question is if there are any risks left if there are
no structures exchanged between the two versions of OpenSSL. Which, in
turn, boils down to the question of dlopen()/dlsym() do the right thing.
If this usage is not OK, we need to make sure no package using Qt (and,
in any of its use-cases triggering an SSL connection via Qt), links to
OpenSSL 1.1, directly or indirectly. And indirect usage can't be
prevented with the build-dependency Adrian suggests.
If, instead, such usage is fine, only (dev-)packages exposing SSL
structures need to be protected by a build-dependency on libssl-dev.
That would be libcurl4-openssl-dev, qtbase5-private-dev and probably
some others I don't know about.
Jan
Reply to: