(Adding Heikki here because that concerns him as well)
On Mon, Nov 20, 2017 at 2:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
>> The attached patch,
>> for REL_10_STABLE, allows a server to accept as well as input "eSws",
>> which is a combination that can now happen. This way, a v10 server
>> accepts connections from a v11 and newer client with SSL.
>
> This is not an acceptable fix. We have to maintain the ability to connect
> to unpatched older servers. If features added to HEAD have broken that,
> either we fix those features to be backwards compatible, or we revert
> them.
Well, when doing the SASL exchange the client does not know what is
the backend version. If we'd know that it would then be possible to
enforce a "n" flag conditionally from the client. So in order to be
backward-compatible we could send unconditionally a "n" flag from a
v11 client even in an SSL context. But that would not actually be true
because the client is able to support channel binding in this case, so
we would make libpq not RFC-compliant.
v10 has not been out for a long time, so this can plead in favor of a
change, and SCRAM is not spread yet. It is really unfortunate that we
did not notice that during at the moment SCRAM has been implemented.
That's clearly a bug of v10.
Honestly I am of the opinion to do a proper fix now and have things in
a clean state which is RFC-compliant instead of maintaining for 10
years a backward-compatible change in libpq that would be only valid
for 10.0 and 10.1 (assuming that the server-side fix is added in
10.2). Note that we need to fix the v10 server anyway with something
like the patch upthread. The enforcement of this "n" flag can just
happen in a v11-client.
--
Michael
