Re: [HACKERS] Implementation of SASLprep for SCRAM-SHA-256

2017-04-10 Thread Michael Paquier
On Mon, Apr 10, 2017 at 5:11 PM, Heikki Linnakangas wrote: > Here are some characters that seem plausible to be misinterpreted and > ignored by SASLprep: > EUC-JP and EUC-JISX0213: > > U+00AD (C2 AD): 足 (meaning "foot", per Unihan database) > U+FE00-FE0F (EF B8 8X): 鏝 (meaning

Re: [HACKERS] Implementation of SASLprep for SCRAM-SHA-256

2017-04-10 Thread Heikki Linnakangas
On 04/06/2017 07:59 PM, Heikki Linnakangas wrote: Another thing I'd like some more eyes on, is how this will work with encodings other than UTF-8. We will now try to normalize the password as if it was in UTF-8, even if it isn't. That's OK as long as we're consistent about it, but there is one

Re: [HACKERS] Implementation of SASLprep for SCRAM-SHA-256

2017-04-07 Thread Michael Paquier
On Fri, Apr 7, 2017 at 8:58 PM, Heikki Linnakangas wrote: > On 04/07/2017 05:30 AM, Michael Paquier wrote: >> I am really wondering if this should not reflect the real range >> reported by the RFC. I understand that you have grouped things to save >> a couple of bytes, but that

Re: [HACKERS] Implementation of SASLprep for SCRAM-SHA-256

2017-04-07 Thread Heikki Linnakangas
On 04/07/2017 05:30 AM, Michael Paquier wrote: On Fri, Apr 7, 2017 at 2:47 AM, Heikki Linnakangas wrote: On 04/06/2017 08:42 PM, Heikki Linnakangas wrote: There is for example this portion in the new tables: +static const Codepoint prohibited_output_chars[] = +{ + 0xD800,

Re: [HACKERS] Implementation of SASLprep for SCRAM-SHA-256

2017-04-06 Thread Michael Paquier
On Fri, Apr 7, 2017 at 2:47 AM, Heikki Linnakangas wrote: > On 04/06/2017 08:42 PM, Heikki Linnakangas wrote: >>> There is for example this portion in the new tables: >>> +static const Codepoint prohibited_output_chars[] = >>> +{ >>> + 0xD800, 0xF8FF, /* C.3, C.5 */

Re: [HACKERS] Implementation of SASLprep for SCRAM-SHA-256

2017-04-06 Thread Heikki Linnakangas
On 04/06/2017 08:42 PM, Heikki Linnakangas wrote: D'oh. Here's a new version, with saslprep.h included. And here it is for real. Sigh. There is for example this portion in the new tables: +static const Codepoint prohibited_output_chars[] = +{ + 0xD800, 0xF8FF, /* C.3, C.5 */

Re: [HACKERS] Implementation of SASLprep for SCRAM-SHA-256

2017-04-06 Thread Heikki Linnakangas
(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 wrote: Attached is a new version. Notable changes since yesterday: * Implemented the rest of the SASLPrep,

Re: [HACKERS] Implementation of SASLprep for SCRAM-SHA-256

2017-04-06 Thread Heikki Linnakangas
Another version attached. I think this is now in committable state, but there's been a lot of small changes here and there, so please have one more look over it if you have a chance. I'm planning to push this tomorrow, after sleeping on it. The code-organization issue with the utf8

Re: [HACKERS] Implementation of SASLprep for SCRAM-SHA-256

2017-04-06 Thread Michael Paquier
On Thu, Apr 6, 2017 at 1:33 AM, Heikki Linnakangas 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 >

Re: [HACKERS] Implementation of SASLprep for SCRAM-SHA-256

2017-04-05 Thread Heikki Linnakangas
On 04/05/2017 07:23 AM, Michael Paquier wrote: fore On Wed, Apr 5, 2017 at 7:05 AM, Heikki Linnakangas wrote: I will continue tomorrow, but I wanted to report on what I've done so far. Attached is a new patch version, quite heavily modified. Notable changes so far: Great,

Re: [HACKERS] Implementation of SASLprep for SCRAM-SHA-256

2017-04-04 Thread Michael Paquier
fore On Wed, Apr 5, 2017 at 7:05 AM, Heikki Linnakangas wrote: > I will continue tomorrow, but I wanted to report on what I've done so far. > Attached is a new patch version, quite heavily modified. Notable changes so > far: Great, thanks! > * Use Unicode codepoints, rather

Re: [HACKERS] Implementation of SASLprep for SCRAM-SHA-256

2017-04-04 Thread Heikki Linnakangas
On 04/04/2017 01:52 PM, Heikki Linnakangas wrote: On 03/31/2017 10:10 AM, Michael Paquier wrote: On Wed, Mar 8, 2017 at 10:39 PM, Robert Haas wrote: On Tue, Mar 7, 2017 at 10:01 PM, Michael Paquier wrote: I kinda hope Heikki is going to step

Re: [HACKERS] Implementation of SASLprep for SCRAM-SHA-256

2017-04-04 Thread Heikki Linnakangas
On 03/31/2017 10:10 AM, Michael Paquier wrote: On Wed, Mar 8, 2017 at 10:39 PM, Robert Haas wrote: On Tue, Mar 7, 2017 at 10:01 PM, Michael Paquier wrote: I kinda hope Heikki is going to step up to the plate here, because I think he

Re: [HACKERS] Implementation of SASLprep for SCRAM-SHA-256

2017-03-31 Thread Michael Paquier
On Wed, Mar 8, 2017 at 10:39 PM, Robert Haas wrote: > On Tue, Mar 7, 2017 at 10:01 PM, Michael Paquier > wrote: >> This way, we can be sure that two UTf-8 strings are considered as >> equivalent in a SASL exchange, in our case we care about the

Re: [HACKERS] Implementation of SASLprep for SCRAM-SHA-256

2017-03-08 Thread Robert Haas
On Tue, Mar 7, 2017 at 10:01 PM, Michael Paquier wrote: > RFC5802 (https://tools.ietf.org/html/rfc5802) regarding the > implementation of SCRAM, needs to have passwords normalized as per > RFC4013 (https://tools.ietf.org/html/rfc4013) using SASLprep, which is > actually

[HACKERS] Implementation of SASLprep for SCRAM-SHA-256

2017-03-07 Thread Michael Paquier
Hi all, Here is another thread for an issue related to SCRAM (https://www.postgresql.org/message-id/243d8c11-6149-a4bb-0909-136992f74...@iki.fi), that can be discussed independently: SASLprep. RFC5802 (https://tools.ietf.org/html/rfc5802) regarding the implementation of SCRAM, needs to have