[openssl-dev] On SSLv23_method() drop and TLS_method() introduction
Steffen Nurpmeso
sdaoden at yandex.com
Wed May 20 10:00:29 UTC 2015
Matt Caswell <matt at openssl.org> wrote:
|On 19/05/15 17:40, Kurt Roeckx wrote:
|> I think that we should just provide the SSLv23_client_method define
|> without the need to enable something, and I guess I missed
|> something during the review in that case.
|
|The reason you need to enable something is that SSLv23_client_method is
|now deprecated. If you want it to "just work" then you would need to
|un-deprecate it. That's ok but it has the disadvantage that the old name
|will then stick around indefinitely and quite probably will be used even
|for new code.
It seems to me you should introduce a multiple-step deprecation
scheme.
But this function series in particular is documented as
"effectively the way to go" in a very famous book that is so old
that it now can be downloaded for free, and i'd expect that almost
all software projects use it: turning it off overnight seems to be
a bad decision to me.
While here, so let me add my opinion, and that is that it would
possibly be better to allow NULL or (maybe better) (a) special
(*)-1(,2,3) constant(s) arguments to SSL_CTX_new() instead of
replacing SSLv23_(client_)?method() with a different
protocol-multiplexer. E.g,, SSL_CTX_new(SSL_METHOD_ANY) or the
like. I'd expect that the actual protocol limitation is done via
_set_options() or SSL_CONF_CTX_cmd() later on anyway, just as
documented.
--steffen
More information about the openssl-dev
mailing list