Re: OpenSSL 3.0.0 compatibility - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: OpenSSL 3.0.0 compatibility
Date
Msg-id 20200919021148.GA18372@paquier.xyz
Whole thread Raw
In response to Re: OpenSSL 3.0.0 compatibility  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: OpenSSL 3.0.0 compatibility  (Daniel Gustafsson <daniel@yesql.se>)
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_logging_init() can return ENOTTY with TAP tests
Next
From: Michael Paquier
Date:
Subject: Re: pg_logging_init() can return ENOTTY with TAP tests