(Adding Heikki here because that concerns him as well) On Mon, Nov 20, 2017 at 2:04 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Michael Paquier <michael.paqu...@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
