Re: OpenSSL 3.0.0 compatibility

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: OpenSSL 3.0.0 compatibility
Date: 2020-09-23 08:17:00
Message-ID: 20200923081700.GC7405@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 21, 2020 at 08:18:42PM +0200, Daniel Gustafsson wrote:
> I'm far from fluent in OpenSSL, but AFAICT it has to do with the new provider
> API. The default value for padding is unchanged, but it needs to be propaged
> into the provider to be set in the context where the old code picked it up
> automatically. The relevant OpenSSL commit (83f68df32f0067ee7b0) which changes
> the docs to say the function should be called doesn't contain enough
> information to explain why.

Hmm. Perhaps we should consider making this part conditional on
3.0.0? But I don't see an actual reason why we cannot do it
unconditionally either. This needs careful testing for sure.

> Turns out it was coming from when I tested against OpenSSL git HEAD, so it may
> come in alpha7 (or whatever the next version will be). Let's disregard this
> for now until dust settles, I've dropped the patch from the series.

Yeah. I have just tried that on the latest HEAD at e771249 and I
could reproduce what you saw. It smells to me like a regression
introduced by upstream, as per 9a30f40c and c2150f7. I'd rather wait
for 3.0.0 to be GA before concluding here. If it proves to be
reproducible with their golden version as a bug (or even not as a
bug), we will need to have a workaround in any case.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Katsuragi Yuta 2020-09-23 08:17:04 Re: [PATCH] Add features to pg_stat_statements
Previous Message Katsuragi Yuta 2020-09-23 08:13:36 Re: [PATCH] Add features to pg_stat_statements