Re: Refactor SCRAM code to dynamically handle hash type and key length

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Refactor SCRAM code to dynamically handle hash type and key length
Дата
Msg-id d3f337e5-9997-f38f-77ca-2c27e9ca97f5@enterprisedb.com
обсуждение исходный текст
Ответ на Refactor SCRAM code to dynamically handle hash type and key length  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Refactor SCRAM code to dynamically handle hash type and key length  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
On 14.12.22 03:38, Michael Paquier wrote:
> This patch passes check-world and the CI is green.  I have tested as
> well the patch with SCRAM verifiers coming from a server initially on
> HEAD, so it looks pretty solid seen from here, being careful of memory
> leaks in the frontend, mainly.

The changes from local arrays to dynamic allocation appear to introduce 
significant complexity.  I would reconsider that.  If we consider your 
reasoning

 > While investigating on what it would take to extend SCRAM to use new
 > hash methods (say like the RFC draft for SCRAM-SHA-512), I have been
 > quickly reminded of the limitations created by SCRAM_KEY_LEN, which is
 > the key length that we use in the HMAC and hash computations when
 > creating a SCRAM verifier or when doing a SASL exchange.

then the obvious fix there is to change the definition of SCRAM_KEY_LEN 
to PG_SHA512_DIGEST_LENGTH, which would be a much smaller and simpler 
change.  We don't have to support arbitrary key sizes, so a fixed-size 
array seems appropriate.




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

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: Allow batched insert during cross-partition updates
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: static assert cleanup