Re: Proposed patch for key managment

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Proposed patch for key managment
Дата
Msg-id 20201218154446.GC28841@momjian.us
обсуждение исходный текст
Ответ на Re: Proposed patch for key managment  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: Proposed patch for key managment  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
On Fri, Dec 18, 2020 at 08:18:53AM -0500, Stephen Frost wrote:
> What I would be thinking about with this are really three pieces-
> 
> - C API for libpq (not relevant for this, but we have had issues in the
>   past with exposing OpenSSL-specific things there)

Right.

> - C API in backend - we should try to at least set up the structure to
>   allow multiple encryption implementations, either via different
>   libraries or if someone feels it'd be useful to write a built-in
>   implementation, but as I mentioned just a moment ago, we aren't going
>   to get this perfect and we should accept that.

All my OpenSSL-specific stuff is isolated in src/common.

> - User API - we should avoid having OpenSSL-specific bits exposed to
>   users, and I don't think we do today, so I don't think this is an
>   issue at the moment.

Right, there is nothing OpenSSL-specific on the user side, but some of
the scripts assume you can pass an open file descriptor to a
PKCS11-enabled tool, and I don't know if non-OpenSSL libraries support
that.

Ideally, we would have scripts for each library to use their
command-line API for this.  I am hestitant to rename the scripts to
contain the name openssl because I am unclear if we will ever have
non-OpenSSL implementations of these.  I updated the script comments at
the top to indicate "It uses OpenSSL with PKCS11 enabled via OpenSC.".

One point is that the passphrase scripts are useful for cluster file
encryption _and_ unlocking TLS certificates.

> > I split apart my patch to create cipher{_openssl}.c and hmac{_openssl}.c
> > so the single HMAC function is not in the cipher file anymore, attached.
> 
> Will try to look at this soon, but in general the idea seems right.

Should I be using the init/update/final HMAC API that SCRAM uses so it
is easier to integrate into Michael's patch?  I can do that, but didn't
because that is going to require me to create a much larger footprint in
the main code, and that might be harder to integrate once Michael's API
is final.  It is easier for me to change one line to five lines than to
change five lines to five different lines.

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

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




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pgbench failed when -f option contains a char '@'
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Refactoring HMAC in the core code