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-18T15:48:00Z
Lists: pgsql-hackers
On Fri, Dec 18, 2020 at 03:46:42PM +0900, Michael Paquier wrote:
> On Fri, Dec 18, 2020 at 08:41:01AM +0900, Michael Paquier wrote:
> > Knowing that we are in a period of vacations for a lot of people, and
> > that this is a sensitive area of the code that involves
> > authentication, I think that it is better to let this thread brew
> > longer and get more eyes to look at it.  As this also concerns
> > external SSL libraries like libnss, making sure that the APIs have a
> > shape flexible enough would be good.  Based on my own checks with
> > OpenSSL and libnss, I think that's more than enough.  But let's be
> > sure.
...
> This has been tested on Windows and Linux across all the versions of
> OpenSSL we support on HEAD.  I am also attaching a small module called
> hmacfuncs that I used as a way to validate this patch across all the
> versions of OpenSSL and the fallback implementation.  As a reference,
> this matches with the results from Wikipedia here:
> https://en.wikipedia.org/wiki/HMAC#Examples

Great.  See my questions in the key manager thread about whether I
should use the init/update/final API or just keep the one-line version.
As far as when to commit this, I think the quiet time is actually better
because if you break something, it is less of a disruption while you fix
it.

-- 
  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