On 13/04/17 13:24, Heikki Linnakangas wrote:
On 04/13/2017 05:54 AM, Michael Paquier wrote:
On Thu, Apr 13, 2017 at 6:37 AM, Álvaro Hernández Tortosa
By looking at the them, and unless I'm missing something, I
how the extra information for the future implementation of channel
would be added (without changing the protocol). Relevant part is:
The message body is a list of SASL authentication mechanisms, in the
server's order of preference. A zero byte is required as terminator
the last authentication mechanism name. For each mechanism, there is
Name of a SASL authentication mechanism.
How do you plan to implement it, in future versions, without
the AuthenticationSASL message? Or is it OK to add new fields to a
in future PostgreSQL versions, without considering that a protocol
I don't quite understand the complain here, it is perfectly fine to
add as many null-terminated names as you want with this model. The
patches would make the server just send one mechanism name now, but
nothing prevents the addition of more.
Right, when we get channel binding, the server will list
"SCRAM-SHA-256" and "SCRAM-SHA-256-PLUS" as the list of mechanisms.
And if we get channel binding using something else than tls-unique,
then those will be added as extra mechanisms, too, e.g.
And how about supporting different SCRAM mechanisms with different
possible channel bindings? Separate by space too? So given a field, is
the first item the SCRAM mechanism, and all the remaning the channel
binding methods? I.e.:
SCRAM-SHA-256-PLUS tls-awesome tls-awesome2 tls-awesome3\0...
Please note that if this is the solution chosen:
- A lot of parsing and convention is required (first arg is the SCRAM
mechanism, succesive are channel binding; tls-unique is always
- Channel binding names will be repeated for every SCRAM mechanism with
"-PLUS". This is not needed, SCRAM mechanisms and channel binding are
- Channel binding names will not be present on others, making the parser
even more complex.
All this vs, again, stating SCRAM mechanisms on one list and
channel binding on another list, which is to my much more KISS. But...
anyway, if this is the decision made, at least I think this should be
documented now, because client parsers need to be designed one way or
Álvaro Hernández Tortosa
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: