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

On 4/8/19 10:08 AM, Tom Lane wrote:
> "Jonathan S. Katz" <jkatz(at)postgresql(dot)org> writes:
>> On 4/8/19 8:49 AM, Magnus Hagander wrote:
>>> I think the real question is, is it OK to give them basically 5months
>>> warning, by right now saying if you don't have a release out in 6
>>> months, things will break.
>
>> Given the supported libraries all have open pull requests or issues, it
>> should be fairly easy to inquire if they would be able to support it for
>> PG12 vs PG13. If this sounds like a reasonable plan, I'm happy to reach
>> out and see.
>
> I think that the right course here is to notify these developers that
> we will change the default in PG13, and it'd be good if they put out
> stable releases with SCRAM support well before that.

+1; I'm happy to reach out with that messaging, referencing this thread.

> This discussion
> seems to be talking as though it's okay if we allow zero daylight
> between availability of fixed drivers and release of a PG version that
> defaults to using SCRAM. That'd be totally unfair to packagers and
> users. There needs to be a pretty fair-size window for those fixed
> drivers to propagate into the wild. A year is not too much; IMO it's
> barely enough.

I agree in principle, esp. related to testing + packaging (and I think
packaging would be my biggest concern), but IMV this primarily would
affect new applications, which is why I thought to provide reasoning for
a more aggressive timeline. You typically keep you pg.conf settings
consistent between version upgrades (with exceptions, e.g. based on
upgrade method). That could also inadvertently block people from
upgrading, too, but the bigger risk would be new application development
on PG12.

Looking at the uncovered user base too, it's not the largest portion of
our users, though accessing PostgreSQL via Go is certainly increasingly
rapidly so I'm very sympathetic that we don't break their accessibility
(and I've personally used asyncpg and would not want my apps to break
either :).

Anyway, I primarily wanted to see if an aggressive timeline to update
our default password approach would make sense esp. given we've had this
feature around for some time, and, again, it is far superior to the
other password based methods. I'm fine with being cautious, just wanted
to ensure we're not being too cautious about getting our users to
utilize a feature with better security.

Jonathan