Matt Caswell <m...@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 _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev