Re: Refactor SCRAM code to dynamically handle hash type and key length - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Refactor SCRAM code to dynamically handle hash type and key length
Date
Msg-id d3f337e5-9997-f38f-77ca-2c27e9ca97f5@enterprisedb.com
Whole thread Raw
In response to Refactor SCRAM code to dynamically handle hash type and key length  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Refactor SCRAM code to dynamically handle hash type and key length
List 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 by date:

Previous
From: Amit Langote
Date:
Subject: Re: Allow batched insert during cross-partition updates
Next
From: Peter Eisentraut
Date:
Subject: Re: static assert cleanup