On Wed, Jun 10, 2020 at 10:51:22AM -0400, Jonathan S. Katz wrote:
> On 6/10/20 10:47 AM, Peter Eisentraut wrote:
>> committed
>
> Yay!!! Thank you!
Thanks, all.
--
Michael
signature.asc
Description: PGP signature
On 6/10/20 10:47 AM, Peter Eisentraut wrote:
> On 2020-05-28 15:28, Jonathan S. Katz wrote:
>> On 5/28/20 8:10 AM, Peter Eisentraut wrote:
>>> On 2020-05-27 15:25, Jonathan S. Katz wrote:
$ initdb -D data --auth-local=scram-sha-256 --auth-host=md5
Got an error message:
"ini
On 2020-05-28 15:28, Jonathan S. Katz wrote:
On 5/28/20 8:10 AM, Peter Eisentraut wrote:
On 2020-05-27 15:25, Jonathan S. Katz wrote:
$ initdb -D data --auth-local=scram-sha-256 --auth-host=md5
Got an error message:
"initdb: error: must specify a password for the superuser to enable md5
authe
Stephen Frost writes:
> * Jonathan S. Katz (jk...@postgresql.org) wrote:
>> By that logic, I would +1 removing ENCRYPTED & UNENCRYPTED, given
>> ENCRYPTED effectively has no meaning either after all this time too.
>> Perhaps a stepping stone is to emit a deprecation warning on PG14 and
>> remove i
On 5/29/20 9:22 AM, Stephen Frost wrote:
> Greetings,
>
> * Jonathan S. Katz (jk...@postgresql.org) wrote:
>> On 5/29/20 3:33 AM, Michael Paquier wrote:
>>> On Thu, May 28, 2020 at 02:53:17PM +0200, Peter Eisentraut wrote:
More along these lines: We could also remove the ENCRYPTED and UNENCRY
Greetings,
* Jonathan S. Katz (jk...@postgresql.org) wrote:
> On 5/29/20 3:33 AM, Michael Paquier wrote:
> > On Thu, May 28, 2020 at 02:53:17PM +0200, Peter Eisentraut wrote:
> >> More along these lines: We could also remove the ENCRYPTED and UNENCRYPTED
> >> keywords from CREATE and ALTER ROLE.
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Thu, May 28, 2020 at 02:53:17PM +0200, Peter Eisentraut wrote:
> > More along these lines: We could also remove the ENCRYPTED and UNENCRYPTED
> > keywords from CREATE and ALTER ROLE. AFAICT, these have never been emitted
> > by pg_dum
On 5/29/20 3:33 AM, Michael Paquier wrote:
> On Thu, May 28, 2020 at 02:53:17PM +0200, Peter Eisentraut wrote:
>> More along these lines: We could also remove the ENCRYPTED and UNENCRYPTED
>> keywords from CREATE and ALTER ROLE. AFAICT, these have never been emitted
>> by pg_dump or psql, so there
On Thu, May 28, 2020 at 02:53:17PM +0200, Peter Eisentraut wrote:
> More along these lines: We could also remove the ENCRYPTED and UNENCRYPTED
> keywords from CREATE and ALTER ROLE. AFAICT, these have never been emitted
> by pg_dump or psql, so there are no concerns from that end. Thoughts?
+0.5
On Thu, May 28, 2020 at 10:01 AM Stephen Frost wrote:
> as if we don't know what columns are
Amen to that!
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, May 28, 2020 at 8:53 AM Peter Eisentraut
> wrote:
> > More along these lines: We could also remove the ENCRYPTED and
> > UNENCRYPTED keywords from CREATE and ALTER ROLE. AFAICT, these have
> > never been emitted by pg_dump or psql
On Thu, May 28, 2020 at 8:53 AM Peter Eisentraut
wrote:
> More along these lines: We could also remove the ENCRYPTED and
> UNENCRYPTED keywords from CREATE and ALTER ROLE. AFAICT, these have
> never been emitted by pg_dump or psql, so there are no concerns from
> that end. Thoughts?
I have a qu
On 5/28/20 8:10 AM, Peter Eisentraut wrote:
> On 2020-05-27 15:25, Jonathan S. Katz wrote:
>> $ initdb -D data --auth-local=scram-sha-256 --auth-host=md5
>>
>> Got an error message:
>>
>> "initdb: error: must specify a password for the superuser to enable md5
>> authentication"
>>
>> For the last t
On 2020-05-27 15:59, Stephen Frost wrote:
Agreed- let's remove the legacy options. As I've mentioned elsewhere,
distros may manage the issue for us, and if we want to get into it, we
could consider adding support to pg_upgrade to complain if it comes
across a legacy setting that isn't valid. I'
On 2020-05-27 15:25, Jonathan S. Katz wrote:
$ initdb -D data --auth-local=scram-sha-256 --auth-host=md5
Got an error message:
"initdb: error: must specify a password for the superuser to enable md5
authentication"
For the last two, that behavior is to be expected (after all, you've set
the tw
Greetings,
* Jonathan S. Katz (jk...@postgresql.org) wrote:
> On 5/27/20 9:13 AM, Michael Paquier wrote:
> > On Wed, May 27, 2020 at 02:56:34PM +0200, Magnus Hagander wrote:
> >> Seems like the better choice yeah. Since we're changing the default anyway,
> >> maybe now is the time to do that? Or i
On 5/27/20 9:13 AM, Michael Paquier wrote:
> On Wed, May 27, 2020 at 02:56:34PM +0200, Magnus Hagander wrote:
>> Seems like the better choice yeah. Since we're changing the default anyway,
>> maybe now is the time to do that? Or if not, maybe have it log an explicit
>> deprecation warning when it l
On 5/26/20 4:25 AM, Peter Eisentraut wrote:
> On 2020-05-25 17:57, Jonathan S. Katz wrote:
>> I took a look over, it looks good. One question on the initdb.c diff:
>>
>> - if (strcmp(authmethodlocal, "scram-sha-256") == 0 ||
>> - strcmp(authmethodhost, "scram-sha-256") == 0)
>> - {
>>
On Wed, May 27, 2020 at 02:56:34PM +0200, Magnus Hagander wrote:
> Seems like the better choice yeah. Since we're changing the default anyway,
> maybe now is the time to do that? Or if not, maybe have it log an explicit
> deprecation warning when it loads a config with it?
Not sure that's worth it
On Wed, May 27, 2020 at 8:29 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2020-05-27 08:00, Michael Paquier wrote:
> > On Tue, May 26, 2020 at 10:25:25AM +0200, Peter Eisentraut wrote:
> >> Yeah, I was too enthusiastic about removing that. Here is a better
> patch.
> >
> >
On 2020-05-27 08:00, Michael Paquier wrote:
On Tue, May 26, 2020 at 10:25:25AM +0200, Peter Eisentraut wrote:
Yeah, I was too enthusiastic about removing that. Here is a better patch.
+as an MD5 hash. (on is also accepted, as an alias
+for md5.) The default is
+scram
On Tue, May 26, 2020 at 10:25:25AM +0200, Peter Eisentraut wrote:
> Yeah, I was too enthusiastic about removing that. Here is a better patch.
+as an MD5 hash. (on is also accepted, as an alias
+for md5.) The default is
+scram-sha-256.
Shouldn't password_encryption = on/t
On 2020-05-25 17:57, Jonathan S. Katz wrote:
I took a look over, it looks good. One question on the initdb.c diff:
- if (strcmp(authmethodlocal, "scram-sha-256") == 0 ||
- strcmp(authmethodhost, "scram-sha-256") == 0)
- {
- conflines = replace_token(confli
On 5/25/20 5:45 AM, Peter Eisentraut wrote:
> On 2020-05-22 23:23, Jonathan S. Katz wrote:
>>> Yeah. But there's still something to Jonathan's argument, because 9.6
>>> will go EOL in November 2021, which is pretty close to when v14 will
>>> reach public release (assuming we can hold to the typica
On 2020-05-22 23:23, Jonathan S. Katz wrote:
Yeah. But there's still something to Jonathan's argument, because 9.6
will go EOL in November 2021, which is pretty close to when v14 will
reach public release (assuming we can hold to the typical schedule).
If we do it in v13, there'll be a full year
On 5/22/20 5:21 PM, Tom Lane wrote:
> Vik Fearing writes:
>> On 5/22/20 9:09 PM, Jonathan S. Katz wrote:
>>> As someone who is an unabashed SCRAM fan and was hoping the default
>>> would be up'd for v13, I would actually +1 making it the default in v14,
>>> i.e. because 9.5 will be EOL at that poi
Vik Fearing writes:
> On 5/22/20 9:09 PM, Jonathan S. Katz wrote:
>> As someone who is an unabashed SCRAM fan and was hoping the default
>> would be up'd for v13, I would actually +1 making it the default in v14,
>> i.e. because 9.5 will be EOL at that point, and as such we both have
>> every* dri
On 5/22/20 9:09 PM, Jonathan S. Katz wrote:
> As someone who is an unabashed SCRAM fan and was hoping the default
> would be up'd for v13, I would actually +1 making it the default in v14,
> i.e. because 9.5 will be EOL at that point, and as such we both have
> every* driver supporting SCRAM AND ev
On 5/22/20 11:34 AM, Tom Lane wrote:
> Stephen Frost writes:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>>> As far as that last goes, we *did* get the buildfarm fixed to be all
>>> v11 scripts, so I thought we were ready to move forward on trying
>>> 09f08930f again. It's too late to consider that
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> I'm +1 for changing both of these things as soon as we branch for v14,
> >> but I feel like it's a bit late for v13. If we aren't feature-frozen
> >> now, when will we be?
>
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I'm +1 for changing both of these things as soon as we branch for v14,
>> but I feel like it's a bit late for v13. If we aren't feature-frozen
>> now, when will we be?
> I really don't consider changing of defaults to be on the sa
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> As far as that last goes, we *did* get the buildfarm fixed to be all
> >> v11 scripts, so I thought we were ready to move forward on trying
> >> 09f08930f again. It's too lat
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> As far as that last goes, we *did* get the buildfarm fixed to be all
>> v11 scripts, so I thought we were ready to move forward on trying
>> 09f08930f again. It's too late to consider that for v13, but
>> perhaps it'd be reasonable
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Magnus Hagander (mag...@hagander.net) wrote:
> >> On Fri, May 22, 2020 at 4:13 PM Tom Lane wrote:
> >>> Peter Eisentraut writes:
> We didn't get anywhere with making the default authentication method in
>
Stephen Frost writes:
> * Magnus Hagander (mag...@hagander.net) wrote:
>> On Fri, May 22, 2020 at 4:13 PM Tom Lane wrote:
>>> Peter Eisentraut writes:
We didn't get anywhere with making the default authentication method in
a source build anything other than trust.
> I'm +1 on moving t
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Fri, May 22, 2020 at 4:13 PM Tom Lane wrote:
> > Peter Eisentraut writes:
> > > We didn't get anywhere with making the default authentication method in
> > > a source build anything other than trust. But perhaps we should change
> >
On Fri, May 22, 2020 at 4:13 PM Tom Lane wrote:
> Peter Eisentraut writes:
> > We didn't get anywhere with making the default authentication method in
> > a source build anything other than trust. But perhaps we should change
> > the default for password_encryption to nudge people to adopt SCRA
Peter Eisentraut writes:
> We didn't get anywhere with making the default authentication method in
> a source build anything other than trust. But perhaps we should change
> the default for password_encryption to nudge people to adopt SCRAM?
> Right now, passwords are still hashed using MD5 by
38 matches
Mail list logo
