> On 22 Sep 2021, at 09:49, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Tue, Sep 07, 2021 at 02:04:23PM +0200, Daniel Gustafsson wrote:
>> On 10 Aug 2021, at 15:27, Daniel Gustafsson <daniel@yesql.se> wrote:
>>
>>> These have now been committed, when OpenSSL 3.0.0 ships and there is coverage
>>> in the buildfarm I’ll revisit this for the backbranches.
>>
>> As an update to this, I’ve tested the tree frozen for the upcoming 3.0.0
>> release (scheduled for today AFAIK) and postgres still builds and tests clean
>> with the patches that were applied.
>
> I think that the time to do a backpatch of 318df8 has come. caiman,
> that runs Fedora 35, has just failed:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=caiman&dt=2021-09-22%2006%3A28%3A00
>
> Here is a diff:
> @@ -8,168 +8,88 @@
> decode('0000000000000000', 'hex'),
> decode('0000000000000000', 'hex'),
> 'bf-ecb/pad:none'), 'hex');
> - encode
> -------------------
> - 4ef997456198dd78
> -(1 row)
> -
> +ERROR: encrypt error: Cipher cannot be initialized ?
That particular error stems from the legacy provider not being enabled in
openssl.cnf, so for this we need to backpatch 72bbff4cd as well.
> So the coverage is here. HEAD passes, not the stabele branches. At
> least for 14 it would be nice to do that before the release of next
> week.
Agreed, I will go ahead and prep backpatches for 318df8 and 72bbff4cd.
--
Daniel Gustafsson https://vmware.com/