Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2

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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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..

In response to

Browse pgsql-hackers by date

  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