Re: 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 +--
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, 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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.
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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:
/messages/by-id/95dea232-aeeb-d619-e917-abf32b44ef8a@8kdata.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
--
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, 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]/messages/by-id/20170404140717.GA2675809@tornado.leadboat.com 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]: /messages/by-id/20170404140717.GA2675809@tornado.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 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/w
iki/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).
We won't by syncing our version numbers with Postgres
Dave Cramer
davec@postgresintl.com
www.postgresintl.com
On 14/09/17 18:06, Dave Cramer wrote:
On 14 September 2017 at 02:21, Alvaro Hernandez <aht@ongres.com
<mailto:aht@ongres.com>> wrote: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 <mailto: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
<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).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:
/messages/by-id/20170404140717.GA2675809@tornado.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:
/messages/by-id/20170404140717.GA2675809@tornado.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
Attachments:
release-notes-notice-about-scram.patchtext/x-patch; name=release-notes-notice-about-scram.patchDownload+6-0
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 aboutSCRAM 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 thelist
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 areappropriate 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
