On 04/13/2017 05:54 AM, Michael Paquier wrote:
On Thu, Apr 13, 2017 at 6:37 AM, Álvaro Hernández Tortosa <a...@8kdata.com> wrote:By looking at the them, and unless I'm missing something, I don't see how the extra information for the future implementation of channel binding 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 after the last authentication mechanism name. For each mechanism, there is the following: <variablelist> <varlistentry> <term> String </term> <listitem> <para> Name of a SASL authentication mechanism. </para> </listitem> </varlistentry> </variablelist> How do you plan to implement it, in future versions, without modifying the AuthenticationSASL message? Or is it OK to add new fields to a message in future PostgreSQL versions, without considering that a protocol change?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. "SCRAM-SHA-256-PLUS tls-awesome".
I don't think that needs to be discussed in the docs yet, because a client will simply ignore any mechanisms it doesn't understand. Although perhaps it would be good to mention explicitly that even though SASL defines that mechanism names have a particular format - all ASCII upper-case, max 20 chars - the client should accept and ignore arbitrary strings, not limited to that format.
- Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
