Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2
От | Daniel Gustafsson |
---|---|
Тема | Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2 |
Дата | |
Msg-id | 81B1EC5D-4C6D-44E4-8533-7AD2B615B176@yesql.se обсуждение исходный текст |
Ответ на | Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2 (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2
|
Список | pgsql-hackers |
> On 3 Dec 2020, at 02:47, Michael Paquier <michael@paquier.xyz> wrote: > > On Wed, Dec 02, 2020 at 12:03:49PM +0900, Michael Paquier wrote: >> Thanks. 0001 has been applied and the buildfarm does not complain, so >> it looks like we are good (I'll take care of any issues, like the one >> Fujii-san has just reported). Attached are new patches for 0002, the >> EVP switch. One thing I noticed is that we need to free the backup >> manifest a bit earlier once we begin to use resource owner in >> basebackup.c as there is a specific step that may do a double-free. >> This would not happen when not using OpenSSL or on HEAD. It would be >> easy to separate the resowner and cryptohash portions of the patch >> here, but both are tightly linked, so I'd prefer to keep them >> together. > > Attached is a rebased version to take care of the conflicts introduced > by 91624c2f. This version looks good to me, and builds/tests without any issues. While I didn't try to adapt the libnss patch to the resowner machinery, I don't see any reasons off the cuff why it wouldn't work with the scaffolding provided here. My only question is: +#ifndef FRONTEND + elog(ERROR, "out of memory"); Shouldn't that be an ereport using ERRCODE_OUT_OF_MEMORY? cheers ./daniel
В списке pgsql-hackers по дате отправления: