Обсуждение: change password_encryption default to scram-sha-256?
Should we change the default of the password_encryption setting to 'scram-sha-256' in PG12? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> Should we change the default of the password_encryption setting to
> 'scram-sha-256' in PG12?
I thought we were going to wait a bit longer --- that just got added
last year, no? What do we know about the state of support in client
libraries?
regards, tom lane
On Sun, Apr 07, 2019 at 12:59:05PM -0400, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: > > Should we change the default of the password_encryption setting to > > 'scram-sha-256' in PG12? > > I thought we were going to wait a bit longer --- that just got added > last year, no? What do we know about the state of support in client > libraries? Great idea! Does it make sense to test all, or at least some significant fraction of the connectors listed in https://wiki.postgresql.org/wiki/Client_Libraries by default? Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
On Sun, Apr 07, 2019 at 08:23:06PM +0200, David Fetter wrote: > Great idea! Does it make sense to test all, or at least some > significant fraction of the connectors listed in > https://wiki.postgresql.org/wiki/Client_Libraries by default? This is a more interesting list: https://wiki.postgresql.org/wiki/List_of_drivers From what I can see, the major drivers not using directly libpq support our SASL protocol: JDBC and npgsql. However I can count three of them which still don't support it: Crystal, pq (Go) and asyncpg. pq and asyncpg are very popular on github, with at least 3000 stars each, which is a lot I think. I have also double-checked their source code and I am seeing no trace of SASL or SCRAM, so it seems to me that we may want to wait more before switching the default. -- Michael
Вложения
Michael Paquier <michael@paquier.xyz> writes:
> From what I can see, the major drivers not using directly libpq
> support our SASL protocol: JDBC and npgsql. However I can count three
> of them which still don't support it: Crystal, pq (Go) and asyncpg.
> pq and asyncpg are very popular on github, with at least 3000 stars
> each, which is a lot I think. I have also double-checked their source
> code and I am seeing no trace of SASL or SCRAM, so it seems to me that
> we may want to wait more before switching the default.
Perhaps we could reach out to the authors of those libraries,
and encourage them to provide support in the next year or so?
I don't doubt that switching to scram-sha-256 is a good idea in
the long run. The idea here was to give driver authors a reasonable
amount of time to update. I don't really think that one year
counts as a "reasonable amount of time" given how slowly this
project moves overall ... but we don't want to wait forever ...
regards, tom lane
Hi, On 2019-04-08 01:34:42 -0400, Tom Lane wrote: > Michael Paquier <michael@paquier.xyz> writes: > > From what I can see, the major drivers not using directly libpq > > support our SASL protocol: JDBC and npgsql. However I can count three > > of them which still don't support it: Crystal, pq (Go) and asyncpg. > > pq and asyncpg are very popular on github, with at least 3000 stars > > each, which is a lot I think. I have also double-checked their source > > code and I am seeing no trace of SASL or SCRAM, so it seems to me that > > we may want to wait more before switching the default. > > Perhaps we could reach out to the authors of those libraries, > and encourage them to provide support in the next year or so? Seems go/pq might get it soon-ish: https://github.com/lib/pq/pull/833 There doesn't appear to be much movement on the crystal front ( https://github.com/will/crystal-pg/issues/154 ), but I don't think it's popular enough to really worry. There's an issue for asyncpg https://github.com/MagicStack/asyncpg/issues/314 - but not too much movement either. Greetings, Andres Freund
On 08/04/2019 08:42, Andres Freund wrote: > Seems go/pq might get it soon-ish: https://github.com/lib/pq/pull/833 I wouldn't hold my breath. That's the third PR to add SCRAM support already, see also https://github.com/lib/pq/pull/788 and https://github.com/lib/pq/pull/608. The project seems to lack the committer manpower or round tuits to review and push these. - Heikki
On Mon, Apr 08, 2019 at 09:08:05AM +0300, Heikki Linnakangas wrote: > I wouldn't hold my breath. That's the third PR to add SCRAM support already, > see also https://github.com/lib/pq/pull/788 and > https://github.com/lib/pq/pull/608. The project seems to lack the committer > manpower or round tuits to review and push these. I am wondering on the contrary if switching the default on Postgres side would make things move faster on their side though. -- Michael
Вложения
Hi > I am wondering on the contrary if switching the default on Postgres > side would make things move faster on their side though. I think we need give more time before change default. I suggest not to repeat the quick change of default to a new valueas it was in the MySQL 8.0 last year [1]. *1 https://mysqlserverteam.com/upgrading-to-mysql-8-0-default-authentication-plugin-considerations/ regards, Sergei
On Mon, Apr 8, 2019 at 2:38 AM Michael Paquier <michael@paquier.xyz> wrote: > > On Mon, Apr 08, 2019 at 09:08:05AM +0300, Heikki Linnakangas wrote: > > I wouldn't hold my breath. That's the third PR to add SCRAM support already, > > see also https://github.com/lib/pq/pull/788 and > > https://github.com/lib/pq/pull/608. The project seems to lack the committer > > manpower or round tuits to review and push these. > > I am wondering on the contrary if switching the default on Postgres > side would make things move faster on their side though. Yeah, if we're not going to do it now we should announce that we will do it in the next release. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2019-04-08 13:52, Andrew Dunstan wrote: > Yeah, if we're not going to do it now we should announce that we will > do it in the next release. Targeting PG13 seems reasonable. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 4/8/19 8:19 AM, Peter Eisentraut wrote: > On 2019-04-08 13:52, Andrew Dunstan wrote: >> Yeah, if we're not going to do it now we should announce that we will >> do it in the next release. > > Targeting PG13 seems reasonable. Counter-argument: SCRAM has been available for 2 years since 10 feature freeze, there has been a lot of time already given to implement support for it. Given is at least 5 months until PG12 comes out, and each of the popular drivers already has patches in place, we could default it for 12 and let them know this is a reality. Given it's superior to the existing methods, it'd be better to encourage the drivers to get this in place sooner. Given what I know about md5, I've tried to avoid building apps with drivers that don't support SCRAM. That said, that would be an aggressive approach, so I would not object to changing the default for PG13 and giving 17 months vs. 5, but we do let md5 persist that much longer. Jonathan
Вложения
On Mon, Apr 8, 2019 at 2:38 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
On 4/8/19 8:19 AM, Peter Eisentraut wrote:
> On 2019-04-08 13:52, Andrew Dunstan wrote:
>> Yeah, if we're not going to do it now we should announce that we will
>> do it in the next release.
>
> Targeting PG13 seems reasonable.
Yeah, that would be fairly consistent with how we usually do htings
Counter-argument: SCRAM has been available for 2 years since 10 feature
freeze, there has been a lot of time already given to implement support
for it. Given is at least 5 months until PG12 comes out, and each of the
popular drivers already has patches in place, we could default it for 12
and let them know this is a reality.
You can't really count feature freeze, you have to count release I think. And basically we're saying they had 2 years. Which in itself would've been perfectly reasonable, *if we told them*. But we didn't.
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 it's superior to the existing methods, it'd be better to encourage
the drivers to get this in place sooner. Given what I know about md5,
I've tried to avoid building apps with drivers that don't support SCRAM.
That said, that would be an aggressive approach, so I would not object
to changing the default for PG13 and giving 17 months vs. 5, but we do
let md5 persist that much longer.
I think we definitely should not make it *later* than 13.
Maybe we should simply reach out to those driver developers, it's not that many of them after all, and *ask* if they would think it's a problem if we change it in 12.
On 4/8/19 8:49 AM, Magnus Hagander wrote: > On Mon, Apr 8, 2019 at 2:38 PM Jonathan S. Katz <jkatz@postgresql.org > <mailto:jkatz@postgresql.org>> wrote: > Counter-argument: SCRAM has been available for 2 years since 10 feature > freeze, there has been a lot of time already given to implement support > for it. Given is at least 5 months until PG12 comes out, and each of the > popular drivers already has patches in place, we could default it for 12 > and let them know this is a reality. > > > You can't really count feature freeze, you have to count release I > think. And basically we're saying they had 2 years. Which in itself > would've been perfectly reasonable, *if we told them*. But we didn't. > > 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. Yeah, that's a good and fair question. > That said, that would be an aggressive approach, so I would not object > to changing the default for PG13 and giving 17 months vs. 5, but we do > let md5 persist that much longer. > > > I think we definitely should not make it *later* than 13. +1 > Maybe we should simply reach out to those driver developers, it's not > that many of them after all, and *ask* if they would think it's a > problem if we change it in 12. It wouldn't hurt. I went through the list again[1] to see which ones don't have it and updated: - pgsql (Erlang) - this webpage doesn't load, maybe we should remove? It may have been replaced by this one[2]? - erlang-pgsql-driver (Erlang) - on the page it says it's unsupported, so we should definitely remove it from the wiki and from consideration - node-postgres (JavaScript) - they added SCRAM in 7.9.0 so I've updated the wiki - pq (Go) - No; as mentioned there are 3 separate patches in consideration - crystal-pg (Ruby) No; open issue, not patch - asyncpg (Python) No; open issue, suggestion on how to implement but no patch Let me also add: - pgx (Go)[3] - another popular Go driver, there is an open patch for SCRAM support So IMV it's pq, crystal-pg, asyncpg, & pgx we have to reach out to, pending resolution on Erlang libs. 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. Jonathan [1] https://wiki.postgresql.org/wiki/List_of_drivers [2] https://github.com/semiocast/pgsql [3] https://github.com/jackc/pgx
Вложения
"Jonathan S. Katz" <jkatz@postgresql.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. 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.
regards, tom lane
On 4/8/19 10:08 AM, Tom Lane wrote: > "Jonathan S. Katz" <jkatz@postgresql.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
Вложения
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. IIUC the vast majority of clients already support SCRAM auth. So the vast majority of PG users can take advantage of the additional security. I think the only massive-adoption exception is JDBC, and apparently they already have working patches for SCRAM. Like many other configuration parameters, setting the default for this one is a trade-off: give the most benefit to most users, causing the least possible pain to users for whom the default is not good. Users that require opening connections from clients that have not updated should just set password_encryption to md5. It's not like things will suddenly blow up in their faces. IMO we don't need to wait until every single client in existence has updated to support SCRAM. After all, they've already had two years. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hi, 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. These arguments would have made a ton more sense at the *beginning* of the v12 development cycle, because that'd have given all these driver authors a lot more heads up. > IIUC the vast majority of clients already support SCRAM auth. So the > vast majority of PG users can take advantage of the additional security. > I think the only massive-adoption exception is JDBC, and apparently they > already have working patches for SCRAM. 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 Greetings, Andres Freund
Andres Freund <andres@anarazel.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. > 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? 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. regards, tom lane
On 4/8/19 2:28 PM, Tom Lane wrote: > Andres Freund <andres@anarazel.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/
Вложения
On Mon, Apr 08, 2019 at 02:28:30PM -0400, Tom Lane wrote: >On Mon, Apr 08, 2019 at 10:41:07AM -0700, Andres Freund wrote: >> 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? I found: https://jdbc.postgresql.org/documentation/changelog.html#version_42.2.1 Version 42.2.0 (2018-01-17) Added Support SCRAM-SHA-256 for PostgreSQL 10 in the JDBC 4.2 version (Java 8+) using the Ongres SCRAM library. PR 842 I see that's in ubuntu, but not any LTS release: https://packages.ubuntu.com/search?keywords=libpostgresql-jdbc-java And in Debian testing, but no released version: https://packages.debian.org/search?keywords=libpostgresql-jdbc-java For centos6/7, OS packages would not have scram support: $ yum list --showdupl postgresql-jdbc Available Packages postgresql-jdbc.noarch 9.2.1002-6.el7_5 base postgresql-jdbc.noarch 42.2.5-1.rhel7.1 pgdg11 $ yum list --showdupl postgresql-jdbc Available Packages postgresql-jdbc.noarch 8.4.704-2.el6 base postgresql-jdbc.noarch 42.2.5-1.rhel6.1 pgdg11 > 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. If someone installs a postgres RPM/DEB from postgresql.org, they could also install postgresql-jdbc, right ? I realize that doesn't mean that people will consistently know to and actually do that. If the default were changed, possibly the PGDG package could define something like (I haven't done packaging in a long time): Conflicts: postgresql-jdbc<42.2.0 On Mon, Apr 08, 2019 at 03:18:42PM -0400, Jonathan S. Katz wrote: > Well, if it's RHEL7, it's PostgreSQL 9.2 so, unless they're using our > RPM, that definitely does not have it :)
Alvaro,
On Mon, 8 Apr 2019 at 13:34, Alvaro Herrera <alvherre@2ndquadrant.com> 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.
IIUC the vast majority of clients already support SCRAM auth. So the
vast majority of PG users can take advantage of the additional security.
I think the only massive-adoption exception is JDBC, and apparently they
already have working patches for SCRAM.
We have more than patches this is already in the driver.
What do you mean by "massive-adoption exception"
On Mon, 8 Apr 2019 at 15:18, Jonathan S. Katz <jkatz@postgresql.org> wrote:
On 4/8/19 2:28 PM, Tom Lane wrote:
> Andres Freund <andres@anarazel.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.
Honestly what JDBC driver XYZ distro ships with is a red herring. Any reasonably complex java program is going to use maven and pull it's dependencies.
That said from a driver developer, I support pushing this decision off to PG13
On 2019-Apr-08, Dave Cramer wrote: > > IIUC the vast majority of clients already support SCRAM auth. So the > > vast majority of PG users can take advantage of the additional security. > > I think the only massive-adoption exception is JDBC, and apparently they > > already have working patches for SCRAM. > > We have more than patches this is already in the driver. > > What do you mean by "massive-adoption exception" I meant an exception to the common situation that SCRAM-SHA-256 is supported and shipped in stable releases of each driver. The wiki here still says it's unsupported on JDBC: https://wiki.postgresql.org/wiki/List_of_drivers For once I'm happy to learn that the wiki is outdated :-) -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Mon, 8 Apr 2019 at 16:07, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
On 2019-Apr-08, Dave Cramer wrote:
> > IIUC the vast majority of clients already support SCRAM auth. So the
> > vast majority of PG users can take advantage of the additional security.
> > I think the only massive-adoption exception is JDBC, and apparently they
> > already have working patches for SCRAM.
>
> We have more than patches this is already in the driver.
>
> What do you mean by "massive-adoption exception"
I meant an exception to the common situation that SCRAM-SHA-256 is
supported and shipped in stable releases of each driver. The wiki here
still says it's unsupported on JDBC:
https://wiki.postgresql.org/wiki/List_of_drivers
For once I'm happy to learn that the wiki is outdated :-)
Way too many places to update :)
On 2019-Apr-08, Dave Cramer wrote: > On Mon, 8 Apr 2019 at 16:07, Alvaro Herrera <alvherre@2ndquadrant.com> > wrote: > > I meant an exception to the common situation that SCRAM-SHA-256 is > > supported and shipped in stable releases of each driver. The wiki here > > still says it's unsupported on JDBC: > > https://wiki.postgresql.org/wiki/List_of_drivers > > For once I'm happy to learn that the wiki is outdated :-) > > Way too many places to update :) Yeah. Actually, it's up to date (it says "yes from 42.2")... I just misread it. I wonder why we have two pages https://wiki.postgresql.org/wiki/Client_Libraries https://wiki.postgresql.org/wiki/List_of_drivers -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 4/8/19 4:10 PM, Alvaro Herrera wrote: > On 2019-Apr-08, Dave Cramer wrote: > >> On Mon, 8 Apr 2019 at 16:07, Alvaro Herrera <alvherre@2ndquadrant.com> >> wrote: > >>> I meant an exception to the common situation that SCRAM-SHA-256 is >>> supported and shipped in stable releases of each driver. The wiki here >>> still says it's unsupported on JDBC: >>> https://wiki.postgresql.org/wiki/List_of_drivers >>> For once I'm happy to learn that the wiki is outdated :-) >> >> Way too many places to update :) > > Yeah. Actually, it's up to date (it says "yes from 42.2")... I just > misread it. > > I wonder why we have two pages > https://wiki.postgresql.org/wiki/Client_Libraries > https://wiki.postgresql.org/wiki/List_of_drivers No clue, but it appears that first one is the newer of the two[1][2] I'd be happy to consolidate them and provide a forwarding reference from Client Libraries to List of Drivers, given I think we reference "List of Drivers" in other places. Jonathan [1] https://wiki.postgresql.org/index.php?title=Client_Libraries&action=history [2] https://wiki.postgresql.org/index.php?title=List_of_drivers&action=history
Вложения
Justin Pryzby <pryzby@telsasoft.com> writes:
> On Mon, Apr 08, 2019 at 02:28:30PM -0400, Tom Lane wrote:
>> 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.
> If someone installs a postgres RPM/DEB from postgresql.org, they could also
> install postgresql-jdbc, right ?
The client software is very possibly not on the same machine as the server,
and may indeed not be under the server admin's control. That sort of
complex interdependency is why we need to move slowly on changes that
require client updates.
regards, tom lane
On 2019-Apr-08, Jonathan S. Katz wrote: > On 4/8/19 4:10 PM, Alvaro Herrera wrote: > > I wonder why we have two pages > > https://wiki.postgresql.org/wiki/Client_Libraries > > https://wiki.postgresql.org/wiki/List_of_drivers > > No clue, but it appears that first one is the newer of the two[1][2] > > I'd be happy to consolidate them and provide a forwarding reference from > Client Libraries to List of Drivers, given I think we reference "List of > Drivers" in other places. There are two links to List of drivers, and one of them is in Client Libraries :-) https://wiki.postgresql.org/wiki/Special:WhatLinksHere/Client_Libraries +1 for consolidation and setting up a redirect. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2019-Apr-08, Tom Lane wrote: > 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. This is a fair objection. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
> 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.
If someone installs a postgres RPM/DEB from postgresql.org, they could also
install postgresql-jdbc, right ?
No, this is not how the majority of people use Java at all. They would use Maven to pull down the JDBC driver of choice.
I would guess there might be some distro specific java apps that might actually use what is on the machine but as mentioned any reasonably complex Java app is going to ensure it has the correct versions for their app using Maven.
Dave Cramer <pg@fastcrypt.com> writes:
>> If someone installs a postgres RPM/DEB from postgresql.org, they could
>> also install postgresql-jdbc, right ?
> I would guess there might be some distro specific java apps that might
> actually use what is on the machine but as mentioned any reasonably complex
> Java app is going to ensure it has the correct versions for their app using
> Maven.
I'm not really sure if that makes things better or worse. If some app
thinks that it needs version N of the driver, but SCRAM support was
added in version N-plus-something, how tough is it going to be to get
it updated? And are you going to have to go through that dance for
each app separately?
regards, tom lane
On Mon, 8 Apr 2019 at 16:38, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Dave Cramer <pg@fastcrypt.com> writes:
>> If someone installs a postgres RPM/DEB from postgresql.org, they could
>> also install postgresql-jdbc, right ?
> I would guess there might be some distro specific java apps that might
> actually use what is on the machine but as mentioned any reasonably complex
> Java app is going to ensure it has the correct versions for their app using
> Maven.
I'm not really sure if that makes things better or worse. If some app
thinks that it needs version N of the driver, but SCRAM support was
added in version N-plus-something, how tough is it going to be to get
it updated? And are you going to have to go through that dance for
each app separately?
I see the problem you are contemplating, but even installing a newer version of the driver has it's perils (we have been known to break some expectations in the name of the spec).
So I could see a situation where there is a legacy app that wants to use SCRAM. They update the JDBC jar on the system and due to the "new and improved" version their app breaks.
Honestly I don't have a solution to this.
That said 42.2.0 was released in January 2018, so by PG13 it's going to be 4 years old.
Dave
Dave Cramer <pg@fastcrypt.com> writes:
> That said 42.2.0 was released in January 2018, so by PG13 it's going to be
> 4 years old.
Huh? 13 should come out in the fall of 2020.
regards, tom lane
On 4/8/19 4:20 PM, Alvaro Herrera wrote: > On 2019-Apr-08, Jonathan S. Katz wrote: > >> On 4/8/19 4:10 PM, Alvaro Herrera wrote: > >>> I wonder why we have two pages >>> https://wiki.postgresql.org/wiki/Client_Libraries >>> https://wiki.postgresql.org/wiki/List_of_drivers >> >> No clue, but it appears that first one is the newer of the two[1][2] >> >> I'd be happy to consolidate them and provide a forwarding reference from >> Client Libraries to List of Drivers, given I think we reference "List of >> Drivers" in other places. > > There are two links to List of drivers, and one of them is in Client > Libraries :-) > https://wiki.postgresql.org/wiki/Special:WhatLinksHere/Client_Libraries > > +1 for consolidation and setting up a redirect. OK, so trying to not be too off topic, I did update the original page as so: https://wiki.postgresql.org/wiki/List_of_drivers When determining what to add, I tried to keep it one-abstraction level deep, i.e., a driver is implemented on top of libpq, implemented the PG protocol on its own, or did some driver-like extensions on top of the base language driver. I steered clear of ORMs or other abstraction layers unless they met the above criteria. (There are a lot of handy ORM-ish abstraction layers as well, but I don't want to go down that path on that page, at least not today). I also added a deprecation warning on top of the "Client Libraries" page. If we're feeling satisfied with the consolidation, I'll wipe the content and indicate where the maintained content is and end the split-brain situation. (One thing that I will say is this is one of those sections that may be worth moving to pgweb, to give it some semi-permanence. Separate discussion.) The good news: while going through the added drivers, most of the non-libpq ones I've added do support SCRAM :) That said, I am still in favor of the PG13 plan, and without objection I would like to reach out to the driver authors in the "no" category, reference this thread, and that this is at least discussed, if not decided upon, and they should considering adding support for SCRAM to allow adequate testing time as well as time for their drivers to make it into appropriate packaging systems. Jonathan
Вложения
> On Sun, Apr 07, 2019 at 12:59:05PM -0400, Tom Lane wrote: >> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: >> > Should we change the default of the password_encryption setting to >> > 'scram-sha-256' in PG12? >> >> I thought we were going to wait a bit longer --- that just got added >> last year, no? What do we know about the state of support in client >> libraries? > > Great idea! Does it make sense to test all, or at least some > significant fraction of the connectors listed in > https://wiki.postgresql.org/wiki/Client_Libraries by default? I am not sure all third party programs concerning scram-sha-256 are listed on this. There are some programs that talk to PostgreSQL using frontend/backend protocol, but not based on libpq or other native drivers (for example Pgpool-II). I guess PgBouncer is in the same category too. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
Em seg, 8 de abr de 2019 às 19:43, Tatsuo Ishii <ishii@sraoss.co.jp> escreveu: > > I am not sure all third party programs concerning scram-sha-256 are > listed on this. There are some programs that talk to PostgreSQL using > frontend/backend protocol, but not based on libpq or other native > drivers (for example Pgpool-II). I guess PgBouncer is in the same > category too. > ... and pgbouncer doesn't support scram-sha-256 authentication method. There is a bit-rot PR but the discussion died a while ago. It is widely used and it would be really sad to turn on SCRAM on v13 without pgbouncer SCRAM support. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
>> I am not sure all third party programs concerning scram-sha-256 are >> listed on this. There are some programs that talk to PostgreSQL using >> frontend/backend protocol, but not based on libpq or other native >> drivers (for example Pgpool-II). I guess PgBouncer is in the same >> category too. >> > ... and pgbouncer doesn't support scram-sha-256 authentication method. > There is a bit-rot PR but the discussion died a while ago. It is > widely used and it would be really sad to turn on SCRAM on v13 without > pgbouncer SCRAM support. I don't how hard it would be for pgbouncer to support scram-sha-256, but it was pretty hard for Pgpool-II to support scram-sha-256. In case of Pgpool-II (it starts to support it since 4.0), it needed to keep clients' password lists. http://www.pgpool.net/docs/latest/en/html/auth-methods.html#AUTH-SCRAM Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
On Mon, Apr 8, 2019 at 10:08:07AM -0400, Tom Lane wrote: > "Jonathan S. Katz" <jkatz@postgresql.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. 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. It would be nice to address channel binding as part of this. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On 4/8/19 6:10 PM, Jonathan S. Katz wrote: > On 4/8/19 4:20 PM, Alvaro Herrera wrote: >> On 2019-Apr-08, Jonathan S. Katz wrote: >> >>> On 4/8/19 4:10 PM, Alvaro Herrera wrote: >> >>>> I wonder why we have two pages >>>> https://wiki.postgresql.org/wiki/Client_Libraries >>>> https://wiki.postgresql.org/wiki/List_of_drivers >>> >>> No clue, but it appears that first one is the newer of the two[1][2] >>> >>> I'd be happy to consolidate them and provide a forwarding reference from >>> Client Libraries to List of Drivers, given I think we reference "List of >>> Drivers" in other places. >> >> There are two links to List of drivers, and one of them is in Client >> Libraries :-) >> https://wiki.postgresql.org/wiki/Special:WhatLinksHere/Client_Libraries >> >> +1 for consolidation and setting up a redirect. > > OK, so trying to not be too off topic, I did update the original page as so: > > https://wiki.postgresql.org/wiki/List_of_drivers > > That said, I am still in favor of the PG13 plan, and without objection I > would like to reach out to the driver authors in the "no" category, > reference this thread, and that this is at least discussed, if not > decided upon, and they should considering adding support for SCRAM to > allow adequate testing time as well as time for their drivers to make it > into appropriate packaging systems. OK so a small update, going through the list[1]: - The golang drivers all now support SCRAM - I've reached out to the remaining two driver projects on the list to make them aware of this thread and the timeline discussion, and to offer any help where needed in adding SCRAM support. Jonathan [1]https://wiki.postgresql.org/wiki/List_of_drivers