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