> On 22 Sep 2021, at 09:49, Michael Paquier <mich...@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 <dan...@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/
