Thread: [HACKERS] Re: Letting the client choose the protocol to use during a SASLexchange

On 04/06/2017 08:13 AM, Noah Misch wrote:
> If any SCRAM open item is a beta blocker, it's this one.  (But SASLprep is
> also in or near that status.)  Post-beta wire protocol changes are bad,
> considering beta is normally the time for projects like pgjdbc and npgsql to
> start adapting to such changes.
>
> [Action required within three days.  This is a generic notification.]
>
> The above-described topic is currently a PostgreSQL 10 open item.

I will work on this next week. I haven't given it much thought yet, but 
I think it's going to be pretty straightforward. It won't require much 
code yet, as we only support one SASL mechanism. We just need to ensure 
that we don't paint ourselves in the corner with the protocol.

- Heikki

On 06/04/17 19:05, Heikki Linnakangas wrote:
> On 04/06/2017 08:13 AM, Noah Misch wrote:
>> If any SCRAM open item is a beta blocker, it's this one.  (But 
>> SASLprep is
>> also in or near that status.)  Post-beta wire protocol changes are bad,
>> considering beta is normally the time for projects like pgjdbc and 
>> npgsql to
>> start adapting to such changes.
>>
>> [Action required within three days.  This is a generic notification.]
>>
>> The above-described topic is currently a PostgreSQL 10 open item.
>
> I will work on this next week. I haven't given it much thought yet, 
> but I think it's going to be pretty straightforward. It won't require 
> much code yet, as we only support one SASL mechanism. We just need to 
> ensure that we don't paint ourselves in the corner with the protocol.
>
>
    I think this could easily extended from the current message. SCRAM 
does not force any concrete way of negotiating the protocols supported. 
The current SASL message sends the only SCRAM method supported. I think 
it should be enough to make this a CSV, which for a single value, is the 
same as we have today (so no code change required, only documentation). 
The other message that needs to be changed is the password one, the 
first time the client sends the SCRAM "client-first-message", which 
needs to contain the algorithm selected. As of today, that could be a 
constant (at least in the code) and validate is value.
    So I guess code changes would be minimal. I could be wrong, of course.
    I'm working myself on Java's (pgjdbc) implementation, and I will 
hopefully have a prototype by next week to try it.

    Álvaro

-- 

Álvaro Hernández Tortosa


-----------
<8K>data