> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Jeffrey Walton > Sent: Tuesday, June 28, 2016 18:04 > To: OpenSSL Users > Subject: Re: [openssl-users] Getting error 'SSLv2_client_method': identifier > not found > > On Mon, Jun 27, 2016 at 3:49 PM, Michael Wojcik > <Michael.Wojcik at microfocus.com> wrote: > > SSLv2 is no longer supported, and neither are the SSLv2_*_method calls. > (And > > yes, this causes build problems when updating to newer OpenSSL builds; > and > > while that causes some pain, it was the Right Thing to do.) > > The library should have unconditionally set OPENSSL_NO_SSL2 when it > yanked SSLv2 support. Iit was warned about use cases like this. > > When SSLv2 was re-added to return NULL because, it still omitted > OPENSSL_NO_SSL2. > > There was no need to break existing client code in this case. That's a valid argument. There was a time, not so long ago, when I made a similar argument on this very list (and was pretty cranky about proposed changes to the OpenSSL API). At the moment, I'm inclined to prefer a compile-time error to a run-time one in this case. I suspect there's a fair bit of code out there which doesn't check for a null return from the *_method calls, leading to some puzzlement on the part of developers. (I'll agree re OPENSSL_NO_SSL2; that ought to be defined.) But perhaps tomorrow I'll feel differently. There's an argument to be made either way. -- Michael Wojcik Technology Specialist, Micro Focus
