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 "trowel", per Unihan
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 wo
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 would protect from
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, 0xF8FF,
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 */
>>>
>>>-
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 */
(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, mapping some char
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 functions,
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
> strings.
>
> * Mov
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, thanks!
* Use Uni
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 than UTF-8 bytes pac
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 up to the plate here, because I
think he understand
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 understands most of it already.
The second person who knows
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 password
>> string (we should care about the usernam
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 NFKC. I have previously des
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 passw
16 matches
Mail list logo