Thread: Re: [HACKERS] SCRAM in the PG 10 release notes
On Tue, Apr 25, 2017 at 10:16 PM, Bruce Momjian <bruce@momjian.us> wrote: > Well, we could add "MD5 users are encouraged to switch to > SCRAM-SHA-256". Now whether we want to list this as something on the > SCRAM-SHA-256 description, or mention it as an incompatibility, or > under Migration. I am not clear that MD5 is in such terrible shape that > this is warranted. I think it's warranted. The continuing use of MD5 has been a headache for some EnterpriseDB customers who have compliance requirements which they must meet. It's not that they themselves necessarily know or care whether MD5 is secure, although in some cases they do; it's that if they use it, they will be breaking laws or regulations to which their business or agency is subject. I imagine customers of other PostgreSQL companies have similar issues. But leaving that aside, the advantage of SCRAM isn't merely that it uses a better algorithm to hash the password. It has other advantages also, like not being vulnerable to replay attacks. If you're doing password authentication, you should really be using SCRAM, and encouraging people to move to SCRAM after upgrading is a good idea. That having been said, SCRAM is a wire protocol break. You will not be able to upgrade to SCRAM unless and until the drivers you use to connect to the database add support for it. The only such driver that's part of libpq; other drivers that have reimplemented the PostgreSQL wire protocol will have to be updated with SCRAM support before it will be possible to use SCRAM with those drivers. I think this should be mentioned in the release notes, too. I also think it would be great if somebody would put together a wiki page listing all the popular drivers and (1) whether they use libpq or reimplement the wire protocol, and (2) if the latter, the status of any efforts to implement SCRAM, and (3) if those efforts have been completed, the version from which they support SCRAM. Then, I think we should reach out to all of the maintainers of those driver authors who aren't moving to support SCRAM and encourage them to do so. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Mon, May 1, 2017 at 08:12:51AM -0400, Robert Haas wrote: > On Tue, Apr 25, 2017 at 10:16 PM, Bruce Momjian <bruce@momjian.us> wrote: > > Well, we could add "MD5 users are encouraged to switch to > > SCRAM-SHA-256". Now whether we want to list this as something on the > > SCRAM-SHA-256 description, or mention it as an incompatibility, or > > under Migration. I am not clear that MD5 is in such terrible shape that > > this is warranted. > > I think it's warranted. The continuing use of MD5 has been a headache > for some EnterpriseDB customers who have compliance requirements which > they must meet. It's not that they themselves necessarily know or > care whether MD5 is secure, although in some cases they do; it's that > if they use it, they will be breaking laws or regulations to which > their business or agency is subject. I imagine customers of other > PostgreSQL companies have similar issues. But leaving that aside, the > advantage of SCRAM isn't merely that it uses a better algorithm to > hash the password. It has other advantages also, like not being > vulnerable to replay attacks. If you're doing password > authentication, you should really be using SCRAM, and encouraging > people to move to SCRAM after upgrading is a good idea. > > That having been said, SCRAM is a wire protocol break. You will not > be able to upgrade to SCRAM unless and until the drivers you use to > connect to the database add support for it. The only such driver > that's part of libpq; other drivers that have reimplemented the > PostgreSQL wire protocol will have to be updated with SCRAM support > before it will be possible to use SCRAM with those drivers. I think > this should be mentioned in the release notes, too. I also think it > would be great if somebody would put together a wiki page listing all > the popular drivers and (1) whether they use libpq or reimplement the > wire protocol, and (2) if the latter, the status of any efforts to > implement SCRAM, and (3) if those efforts have been completed, the > version from which they support SCRAM. Then, I think we should reach > out to all of the maintainers of those driver authors who aren't > moving to support SCRAM and encourage them to do so. I have added this as an open item because we will have to wait to see where we are with driver support as the release gets closer. -- 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 Thu, May 11, 2017 at 11:50 AM, Bruce Momjian <bruce@momjian.us> wrote: > I have added this as an open item because we will have to wait to see > where we are with driver support as the release gets closer. As Postgres ODBC now has a hard dependency with libpq, no actions is taken from there. At least this makes one driver worth mentioning. -- Michael
On 05/11/2017 07:03 AM, Michael Paquier wrote: > On Thu, May 11, 2017 at 11:50 AM, Bruce Momjian <bruce@momjian.us> wrote: >> I have added this as an open item because we will have to wait to see >> where we are with driver support as the release gets closer. > > As Postgres ODBC now has a hard dependency with libpq, no actions is > taken from there. At least this makes one driver worth mentioning. FWIW, I wrote a patch for the Go driver at https://github.com/lib/pq, to implement SCRAM. It's awaiting review. I updated the List of Drivers in the Wiki. I added a few drivers that were missing, like the ODBC driver, and the pgtclng driver, as well as a Go and Rust driver that I'm aware of. I reformatted it, and added a column to indicate whether each driver uses libpq or not. https://wiki.postgresql.org/wiki/List_of_drivers There is a similar list in our docs: https://www.postgresql.org/docs/devel/static/external-interfaces.html Should we update the list in the docs, adding every driver we know of? Or curate the list somehow, adding only more popular drivers? Or perhaps add a link to the Wiki page from the docs? We can use this list in the Wiki to track which drivers implement SCRAM. - Heikki
Heikki Linnakangas <hlinnaka@iki.fi> writes: > I updated the List of Drivers in the Wiki. I added a few drivers that > were missing, like the ODBC driver, and the pgtclng driver, as well as a > Go and Rust driver that I'm aware of. I reformatted it, and added a > column to indicate whether each driver uses libpq or not. > https://wiki.postgresql.org/wiki/List_of_drivers > There is a similar list in our docs: > https://www.postgresql.org/docs/devel/static/external-interfaces.html > Should we update the list in the docs, adding every driver we know of? > Or curate the list somehow, adding only more popular drivers? Or perhaps > add a link to the Wiki page from the docs? Certainly, if that list is out of date, we need to do something about it. ISTM that the list probably doesn't change fast enough that tracking it in our SGML docs is a huge problem. I think it'd likely be good enough to just add the missing drivers to the list in the docs. (If you do, please back-patch that.) > We can use this list in the Wiki to track which drivers implement SCRAM. +1. That *is* something likely to change faster than we can update the SGML docs. regards, tom lane
On 11/05/17 09:20, Heikki Linnakangas wrote: > On 05/11/2017 07:03 AM, Michael Paquier wrote: >> On Thu, May 11, 2017 at 11:50 AM, Bruce Momjian <bruce@momjian.us> >> wrote: >>> I have added this as an open item because we will have to wait to see >>> where we are with driver support as the release gets closer. >> >> As Postgres ODBC now has a hard dependency with libpq, no actions is >> taken from there. At least this makes one driver worth mentioning. > > FWIW, I wrote a patch for the Go driver at https://github.com/lib/pq, > to implement SCRAM. It's awaiting review. > > I updated the List of Drivers in the Wiki. I added a few drivers that > were missing, like the ODBC driver, and the pgtclng driver, as well as > a Go and Rust driver that I'm aware of. I reformatted it, and added a > column to indicate whether each driver uses libpq or not. > > https://wiki.postgresql.org/wiki/List_of_drivers > > There is a similar list in our docs: > > https://www.postgresql.org/docs/devel/static/external-interfaces.html > > Should we update the list in the docs, adding every driver we know of? > Or curate the list somehow, adding only more popular drivers? Or > perhaps add a link to the Wiki page from the docs? > > We can use this list in the Wiki to track which drivers implement SCRAM. I have just submitted a PR to add SCRAM support for pgjdbc: https://github.com/pgjdbc/pgjdbc/pull/842 Thread on the pgjdbc-list: https://www.postgresql.org/message-id/95dea232-aeeb-d619-e917-abf32b44ef8a%408kdata.com Hopefully it will be merged soon, and the list of drivers could then be updated with this. Álvaro -- Álvaro Hernández Tortosa ----------- <8K>data
On Wed, May 10, 2017 at 10:50:51PM -0400, Bruce Momjian wrote: > On Mon, May 1, 2017 at 08:12:51AM -0400, Robert Haas wrote: > > On Tue, Apr 25, 2017 at 10:16 PM, Bruce Momjian <bruce@momjian.us> wrote: > > > Well, we could add "MD5 users are encouraged to switch to > > > SCRAM-SHA-256". Now whether we want to list this as something on the > > > SCRAM-SHA-256 description, or mention it as an incompatibility, or > > > under Migration. I am not clear that MD5 is in such terrible shape that > > > this is warranted. > > > > I think it's warranted. The continuing use of MD5 has been a headache > > for some EnterpriseDB customers who have compliance requirements which > > they must meet. It's not that they themselves necessarily know or > > care whether MD5 is secure, although in some cases they do; it's that > > if they use it, they will be breaking laws or regulations to which > > their business or agency is subject. I imagine customers of other > > PostgreSQL companies have similar issues. But leaving that aside, the > > advantage of SCRAM isn't merely that it uses a better algorithm to > > hash the password. It has other advantages also, like not being > > vulnerable to replay attacks. If you're doing password > > authentication, you should really be using SCRAM, and encouraging > > people to move to SCRAM after upgrading is a good idea. > > > > That having been said, SCRAM is a wire protocol break. You will not > > be able to upgrade to SCRAM unless and until the drivers you use to > > connect to the database add support for it. The only such driver > > that's part of libpq; other drivers that have reimplemented the > > PostgreSQL wire protocol will have to be updated with SCRAM support > > before it will be possible to use SCRAM with those drivers. I think > > this should be mentioned in the release notes, too. I also think it > > would be great if somebody would put together a wiki page listing all > > the popular drivers and (1) whether they use libpq or reimplement the > > wire protocol, and (2) if the latter, the status of any efforts to > > implement SCRAM, and (3) if those efforts have been completed, the > > version from which they support SCRAM. Then, I think we should reach > > out to all of the maintainers of those driver authors who aren't > > moving to support SCRAM and encourage them to do so. > > I have added this as an open item because we will have to wait to see > where we are with driver support as the release gets closer. With the release near, I'm promoting this to the regular open issues section. [Action required within three days. This is a generic notification.] The above-described topic is currently a PostgreSQL 10 open item. Heikki, since you committed the patch believed to have created it, you own this open item. If some other commit is more relevant or if this does not belong as a v10 open item, please let us know. Otherwise, please observe the policy on open item ownership[1] and send a status update within three calendar days of this message. Include a date for your subsequent status update. Testers may discover new open items at any time, and I want to plan to get them all fixed well in advance of shipping v10. Consequently, I will appreciate your efforts toward speedy resolution. Thanks. [1] https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
On 09/12/2017 04:09 AM, Noah Misch wrote: > On Wed, May 10, 2017 at 10:50:51PM -0400, Bruce Momjian wrote: >> On Mon, May 1, 2017 at 08:12:51AM -0400, Robert Haas wrote: >>> On Tue, Apr 25, 2017 at 10:16 PM, Bruce Momjian <bruce@momjian.us> wrote: >>>> Well, we could add "MD5 users are encouraged to switch to >>>> SCRAM-SHA-256". Now whether we want to list this as something on the >>>> SCRAM-SHA-256 description, or mention it as an incompatibility, or >>>> under Migration. I am not clear that MD5 is in such terrible shape that >>>> this is warranted. >>> >>> I think it's warranted. The continuing use of MD5 has been a headache >>> for some EnterpriseDB customers who have compliance requirements which >>> they must meet. It's not that they themselves necessarily know or >>> care whether MD5 is secure, although in some cases they do; it's that >>> if they use it, they will be breaking laws or regulations to which >>> their business or agency is subject. I imagine customers of other >>> PostgreSQL companies have similar issues. But leaving that aside, the >>> advantage of SCRAM isn't merely that it uses a better algorithm to >>> hash the password. It has other advantages also, like not being >>> vulnerable to replay attacks. If you're doing password >>> authentication, you should really be using SCRAM, and encouraging >>> people to move to SCRAM after upgrading is a good idea. >>> >>> That having been said, SCRAM is a wire protocol break. You will not >>> be able to upgrade to SCRAM unless and until the drivers you use to >>> connect to the database add support for it. The only such driver >>> that's part of libpq; other drivers that have reimplemented the >>> PostgreSQL wire protocol will have to be updated with SCRAM support >>> before it will be possible to use SCRAM with those drivers. I think >>> this should be mentioned in the release notes, too. I also think it >>> would be great if somebody would put together a wiki page listing all >>> the popular drivers and (1) whether they use libpq or reimplement the >>> wire protocol, and (2) if the latter, the status of any efforts to >>> implement SCRAM, and (3) if those efforts have been completed, the >>> version from which they support SCRAM. Then, I think we should reach >>> out to all of the maintainers of those driver authors who aren't >>> moving to support SCRAM and encourage them to do so. >> >> I have added this as an open item because we will have to wait to see >> where we are with driver support as the release gets closer. > > With the release near, I'm promoting this to the regular open issues section. Thanks. I updated the list of drivers on the wiki (https://wiki.postgresql.org/wiki/List_of_drivers), adding a column for whether the driver supports SCRAM authentication. Currently, the only non-libpq driver that has implemented SCRAM is the JDBC driver. I submitted a patch for the Go driver, but it hasn't been committed yet. As for a recommendation in the release notes, maybe something like "Installations using MD5 authentication are encouraged to switch to SCRAM-SHA-256, unless using older client programs or drivers that don't support it yet." - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Sep 14, 2017 at 3:57 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote: > I updated the list of drivers on the wiki > (https://wiki.postgresql.org/wiki/List_of_drivers), adding a column for > whether the driver supports SCRAM authentication. Currently, the only > non-libpq driver that has implemented SCRAM is the JDBC driver. I submitted > a patch for the Go driver, but it hasn't been committed yet. Thanks Heikki for updating. Sorry for slacking on this item. Regarding hte Erlang driver, http://glozer.net/src/epgsql/ and http://tilleuropa.se/pgsql are dead links, and I have found one erland driver on github which is rather active: https://github.com/epgsql/epgsql This does not use libpq, and it does not support the sasl protocol. The third driver (https://code.google.com/archive/p/erlang-psql-driver/) exists but it is claimed as unmaintained. Wouldn't it be better to just remove all three from the list and replace them by the github one? For node-postgres, I would recommend updating the third column to tell "yes" if libpq is used, and "no" otherwise. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
On 14/09/17 08:57, Heikki Linnakangas wrote: > On 09/12/2017 04:09 AM, Noah Misch wrote: >> On Wed, May 10, 2017 at 10:50:51PM -0400, Bruce Momjian wrote: >>> On Mon, May 1, 2017 at 08:12:51AM -0400, Robert Haas wrote: >>>> On Tue, Apr 25, 2017 at 10:16 PM, Bruce Momjian <bruce@momjian.us> >>>> wrote: >>>>> Well, we could add "MD5 users are encouraged to switch to >>>>> SCRAM-SHA-256". Now whether we want to list this as something on the >>>>> SCRAM-SHA-256 description, or mention it as an incompatibility, or >>>>> under Migration. I am not clear that MD5 is in such terrible >>>>> shape that >>>>> this is warranted. >>>> >>>> I think it's warranted. The continuing use of MD5 has been a headache >>>> for some EnterpriseDB customers who have compliance requirements which >>>> they must meet. It's not that they themselves necessarily know or >>>> care whether MD5 is secure, although in some cases they do; it's that >>>> if they use it, they will be breaking laws or regulations to which >>>> their business or agency is subject. I imagine customers of other >>>> PostgreSQL companies have similar issues. But leaving that aside, the >>>> advantage of SCRAM isn't merely that it uses a better algorithm to >>>> hash the password. It has other advantages also, like not being >>>> vulnerable to replay attacks. If you're doing password >>>> authentication, you should really be using SCRAM, and encouraging >>>> people to move to SCRAM after upgrading is a good idea. >>>> >>>> That having been said, SCRAM is a wire protocol break. You will not >>>> be able to upgrade to SCRAM unless and until the drivers you use to >>>> connect to the database add support for it. The only such driver >>>> that's part of libpq; other drivers that have reimplemented the >>>> PostgreSQL wire protocol will have to be updated with SCRAM support >>>> before it will be possible to use SCRAM with those drivers. I think >>>> this should be mentioned in the release notes, too. I also think it >>>> would be great if somebody would put together a wiki page listing all >>>> the popular drivers and (1) whether they use libpq or reimplement the >>>> wire protocol, and (2) if the latter, the status of any efforts to >>>> implement SCRAM, and (3) if those efforts have been completed, the >>>> version from which they support SCRAM. Then, I think we should reach >>>> out to all of the maintainers of those driver authors who aren't >>>> moving to support SCRAM and encourage them to do so. >>> >>> I have added this as an open item because we will have to wait to see >>> where we are with driver support as the release gets closer. >> >> With the release near, I'm promoting this to the regular open issues >> section. > > Thanks. > > I updated the list of drivers on the wiki > (https://wiki.postgresql.org/wiki/List_of_drivers), adding a column > for whether the driver supports SCRAM authentication. Currently, the > only non-libpq driver that has implemented SCRAM is the JDBC driver. I > submitted a patch for the Go driver, but it hasn't been committed yet. On the JDBC driver, strictly speaking, code has not been released yet. It is scheduled for v 42.2.0, and maybe the wiki should also mention from what version of the driver it is supported (I guess for all cases, unless their versioning would be synced with PostgreSQL's). Álvaro -- Alvaro Hernandez ----------- OnGres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
On 14 September 2017 at 02:21, Alvaro Hernandez <aht@ongres.com> wrote:
On the JDBC driver, strictly speaking, code has not been released yet. It is scheduled for v 42.2.0, and maybe the wiki should also mention from what version of the driver it is supported (I guess for all cases, unless their versioning would be synced with PostgreSQL's).
On 14/09/17 08:57, Heikki Linnakangas wrote:On 09/12/2017 04:09 AM, Noah Misch wrote:On Wed, May 10, 2017 at 10:50:51PM -0400, Bruce Momjian wrote:On Mon, May 1, 2017 at 08:12:51AM -0400, Robert Haas wrote:On Tue, Apr 25, 2017 at 10:16 PM, Bruce Momjian <bruce@momjian.us> wrote:Well, we could add "MD5 users are encouraged to switch to
SCRAM-SHA-256". Now whether we want to list this as something on the
SCRAM-SHA-256 description, or mention it as an incompatibility, or
under Migration. I am not clear that MD5 is in such terrible shape that
this is warranted.
I think it's warranted. The continuing use of MD5 has been a headache
for some EnterpriseDB customers who have compliance requirements which
they must meet. It's not that they themselves necessarily know or
care whether MD5 is secure, although in some cases they do; it's that
if they use it, they will be breaking laws or regulations to which
their business or agency is subject. I imagine customers of other
PostgreSQL companies have similar issues. But leaving that aside, the
advantage of SCRAM isn't merely that it uses a better algorithm to
hash the password. It has other advantages also, like not being
vulnerable to replay attacks. If you're doing password
authentication, you should really be using SCRAM, and encouraging
people to move to SCRAM after upgrading is a good idea.
That having been said, SCRAM is a wire protocol break. You will not
be able to upgrade to SCRAM unless and until the drivers you use to
connect to the database add support for it. The only such driver
that's part of libpq; other drivers that have reimplemented the
PostgreSQL wire protocol will have to be updated with SCRAM support
before it will be possible to use SCRAM with those drivers. I think
this should be mentioned in the release notes, too. I also think it
would be great if somebody would put together a wiki page listing all
the popular drivers and (1) whether they use libpq or reimplement the
wire protocol, and (2) if the latter, the status of any efforts to
implement SCRAM, and (3) if those efforts have been completed, the
version from which they support SCRAM. Then, I think we should reach
out to all of the maintainers of those driver authors who aren't
moving to support SCRAM and encourage them to do so.
I have added this as an open item because we will have to wait to see
where we are with driver support as the release gets closer.
With the release near, I'm promoting this to the regular open issues section.
Thanks.
I updated the list of drivers on the wiki (https://wiki.postgresql.org/wiki/List_of_drivers), adding a column for whether the driver supports SCRAM authentication. Currently, the only non-libpq driver that has implemented SCRAM is the JDBC driver. I submitted a patch for the Go driver, but it hasn't been committed yet.
We won't by syncing our version numbers with Postgres
On 14/09/17 18:06, Dave Cramer wrote:
On 14 September 2017 at 02:21, Alvaro Hernandez <aht@ongres.com> wrote:On the JDBC driver, strictly speaking, code has not been released yet. It is scheduled for v 42.2.0, and maybe the wiki should also mention from what version of the driver it is supported (I guess for all cases, unless their versioning would be synced with PostgreSQL's).
On 14/09/17 08:57, Heikki Linnakangas wrote:On 09/12/2017 04:09 AM, Noah Misch wrote:On Wed, May 10, 2017 at 10:50:51PM -0400, Bruce Momjian wrote:On Mon, May 1, 2017 at 08:12:51AM -0400, Robert Haas wrote:On Tue, Apr 25, 2017 at 10:16 PM, Bruce Momjian <bruce@momjian.us> wrote:Well, we could add "MD5 users are encouraged to switch to
SCRAM-SHA-256". Now whether we want to list this as something on the
SCRAM-SHA-256 description, or mention it as an incompatibility, or
under Migration. I am not clear that MD5 is in such terrible shape that
this is warranted.
I think it's warranted. The continuing use of MD5 has been a headache
for some EnterpriseDB customers who have compliance requirements which
they must meet. It's not that they themselves necessarily know or
care whether MD5 is secure, although in some cases they do; it's that
if they use it, they will be breaking laws or regulations to which
their business or agency is subject. I imagine customers of other
PostgreSQL companies have similar issues. But leaving that aside, the
advantage of SCRAM isn't merely that it uses a better algorithm to
hash the password. It has other advantages also, like not being
vulnerable to replay attacks. If you're doing password
authentication, you should really be using SCRAM, and encouraging
people to move to SCRAM after upgrading is a good idea.
That having been said, SCRAM is a wire protocol break. You will not
be able to upgrade to SCRAM unless and until the drivers you use to
connect to the database add support for it. The only such driver
that's part of libpq; other drivers that have reimplemented the
PostgreSQL wire protocol will have to be updated with SCRAM support
before it will be possible to use SCRAM with those drivers. I think
this should be mentioned in the release notes, too. I also think it
would be great if somebody would put together a wiki page listing all
the popular drivers and (1) whether they use libpq or reimplement the
wire protocol, and (2) if the latter, the status of any efforts to
implement SCRAM, and (3) if those efforts have been completed, the
version from which they support SCRAM. Then, I think we should reach
out to all of the maintainers of those driver authors who aren't
moving to support SCRAM and encourage them to do so.
I have added this as an open item because we will have to wait to see
where we are with driver support as the release gets closer.
With the release near, I'm promoting this to the regular open issues section.
Thanks.
I updated the list of drivers on the wiki (https://wiki.postgresql.org/wiki/List_of_drivers), adding a column for whether the driver supports SCRAM authentication. Currently, the only non-libpq driver that has implemented SCRAM is the JDBC driver. I submitted a patch for the Go driver, but it hasn't been committed yet. We won't by syncing our version numbers with Postgres
Of course, I wanted to mean with that for other drivers that are not JDBC (which I don't know whether they sync the versions or they don't). Thanks for the clarification!
Álvaro
-- Alvaro Hernandez ----------- OnGres
On Fri, Sep 15, 2017 at 12:10 AM, Alvaro Hernandez <aht@ongres.com> wrote: >> On the JDBC driver, strictly speaking, code has not been released yet. >> It is scheduled for v 42.2.0, and maybe the wiki should also mention from >> what version of the driver it is supported (I guess for all cases, unless >> their versioning would be synced with PostgreSQL's). Adding the information that JDBC is able to speak the SASL protocol with Postgres from version 42.2.0 looks like a good addition to me, so I added it on the wiki page. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Sep 14, 2017 at 09:57:36AM +0300, Heikki Linnakangas wrote: > On 09/12/2017 04:09 AM, Noah Misch wrote: > >On Wed, May 10, 2017 at 10:50:51PM -0400, Bruce Momjian wrote: > >>On Mon, May 1, 2017 at 08:12:51AM -0400, Robert Haas wrote: > >>>On Tue, Apr 25, 2017 at 10:16 PM, Bruce Momjian <bruce@momjian.us> wrote: > >>>>Well, we could add "MD5 users are encouraged to switch to > >>>>SCRAM-SHA-256". Now whether we want to list this as something on the > >>>>SCRAM-SHA-256 description, or mention it as an incompatibility, or > >>>>under Migration. I am not clear that MD5 is in such terrible shape that > >>>>this is warranted. > >>> > >>>I think it's warranted. The continuing use of MD5 has been a headache > >>>for some EnterpriseDB customers who have compliance requirements which > >>>they must meet. It's not that they themselves necessarily know or > >>>care whether MD5 is secure, although in some cases they do; it's that > >>>if they use it, they will be breaking laws or regulations to which > >>>their business or agency is subject. I imagine customers of other > >>>PostgreSQL companies have similar issues. But leaving that aside, the > >>>advantage of SCRAM isn't merely that it uses a better algorithm to > >>>hash the password. It has other advantages also, like not being > >>>vulnerable to replay attacks. If you're doing password > >>>authentication, you should really be using SCRAM, and encouraging > >>>people to move to SCRAM after upgrading is a good idea. > >>> > >>>That having been said, SCRAM is a wire protocol break. You will not > >>>be able to upgrade to SCRAM unless and until the drivers you use to > >>>connect to the database add support for it. The only such driver > >>>that's part of libpq; other drivers that have reimplemented the > >>>PostgreSQL wire protocol will have to be updated with SCRAM support > >>>before it will be possible to use SCRAM with those drivers. I think > >>>this should be mentioned in the release notes, too. I also think it > >>>would be great if somebody would put together a wiki page listing all > >>>the popular drivers and (1) whether they use libpq or reimplement the > >>>wire protocol, and (2) if the latter, the status of any efforts to > >>>implement SCRAM, and (3) if those efforts have been completed, the > >>>version from which they support SCRAM. Then, I think we should reach > >>>out to all of the maintainers of those driver authors who aren't > >>>moving to support SCRAM and encourage them to do so. > >> > >>I have added this as an open item because we will have to wait to see > >>where we are with driver support as the release gets closer. > > > >With the release near, I'm promoting this to the regular open issues section. > > Thanks. > > I updated the list of drivers on the wiki > (https://wiki.postgresql.org/wiki/List_of_drivers), adding a column for > whether the driver supports SCRAM authentication. Currently, the only > non-libpq driver that has implemented SCRAM is the JDBC driver. I submitted > a patch for the Go driver, but it hasn't been committed yet. > > As for a recommendation in the release notes, maybe something like > "Installations using MD5 authentication are encouraged to switch to > SCRAM-SHA-256, unless using older client programs or drivers that don't > support it yet." That sounds reasonable. This PostgreSQL 10 open item is past due for your status update. Kindly send a status update within 24 hours, and include a date for your subsequent status update. Refer to the policy on open item ownership: https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
On 09/18/2017 11:13 AM, Noah Misch wrote: > On Thu, Sep 14, 2017 at 09:57:36AM +0300, Heikki Linnakangas wrote: >> On 09/12/2017 04:09 AM, Noah Misch wrote: >>> On Wed, May 10, 2017 at 10:50:51PM -0400, Bruce Momjian wrote: >>>> On Mon, May 1, 2017 at 08:12:51AM -0400, Robert Haas wrote: >>>>> On Tue, Apr 25, 2017 at 10:16 PM, Bruce Momjian <bruce@momjian.us> wrote: >>>>>> Well, we could add "MD5 users are encouraged to switch to >>>>>> SCRAM-SHA-256". Now whether we want to list this as something on the >>>>>> SCRAM-SHA-256 description, or mention it as an incompatibility, or >>>>>> under Migration. I am not clear that MD5 is in such terrible shape that >>>>>> this is warranted. >>>>> >>>>> I think it's warranted. The continuing use of MD5 has been a headache >>>>> for some EnterpriseDB customers who have compliance requirements which >>>>> they must meet. It's not that they themselves necessarily know or >>>>> care whether MD5 is secure, although in some cases they do; it's that >>>>> if they use it, they will be breaking laws or regulations to which >>>>> their business or agency is subject. I imagine customers of other >>>>> PostgreSQL companies have similar issues. But leaving that aside, the >>>>> advantage of SCRAM isn't merely that it uses a better algorithm to >>>>> hash the password. It has other advantages also, like not being >>>>> vulnerable to replay attacks. If you're doing password >>>>> authentication, you should really be using SCRAM, and encouraging >>>>> people to move to SCRAM after upgrading is a good idea. >>>>> >>>>> That having been said, SCRAM is a wire protocol break. You will not >>>>> be able to upgrade to SCRAM unless and until the drivers you use to >>>>> connect to the database add support for it. The only such driver >>>>> that's part of libpq; other drivers that have reimplemented the >>>>> PostgreSQL wire protocol will have to be updated with SCRAM support >>>>> before it will be possible to use SCRAM with those drivers. I think >>>>> this should be mentioned in the release notes, too. I also think it >>>>> would be great if somebody would put together a wiki page listing all >>>>> the popular drivers and (1) whether they use libpq or reimplement the >>>>> wire protocol, and (2) if the latter, the status of any efforts to >>>>> implement SCRAM, and (3) if those efforts have been completed, the >>>>> version from which they support SCRAM. Then, I think we should reach >>>>> out to all of the maintainers of those driver authors who aren't >>>>> moving to support SCRAM and encourage them to do so. >>>> >>>> I have added this as an open item because we will have to wait to see >>>> where we are with driver support as the release gets closer. >>> >>> With the release near, I'm promoting this to the regular open issues section. >> >> Thanks. >> >> I updated the list of drivers on the wiki >> (https://wiki.postgresql.org/wiki/List_of_drivers), adding a column for >> whether the driver supports SCRAM authentication. Currently, the only >> non-libpq driver that has implemented SCRAM is the JDBC driver. I submitted >> a patch for the Go driver, but it hasn't been committed yet. >> >> As for a recommendation in the release notes, maybe something like >> "Installations using MD5 authentication are encouraged to switch to >> SCRAM-SHA-256, unless using older client programs or drivers that don't >> support it yet." > > That sounds reasonable. > > This PostgreSQL 10 open item is past due for your status update. Kindly send > a status update within 24 hours, and include a date for your subsequent status > update. Refer to the policy on open item ownership: > https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com I'm not sure what exactly to do here. Where should we stick that notice? We could put it in the release notes, where the bullet point about SCRAM is, but it would be well hidden. If we want to give advice to people who might not otherwise pay attention, it should go to a more prominent place. In the "Migration to version 10" section perhaps. Currently, it only lists incompatibilities, which this isn't. Perhaps put the notice after the list of incompatibilities (patch attached)? - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
Heikki Linnakangas <hlinnaka@iki.fi> writes:
> I'm not sure what exactly to do here. Where should we stick that notice?
> We could put it in the release notes, where the bullet point about SCRAM
> is, but it would be well hidden. If we want to give advice to people who
> might not otherwise pay attention, it should go to a more prominent
> place. In the "Migration to version 10" section perhaps. Currently, it
> only lists incompatibilities, which this isn't. Perhaps put the notice
> after the list of incompatibilities (patch attached)?
That seems pretty weird. I don't see a big reason not to just put it with
the bullet point about SCRAM. People who care will notice it there just
fine.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Sep 19, 2017 at 1:32 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
I'm not sure what exactly to do here. Where should we stick that notice? We could put it in the release notes, where the bullet point about SCRAM is, but it would be well hidden. If we want to give advice to people who might not otherwise pay attention, it should go to a more prominent place. In the "Migration to version 10" section perhaps. Currently, it only lists incompatibilities, which this isn't. Perhaps put the notice after the list of incompatibilities (patch attached)?
I guess I'm late to the party, but I don't see why this is needed at all. We encourage people to use any and all new features which are appropriate to them--that is why we implement new features. Why does this feature need a special invitation?
Cheers,
Jeff
On Wed, Sep 20, 2017 at 6:55 AM, Jeff Janes <jeff.janes@gmail.com> wrote: > On Tue, Sep 19, 2017 at 1:32 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote: >> I'm not sure what exactly to do here. Where should we stick that notice? >> We could put it in the release notes, where the bullet point about SCRAM is, >> but it would be well hidden. If we want to give advice to people who might >> not otherwise pay attention, it should go to a more prominent place. In the >> "Migration to version 10" section perhaps. Currently, it only lists >> incompatibilities, which this isn't. Perhaps put the notice after the list >> of incompatibilities (patch attached)? > > I guess I'm late to the party, but I don't see why this is needed at all. > We encourage people to use any and all new features which are appropriate to > them--that is why we implement new features. Why does this feature need a > special invitation? There have been continuous complains on those lists for the last 5 years or so that MD5 is "weak" and should be avoided. Well, Postgres is not wrong in the way it uses MD5 in itself, backups including raw MD5 hashes being more of a problem. But I would think that it is fair to tell in a louder to such folks that Postgres has actually done something on the matter. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Sep 19, 2017 at 4:29 PM, Michael Paquier <michael.paquier@gmail.com> wrote:
On Wed, Sep 20, 2017 at 6:55 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
> On Tue, Sep 19, 2017 at 1:32 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>> I'm not sure what exactly to do here. Where should we stick that notice?
>> We could put it in the release notes, where the bullet point about SCRAM is,
>> but it would be well hidden. If we want to give advice to people who might
>> not otherwise pay attention, it should go to a more prominent place. In the
>> "Migration to version 10" section perhaps. Currently, it only lists
>> incompatibilities, which this isn't. Perhaps put the notice after the list
>> of incompatibilities (patch attached)?
>
> I guess I'm late to the party, but I don't see why this is needed at all.
> We encourage people to use any and all new features which are appropriate to
> them--that is why we implement new features. Why does this feature need a
> special invitation?
There have been continuous complains on those lists for the last 5
years or so that MD5 is "weak" and should be avoided. Well, Postgres
is not wrong in the way it uses MD5 in itself, backups including raw
MD5 hashes being more of a problem. But I would think that it is fair
to tell in a louder to such folks that Postgres has actually done
something on the matter.
People who are stressed out about it but use PostgreSQL anyway will see it in the release notes and recognize the importance (to them) without being told. People who don't use PostgreSQL at all due to the issue aren't going to be reading the release notes anyway. The place to be louder about "this is now available" is in the announcement and press release, and in the (currently unwritten) "E.1.1. Overview", not down in the guts.
Meanwhile the people who don't know enough about it to understand why our use of md5 "is not wrong", will just see "encourage" and "better security" and then go lock their users and themselves out of their database and have a generally miserable experience.
I think the proposed invitation is too strong and warning is too weak. Especially as there seems to be no way to audit server-side what drivers/versions people are connecting with. You either have to track down every client and identify the correct binaries and run ldd against them (or whatever you would have to do on Windows), or just go ahead and break it and see who calls.
The people who need this don't need to be encouraged to use it, they just need to know it exists. The people who need to be encouraged are going to shoot themselves in the foot.
Cheers,
Jeff
On 9/19/17 17:55, Jeff Janes wrote: > I guess I'm late to the party, but I don't see why this is needed at > all. We encourage people to use any and all new features which are > appropriate to them--that is why we implement new features. Why does > this feature need a special invitation? It's not clear to me how an average user would get from the press release or release notes to upgrading their installation to use SCRAM-based authentication and passwords. A little bit more guidance somewhere would be helpful. The patch that Heikki posted seemed reasonable to me as a starting point, but there probably needs to be more "how" information somewhere. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Sep 20, 2017 at 9:45 AM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > On 9/19/17 17:55, Jeff Janes wrote: >> I guess I'm late to the party, but I don't see why this is needed at >> all. We encourage people to use any and all new features which are >> appropriate to them--that is why we implement new features. Why does >> this feature need a special invitation? > > It's not clear to me how an average user would get from the press > release or release notes to upgrading their installation to use > SCRAM-based authentication and passwords. A little bit more guidance > somewhere would be helpful. > > The patch that Heikki posted seemed reasonable to me as a starting > point, but there probably needs to be more "how" information somewhere. I agree with that. + <para> + Installations using MD5 authentication are encouraged to switch to + SCRAM-SHA-256, unless using older client programs or drivers that don't + support it yet. + </para> I think that the addition of a link to https://wiki.postgresql.org/wiki/List_of_drivers would be appropriate. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
On 9/19/17 21:44, Michael Paquier wrote: >> The patch that Heikki posted seemed reasonable to me as a starting >> point, but there probably needs to be more "how" information somewhere. > > I agree with that. > > + <para> > + Installations using MD5 authentication are encouraged to switch to > + SCRAM-SHA-256, unless using older client programs or drivers that don't > + support it yet. > + </para> > I think that the addition of a link to > https://wiki.postgresql.org/wiki/List_of_drivers would be appropriate. I don't have any expectation that that list will be kept up to date. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Sep 20, 2017 at 9:42 AM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > I don't have any expectation that that list will be kept up to date. Ditto. I suggest removing this as an open item. There's no defect in the code alleged, and whether there is a defect in the documentation is a matter of opinion on which not everyone agrees. The open items list is not a club to force committers to change things in a way that the person adding it likes better; it is a means for ensuring that clear defects get addressed in a timely manner so that we can have a timely release. In my opinion, it would be useful and appropriate to document migration instructions. However, I think the burden of doing that in an appropriate way is on whoever wants it done, not on Heikki, just like any other change that somebody wants made. Also in my opinion, it would be inappropriate to encourage people to migrate to SCRAM. Our job is to provide features, not to admonish users that they must use them. We could equally well add notes to the documentation saying: * Installations using out-of-core logical replication are encouraged to consider whether our built-in logical replication is now a better option. * Installations using table inheritance for partitioning should consider using the new table partitioning feature instead. * Installations using btree indexes on wide keys with equality comparisons only should consider whether hash indexes are now a better alternative. But let's not. Let's just do what we're already doing - tell people what we've got and let them decide whether to use it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Sep 20, 2017 at 6:42 AM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
On 9/19/17 21:44, Michael Paquier wrote:
>> The patch that Heikki posted seemed reasonable to me as a starting
>> point, but there probably needs to be more "how" information somewhere.
>
> I agree with that.
>
> + <para>
> + Installations using MD5 authentication are encouraged to switch to
> + SCRAM-SHA-256, unless using older client programs or drivers that don't
> + support it yet.
> + </para>
> I think that the addition of a link to
> https://wiki.postgresql.org/wiki/List_of_drivers would be appropriate.
I don't have any expectation that that list will be kept up to date.
I am not confident that it will be either, but what could we ever have more confidence in being kept up-to-date than something anyone can update which is hosted on a community asset? If we can't collectively keep it up-to-date, then shame on us and what hope is there for anything else? Certainly if it is not linked to from the docs, then it is just that much less likely to be kept up to date. The problem with it currently is that it implies anything using libpq supports scram, even though a libpq which supports scram has not even been released yet.
Cheers,
Jeff
On 9/19/17 20:45, Peter Eisentraut wrote: > On 9/19/17 17:55, Jeff Janes wrote: >> I guess I'm late to the party, but I don't see why this is needed at >> all. We encourage people to use any and all new features which are >> appropriate to them--that is why we implement new features. Why does >> this feature need a special invitation? > > It's not clear to me how an average user would get from the press > release or release notes to upgrading their installation to use > SCRAM-based authentication and passwords. A little bit more guidance > somewhere would be helpful. Here is a patch that expands the SCRAM documentation a bit, adds more explanation how the different options are related, and sets some better links. I think now you can get from the release notes to the relevant documentation and have enough information on how to put the new features into use. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
On 9/20/17 15:52, Jeff Janes wrote: > I think that the addition of a link to > > https://wiki.postgresql.org/wiki/List_of_drivers > <https://wiki.postgresql.org/wiki/List_of_drivers> would be appropriate. > > I don't have any expectation that that list will be kept up to date. > > I am not confident that it will be either, but what could we ever have > more confidence in being kept up-to-date than something anyone can > update which is hosted on a community asset? If we put such a list linked from the documentation, we have to keep it up to date for years, and no one is committing to do that. I don't think it's our job to maintain lists of which third-party products are ready to take advantage of new features in PostgreSQL. I don't see a list of GUIs ready to work with the new partitioning or monitoring tools ready to work with the new xlog/wal naming. If some folks want to maintain such lists, that's great, but it's not a release issue. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
On 09/21/2017 07:51 AM, Peter Eisentraut wrote: > On 9/20/17 15:52, Jeff Janes wrote: >> I think that the addition of a link to >> > https://wiki.postgresql.org/wiki/List_of_drivers >> <https://wiki.postgresql.org/wiki/List_of_drivers> would be appropriate. >> >> I don't have any expectation that that list will be kept up to date. >> >> I am not confident that it will be either, but what could we ever have >> more confidence in being kept up-to-date than something anyone can >> update which is hosted on a community asset? > If we put such a list linked from the documentation, we have to keep it > up to date for years, and no one is committing to do that. > > I don't think it's our job to maintain lists of which third-party > products are ready to take advantage of new features in PostgreSQL. I > don't see a list of GUIs ready to work with the new partitioning or > monitoring tools ready to work with the new xlog/wal naming. If some > folks want to maintain such lists, that's great, but it's not a release > issue. Peter is correct. JD -- Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc PostgreSQL Centered full stack support, consulting and development. Advocate: @amplifypostgres || Learn: https://pgconf.us ***** Unless otherwise stated, opinions are my own. ***** -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Sep 21, 2017 at 7:42 AM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
This looks good to me. Might suggest adding verifying the clients as a specific step:
On 9/19/17 20:45, Peter Eisentraut wrote:
> On 9/19/17 17:55, Jeff Janes wrote:
>> I guess I'm late to the party, but I don't see why this is needed at
>> all. We encourage people to use any and all new features which are
>> appropriate to them--that is why we implement new features. Why does
>> this feature need a special invitation?
>
> It's not clear to me how an average user would get from the press
> release or release notes to upgrading their installation to use
> SCRAM-based authentication and passwords. A little bit more guidance
> somewhere would be helpful.
Here is a patch that expands the SCRAM documentation a bit, adds more
explanation how the different options are related, and sets some better
links. I think now you can get from the release notes to the relevant
documentation and have enough information on how to put the new features
into use.
Cheers,
Jeff
On 9/21/17 14:15, Jeff Janes wrote: > This looks good to me. Might suggest adding verifying the clients as a > specific step: > > "To upgrade an existing installation from md5 to scram-sha-256, verify > that all client software supports it, set password_encryption = > 'scram-sha-256' in postgresql.conf..." I don't think there is a well-defined way of verifying whether all client software supports it other than making the switch described and then checking what breaks. So it's a bit of a circular process. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
On 9/21/17 14:15, Jeff Janes wrote: > Here is a patch that expands the SCRAM documentation a bit, adds more > explanation how the different options are related, and sets some better > links. I think now you can get from the release notes to the relevant > documentation and have enough information on how to put the new features > into use. > > > > This looks good to me. Might suggest adding verifying the clients as a > specific step: committed -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers