OpenSSL-1.1 transition.
Contents
FAQ
- Will it definitely go ahead for stretch?
- We have a mix of libssl1.0 and libssl1.1 users
- Which packages must transition at the same time?
- If applications or libraries exchange structures defined by OpenSSL, like SSL_CTX, they must use the same version of OpenSSL. Failing to do so may not be caught at compile time, but cause runtime bugs like segmentation faults or just misbehaving applications. Therefore, extreme care must be taken to avoid such situations. Example: zurl 1.7.0-1 (currently in testing), if linked to libcurl3 7.51.0-1 (currently in sid), fails to retrieve https pages, because it's linked to OpenSSL 1.0 while libcurl3 already switched to OpenSSL 1.1. These
packages exchange an OpenSSL struct (SSL_CTX) via an API defined by curl. Bug #844018
- If applications or libraries exchange structures defined by OpenSSL, like SSL_CTX, they must use the same version of OpenSSL. Failing to do so may not be caught at compile time, but cause runtime bugs like segmentation faults or just misbehaving applications. Therefore, extreme care must be taken to avoid such situations. Example: zurl 1.7.0-1 (currently in testing), if linked to libcurl3 7.51.0-1 (currently in sid), fails to retrieve https pages, because it's linked to OpenSSL 1.0 while libcurl3 already switched to OpenSSL 1.1. These
- Can packages and libraries using both versions of OpenSSL be mixed?
According to a post to debian-devel, it's ok to link to libraries which in turn use different versions of OpenSSL, as long as they don't exchange OpenSSL data structures:
- "The linking is fine, I believe even any eventual globals (if any) will be correctly handled in Debian nowadays. What causes extremely nasty issues is layering violations causing openssl data structures to leak from something linked to one version of the library, to something else linked to another version of the library. If, at any point, internal data structures from openssl are exposed, or OpenSSL contextes are passed between two libraries, or a library and an application, *they must all be from the same openssl*. This is not something the linker or dlopen/dlsym can enforce. And you need to manually inspect the code to be sure... usually. So, if Qt *ever* exposes its use of openssl anywere in its APIs, it might not be safe. If it doesn't (i.e. at most you have a qt flag that says "use SSL", etc), then it should be fine."
But: Qt uses dlopen() and dlsym() (not: dlvsym()) to load OpenSSL. It's not completely clear if that invalidates the abovementioned assumptions and makes linking to different versions of OpenSSL unsafe.
Current Status
The transition for OpenSSL 1.1 is over. We have libssl 1.0 and 1.1 users in the archive for Stretch. The OpenSSL 1.0 package should be removed in the Buster cycle. The list of OpenSSL 1.0 users