Re: Proposed patch for key managment

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Proposed patch for key managment
Дата
Msg-id X9lhi1ht04I+v/rV@paquier.xyz
обсуждение исходный текст
Ответ на Re: Proposed patch for key managment  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Proposed patch for key managment  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On Tue, Dec 15, 2020 at 04:02:12PM -0500, Bruce Momjian wrote:
> I thought this was going to be a huge job, but once I looked at it, it
> was clear exactly what you were saying.  Comparing cryptohash.c and
> cryptohash_openssl.c I saw exactly what you wanted, and I think I have
> completed it in the attached patch.  cryptohash.c implemented the hash
> in C code if OpenSSL is not present --- I assume you didn't want me to
> do that, but rather to split the API so it was easy to add another
> implementation.

Hmm.  I don't think that this is right.  First, this still mixes
ciphers and HMAC.  Second, it is only possible here to use HMAC with
SHA512 but we want to be able to use SHA256 as well with SCRAM (per se
the scram_HMAC_* business in scram-common.c).  Third, this lacks a
fallback implementation.  Finally, pgcrypto is not touched, but we
should be able to simplify the area around int_digest_list in
px-hmac.c which lists for HMAC as available options MD5, SHA1 and all
four SHA2.

Please note that we have MD5 and SHA2 as choices in cryptohash.h, and
I have already a patch to add SHA1 to the cryptohash set pending for
review: https://commitfest.postgresql.org/31/2868/.  If all that is
done correctly, a lot of code can be cleaned up while making things
still pluggable with various SSL libraries.
--
Michael

Вложения

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Reloptions for table access methods
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: Fix generate_useful_gather_paths for parallel unsafe pathkeys