On Thu, Nov 10, 2022 at 11:14:34PM -0500, Jonathan S. Katz wrote: > On 10/31/22 8:56 PM, Michael Paquier wrote: >> Well, one could pass a salt based on something generated by random() >> to emulate what we currently do in the default case, as well. The >> salt length is an extra possibility, letting it be randomly generated >> by pg_strong_random(). > > Sure, this is a good point. From a SQL level we can get that from pgcrypto > "gen_random_bytes".
Could it be something we could just push into core? FWIW, I've used that quite a bit in the last to cheaply build long random strings of data for other things. Without pgcrypto, random() with generate_series() has always been kind of.. fun. +SELECT scram_build_secret_sha256(NULL); +ERROR: password must not be null +SELECT scram_build_secret_sha256(NULL, NULL); +ERROR: password must not be null +SELECT scram_build_secret_sha256(NULL, NULL, NULL); +ERROR: password must not be null This is just testing three times the same thing as per the defaults. I would cut the second and third cases. git diff --check reports some whitespaces. scram_build_secret_sha256_internal() is missing SASLprep on the password string. Perhaps the best thing to do here is just to extend pg_be_scram_build_secret() with more arguments so as callers can optionally pass down a custom salt with its length, leaving the responsibility to pg_be_scram_build_secret() to create a random salt if nothing has been given? -- Michael
signature.asc
Description: PGP signature