Bug #125245 for Net-SSLeay: ST_OK issue

On Mon Apr 30 22:53:47 2018, UNDEF wrote: Show quoted text
OpenSSL's handshake state machine code was rewritten in time for version 1.1.0, and the possible states for the new state machine are enumerated in OSSL_HANDSHAKE_STATE. The OpenSSL developers attempted to maintain a loose mapping from the SSL_ST_* constants defining the states used by the old code to their approximate OSSL_HANDSHAKE_STATE equivalents, but this became too troublesome so the old constants were removed completely in commit f3ae9862 [1]. Fortunately this isn't too much of a problem, because OpenSSL exposes a number of functions for inspecting the handshake state that previously weren't being made available via Net::SSLeay, and those functions are sufficient for most purposes. As of commit 041a0787 [2] (which is part of Net-SSLeay 1.86_05), the following OpenSSL functions are exposed: * SSL_in_before() * SSL_is_init_finished() * SSL_in_init() * SSL_in_connect_init() * SSL_in_accept_init() These functions are available in all versions of OpenSSL and LibreSSL we currently support, so we strongly recommend using them instead of checking the return value of get_state() or state() manually where possible. For instance, instead of Net::SSLeay::state($ssl) == Net::SSLeay::ST_OK() you can now use the equivalent Net::SSLeay::is_init_finished($ssl) which avoids the need to use the handshake state machine constant altogether. I could only find one instance on the whole of CPAN of the return value of state() being compared with an ST_* constant --- ST_OK, in AnyEvent::Handle [3] --- and I'm about to send a patch that replaces that with a call to one of the newly-exposed functions. [1] https://github.com/openssl/openssl/commit/f3ae986218ad2269758f4994ffe137b8233dc0b8 [2] https://github.com/radiator-software/p5-net-ssleay/commit/041a0787be29bf648c6947a172c735c66e70fe01 [3] https://metacpan.org/source/MLEHMANN/AnyEvent-7.14/lib/AnyEvent/Handle.pm#L2116