On 04/03/17 16:13, Steffan Karger wrote: > As a last resort, we could consider keeping the old code inside #if > OSSL_VER < 1.1.0 in release/2.4, but that might just create more > confusion...
Just a very quick thought here ... I do dislike different behaviours depending on which OpenSSL version being used. But given that this feature is already deprecated and even removed in OpenSSL-1.1, I think that gives us some options. I agree with Gert that breaking --ns-cert-type isn't good at all. However, consider when people upgrade from OpenSSL v1.0 to v1.1 - that is most commonly when there is major distro update. It is not something which happens "mid-term", as OpenSSL is quite commonly used by lots of base system packages these days. Regardless of OpenSSL version, I agree to loudly deprecate --ns-cert-type, through documentation, --help and log files. But I think we need to carry the existing behaviour for --ns-cert-type when built against OpenSSL v1.0. And we can solve through some compatibility wrapper when built against OpenSSL v1.1 - with even louder warnings in the logs that this may break apart. The reason I say this, is that Fedora users are quite unhappy that --tls-remote disappeared in v2.4.0 *despite* a more recent NetworkManager-OpenVPN plug-in actually making it easy to switch to --verify-x509-name. But IIRC, this wasn't backported to all older and still valid Fedora releases, so that caused additional pain for the users. And don't get me started with the attempt of temporarily build against mbed TLS instead of OpenSSL in Fedora Rawhide (which will become Fedora 26), as that broke lots of configurations with CA certificates using RSA 1024 bit keys. All this results in very little OpenVPN 2.4 adaptation among many Fedora users. I can barely imagine what happens if we break --ns-cert-type on top of that ... Just that the behaviour might change for a minority of users in when Fedora 26 hits the streets, with OpenSSL v1.1, might hit us bad again. But at least with OpenSSL v1.1, many users knows that things will be somewhat different too. And we can actually point at OpenSSL and explain why it broke, which is not something we could do with the --tls-remote option. Just my way too many cents ..... :) -- kind regards, David Sommerseth OpenVPN Technologies, Inc
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
