Re: change password_encryption default to scram-sha-256?

On 4/8/19 2:28 PM, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
>> On 2019-04-08 13:34:12 -0400, Alvaro Herrera wrote:
>>> I'm not sure I understand all this talk about deferring changing the
>>> default to pg13. AFAICS only a few fringe drivers are missing support;
>>> not changing in pg12 means we're going to leave *all* users, even those
>>> whose clients have support, without the additional security for 18 more
>>> months.
>
>> Imo making such changes after feature freeze is somewhat poor
>> form.
>
> Yeah.

Yeah, that's fair.

>
>> If jdbc didn't support scram, it'd be an absolutely clear no-go imo. A
>> pretty large fraction of users use jdbc to access postgres. But it seems
>> to me that support has been merged for a while:
>> https://github.com/pgjdbc/pgjdbc/pull/1014
>
> "Merged to upstream" is a whole lot different from "readily available in
> the field". What's the actual status in common Linux distros, for
> example?

Did some limited research just to get a sense.

Well, if it's RHEL7, it's PostgreSQL 9.2 so, unless they're using our
RPM, that definitely does not have it :)

(While researching this, I noticed on the main RHEL8 beta page[1] that
PostgreSQL is actually featured, which is kind of neat. I could not
quickly find which version of the JDBC driver it is shipping with, though)

On Ubuntu, 18.04 LTS ships PG10, but the version of JDBC does not
include SCRAM support. 18.10 ships JDBC w/SCRAM support.

On Debian, stretch is on 9.4. buster has 11 packaged, and JDBC is
shipping with SCRAM support.

> The scenario that worries me here is somebody using a bleeding-edge PGDG
> server package in an environment where the rest of the Postgres ecosystem
> is much less bleeding-edge. The last time that situation would have
> caused them can't-connect problems was, um, probably when we introduced
> MD5 password encryption. So they won't be expecting to get blindsided by
> something like this.
>
> I'm particularly concerned about the idea that they won't see a problem
> during initial testing, only to have things fall over after they enter
> production and do a "routine" password change.

Yeah, I think all of the above is fair. It's been awhile since md5 was
added :)

So I think based on that and a quick look at the different distros
indicate that changing the default to PG12 has too much risk of
breakage, but PG13 would be a fair target as long as we start making
noise sooner (now?).

Jonathan

[1] https://developers.redhat.com/rhel8/