From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2 |
Date: | 2020-12-04 02:09:05 |
Message-ID: | X8maQe5Am7Q141f4@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Dec 03, 2020 at 10:58:39PM +0100, Daniel Gustafsson wrote:
> 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.
Based on my read of the code in lib/freebl/, SHA256ContextStr & co
hold the context data for SHA2, but are headers like sha256.h
installed? I don't know enough of NSS to be able to answer to
that. If, like OpenSSL, the context internals are not provided, I
think that you could use SHA256_NewContext() and track the allocation
with the resource owner callbacks, but doing a palloc() would be
much simpler if the context internals are available.
> My only question is:
>
> +#ifndef FRONTEND
> + elog(ERROR, "out of memory");
> Shouldn't that be an ereport using ERRCODE_OUT_OF_MEMORY?
That makes sense, fixed.
I have done more testing across all versions of OpenSSL, and applied
this one, meaning that we are done for SHA2. Thanks for the reviews!
Now, moving back to MD5..
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2020-12-04 02:22:44 | Re: Single transaction in the tablesync worker? |
Previous Message | Justin Pryzby | 2020-12-04 01:25:43 | Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly |