[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