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 aaU2AE8BgH0Kc_hw@paquier.xyz
Whole thread Raw
In response to Non-compliant SASLprep implementation for ASCII characters  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Fri, Feb 27, 2026 at 12:05:28PM +0900, Michael Paquier wrote:
> - 0001 is a test suite that I have been relying on for some time,
> introduced as the test module test_saslprep.  One artifact that Heikki
> has mentioned to me offline while discussing this tool is that we
> could also have a check for the entire range of valid UTF8 codepoints
> to make sure that we never return an empty password for all these
> codepoints.  This check is slightly expensive (3s on my laptop, which
> is not bad still a bit expensive), so I have implemented that as a TAP
> test controlled by a PG_TEST_EXTRA.  The only exception for the empty
> password case is the nul character, that we disallow in CREATE/ALTER
> ROLE.  This test suite also adds a test to cover 390b3cbbb2af with an
> incomplete UTF8 sequence, as a nice bonus.

While thinking more about this one, I have come up with a smarter
query based on set_byte() to build a full range of byteas for the
ASCII characters to check, leading to this simpler pattern:
SELECT set_byte('\x00'::bytea, 0, a) FROM generate_series(0, 127);

A second thing that I have adjusted is the output for non-printable
characters, using a CASE/WHEN shortcut.  Attached is an updated
version of the patch set with these adjustments.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Soumya S Murali
Date:
Subject: Re: [Patch]Add tab completion for DELETE ... USING
Next
From: Chao Li
Date:
Subject: Re: guc: make dereference style consistent in check_backtrace_functions