On Friday November 13 2015 11:30:59 Jeremy Huddleston Sequoia wrote:
> I don't understand what you mean here. These methods *force* the use of
> SSLv2 even if secure alternatives are available:
>
> qt.network.ssl: QSslSocket: cannot resolve SSLv2_client_method
> qt.network.ssl: QSslSocket: cannot resolve SSLv2_server_method
They surely do when you call them, but not when you only resolve them, i.e.
load them dynamically. As I have tried to point out before, Qt loads these and
most if not all optionally supported SSL functions dynamically. It is then up
to the user to decide what s/he is actually going to use; see
QSslContext::fromConfiguration().
It is perfectly possible to exclude support for SSL2 (since 2012) and SSL3
(since this year), btw.
> And from the SSL_CTX_new(3) man page, the recommendation is to use
> SSLv23_method et al when compatibility is a concern
>From the above method:
case QSsl::SecureProtocols:
// SSLv2 and SSLv3 will be disabled by SSL options
// But we need q_SSLv23_server_method() otherwise AnyProtocol will be
unable to connect on Win32.
case QSsl::TlsV1SslV3:
// SSLv2 will will be disabled by SSL options
case QSsl::AnyProtocol:
default:
sslContext->ctx = q_SSL_CTX_new(client ? q_SSLv23_client_method() :
q_SSLv23_server_method());
break;
> 20 years! There is absolutely NO excuse for any piece of software still
> using it.
Sure there is. That hypothetical 20+ year old closed-source binary library
someone distantly related fundamental science colleague of mine still relies on
and that magically still works with the latest Qt library... :)
R
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
