Re: Refactoring HMAC in the core code - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Refactoring HMAC in the core code
Date
Msg-id X9vsjX0FJ+AGsw9p@paquier.xyz
Whole thread Raw
In response to Re: Refactoring HMAC in the core code  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Refactoring HMAC in the core code
List pgsql-hackers
On Thu, Dec 17, 2020 at 12:53:06PM -0500, Bruce Momjian wrote:
> 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.

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.

I don't think that this prevents to update your code to rely on this
new API as you could post a copy of this patch in your own patch
series (the CF bot can pick up a set of patches labeled with
format-patch), making your own feature a bit smaller in size.  But I
guess that depends on how you want to maintain a live patch series.

What should be really avoided is to commit in the code tree any code
that we know could have been refactored out first, so as we always
have in the tree what we consider as a clean state and don't
accumulate duplications.  That pays off a lot when it comes to the
buildfarm turning suddenly red where a revert is necessary, as
incremental changes reduce the number of things to work on at once,
and the number of changes to revert.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [BUG] orphaned function
Next
From: Michael Paquier
Date:
Subject: Re: multi-install PostgresNode