Re: Letting the client choose the protocol to use during a SASL exchange

Michael Paquier <michael.paquier@gmail.com>

From: Michael Paquier <michael.paquier@gmail.com>
To: Álvaro Hernández Tortosa <aht@8kdata.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Tom Lane <tgl@sss.pgh.pa.us>, Simon Riggs <simon@2ndquadrant.com>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2017-04-13T02:54:59Z
Lists: pgsql-hackers
On Thu, Apr 13, 2017 at 6:37 AM, Álvaro Hernández Tortosa
<aht@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.
-- 
Michael


Commits

  1. Improve the SASL authentication protocol.

  2. Refactor libpq authentication request processing.

  3. Minor cleanup of backend SCRAM code.