Re: Implementation of SASLprep for SCRAM-SHA-256

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Implementation of SASLprep for SCRAM-SHA-256
Date: 2017-04-06 17:42:58
Message-ID: 2c42013a-9ecd-1eb4-ee09-2313a1d74b2b@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

(sorry, I didn't notice your email until after I just sent version 4!)

On 04/06/2017 10:32 AM, Michael Paquier wrote:
> On Thu, Apr 6, 2017 at 1:33 AM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>> Attached is a new version. Notable changes since yesterday:
>>
>> * Implemented the rest of the SASLPrep, mapping some characters to spaces,
>> leaving out others, and checking for prohibited characters and bidirectional
>> strings.
>>
>> * Moved things around. There's now a separate directory, src/common/unicode,
>> which contains the perl scripts and the test code. Those are not needed to
>> build from source, as the pre-generated tables are put in
>> src/include/common. Similar to the scripts in src/backend/utils/mb/Unicode,
>> really.
>>
>> * Renamed many things from utf_* to unicode_*, since they don't deal with
>> utf-8 input anymore.
>>
>> This is starting to shape up, but still some cleanup work to do. I will
>> continue tomorrow..
>
> Thanks for the new patch, that's looking nice. Now I was not able to
> compile it as saslprep.h is missing from what you have sent...

D'oh. Here's a new version, with saslprep.h included.

> There is for example this portion in the new tables:
> +static const Codepoint prohibited_output_chars[] =
> +{
> + 0xD800, 0xF8FF, /* C.3, C.5 */
>
> ----- Start Table C.5 -----
> D800-DFFF; [SURROGATE CODES]
> ----- End Table C.5 -----
> This indicates a range of values. Wouldn't it be better to split this
> table in two, one for the range of codepoints and another one with the
> single entries?

I considered that, but there are relatively few singular codepoints in
the tables, so it wouldn't save much space. In this patch, singular
codepoints are represented by a range like "0x3000, 0x3000".

> + 0x1D173, 0x1D17A, /* C.2.2 */
> This is for musical symbols. It seems to me that checking for a range
> is what is intended.

Can you elaborate?

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2017-04-06 17:47:12 Re: Implementation of SASLprep for SCRAM-SHA-256
Previous Message Peter Eisentraut 2017-04-06 17:38:41 Re: logical replication apply to run with sync commit off by default