Re: Refactoring HMAC in the core code

Bruce Momjian <bruce@momjian.us>

From: Bruce Momjian <bruce@momjian.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>, Daniel Gustafsson <daniel@yesql.se>
Date: 2020-12-17T17:53:06Z
Lists: pgsql-hackers
On Wed, Dec 16, 2020 at 04:17:50PM +0900, Michael Paquier wrote:
> Please note that I have added code that should be enough for the
> compilation on Windows, but I have not taken the time to check that.
> I have checked that things compiled and that check-world passes
> with and without OpenSSL 1.1.1 on Linux though, so I guess that I have
> not messed up too badly.  This stuff requires much more tests, like
> making sure that we are able to connect to PG correctly with SCRAM
> when using combinations like libpq based on OpenSSL and the backend
> using the fallback, or just check the consistency of the results of
> computations with SQL functions or such.  An extra thing that can be
> done is to clean up pgcrypto's px-hmac.c but this also requires SHA1
> in cryptohash.c, something that I have submitted separately in [2].
> So this could just be done later.  This patch has updated the code of
> SCRAM so as we don't use anymore all the SCRAM/HMAC business but the
> generic HMAC routines instead for this work.
> 
> Thoughts are welcome.  I am adding that to the next CF.

Very nice.  Are you planning to apply this soon?  If so, I will delay
my key management patch until this is applied.  If not, I will update my
HMAC call when you apply this.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee




Commits

  1. Refactor HMAC implementations