Re: OpenSSL 3.0.0 compatibility

On Fri, Sep 18, 2020 at 04:11:13PM +0200, Daniel Gustafsson wrote:
> Since we support ciphers that are now deprecated, we have no other choice than
> to load the legacy provider.

Ah, thanks. I actually tried something similar to that when I had my
mind on it by loading the legacy providers, but missed the padding
part. Nice find.

> The other problem was that the cipher context
> padding must be explicitly set, whereas in previous versions relying on the
> default worked fine. EVP_CIPHER_CTX_set_padding always returns 1 so thats why
> it isn't checking the returnvalue as the other nearby initialization calls.

It seems to me that it would be a good idea to still check for the
return value of EVP_CIPHER_CTX_set_padding() and just return with
a PXE_CIPHER_INIT. By looking at the upstream code, it is true that
it always returns true for <= 1.1.1, but that's not the case for
3.0.0. Some code paths of upstream also check after it.

Also, what's the impact with disabling the padding for <= 1.1.1? This
part of the upstream code is still a bit obscure to me..

> To avoid problems with the by LibreSSL overloaded OPENSSL_VERSION_NUMBER macro
> (which too is deprecated in 3.0.0), I used the new macro which is only set in
> 3.0.0. Not sure if that's considered acceptable or if we should invent our own
> version macro in autoconf.

OSSL_PROVIDER_load() is new as of 3.0.0, so using a configure switch
similarly as what we do for the other functions should be more
consistent and enough, no?

> For the main SSL tests, the incorrect password test has a new errormessage
> which is added in 0002.

Hmm. I am linking to a build of alpha6 here, but I still see the
error being reported as a bad decrypt for this test. Interesting.
--
Michael