Re: OpenSSL 3.0.0 compatibility - Mailing list pgsql-hackers

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

Attachment

pgsql-hackers by date:

Previous
From: Katsuragi Yuta
Date:
Subject: Re: [PATCH] Add features to pg_stat_statements
Next
From: Katsuragi Yuta
Date:
Subject: Re: [PATCH] Add features to pg_stat_statements