Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Tom Lane <tgl@sss.pgh.pa.us>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-12-04T02:09:05Z
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
Commits
-
Change SHA2 implementation based on OpenSSL to use EVP digest routines
- 4f48a6fbe2b2 14.0 landed
- e21cbb4b893b 14.0 landed
-
Move SHA2 routines to a new generic API layer for crypto hashes
- 87ae9691d253 14.0 landed
-
Use OpenSSL EVP API for symmetric encryption in pgcrypto.
- 5ff4a67f63fd 10.0 cited