Re: Non-compliant SASLprep implementation for ASCII characters - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Non-compliant SASLprep implementation for ASCII characters
Date
Msg-id acHNtuWEbQajldY8@paquier.xyz
Whole thread Raw
In response to Re: Non-compliant SASLprep implementation for ASCII characters  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Thu, Mar 19, 2026 at 01:25:52PM +0900, Michael Paquier wrote:
> Applied the result for the module, to have at least the coverage part.
> The last piece is refreshed, and attached for now.

I have worked on the final piece of this thread, and applied it.

I am also attaching a small module, called scram_utils(), that I have
used to validate this change by creating SCRAM verifiers with
non-printable ASCII characters, like:
SELECT scram_utils_verifier_bytea('myrole', '\x010203', 200, 10);

This function passes down the password data to scram_build_secret()
after applying pg_saslprep(), reusing the original password if
the SASLprep was not a success.  That's the same as what we do in
pg_be_scram_build_secret() but I wanted control over the salt length
and the number of iterations for each function call (implemented that
years ago with tested SCRAM), hence the split.

Then use for example something like that for the input:
export PGPASSWORD=$(printf '%b%b%b' '\01\02\03')

The validation between the non-compliant and the compliant
implementation then comes down to:
- Generate the rolpassword on HEAD patched (new) and unpatched (old).
- Check connections with libpq patched (new) and unpatched (old), with
client->server as of new->old, old->new, new->new.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Adding comments to help understand psql hidden queries
Next
From: KAZAR Ayoub
Date:
Subject: Re: Add pg_stat_vfdcache view for VFD cache statistics