[Development] Setting a Minimum Support OpenSSL Version

shane.kearns at accenture.com shane.kearns at accenture.com
Wed Apr 17 19:41:47 CEST 2013


> 1) We could say we'll set the minimum to the version macos bundles.

If we don't support it, then people will need to include openssl with their application on Mac OS, in the same way they do on Windows.
My (weak) understanding of Mac packaging is that the libraries should ideally be included in the app bundle.
Unless Qt is configured with -openssl-linked, then the dependency is invisible to packaging tools, so it would need to be added manually by the app developer.
Also we may need to do something with Qt's search paths to include the app bundle when searching for an openssl version to dlopen()

Using Apple's library instead of openssl is a major development effort - I know you've looked into decoupling QSslSocket from qsslsocket_openssl with your GnuTLS prototyping.

Decision on dropping support would need to be based on:
Is it no longer secure? (i.e. if Apple stops providing timely security patches)
Is it holding back development of Qt? (i.e. we can't support common features because of missing support in the old openssl)


> 2) We could say 1.0.0 is the minimum.

This would be a good cutoff from a technical perspective.
1.0.0 has a defined API and future versions should be BC with it, whereas 0.9.x had source and binary incompatible changes.

> 3) We could pick another version as a minimum.
>
> This would have to be based on the versions used by the various long
> term supported distributions such as rhel, suse enterprise etc.

>From the responses so far in the thread, these look like some version of 0.9.8 for the older distributions still in current support.
We don't need to care about server distributions (which can have longer support periods).

--


This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited.

Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.

______________________________________________________________________________________

www.accenture.com




More information about the Development mailing list