From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: scram and \password |
Date: | 2017-03-13 17:05:39 |
Message-ID: | CAMkU=1xdbeGMJFLwoqtOuK8jrUNebpMjzbQJ-Way6qVp3UM4TQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Mar 10, 2017 at 2:43 PM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
wrote:
> On Sat, Mar 11, 2017 at 2:53 AM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> > Should the \password tool in psql inspect password_encryption and act on
> it
> > being 'scram'?
>
> Not sure if it is wise to change the default fot this release.
>
I'm not proposing that we change the default value of password_encryption,
only that \password respect whatever value it currently finds there. But
after thinking about it a bit more, I reached the same conclusion that Joe
did, that it should use the same hashing method as the current password
does, and only consult password_encryption if there is no password
currently set.
> A patch among those lines would be a simple, do people feel that this
> should be part of PG 10?
>
I think it is pretty important to have some way of setting the password
that doesn't risk it ending up in the server log file, or .psql_history, or
having someone shoulder-surf it.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Konstantin Knizhnik | 2017-03-13 17:10:48 | Re: WIP: Faster Expression Processing v4 |
Previous Message | Tom Lane | 2017-03-13 17:03:38 | Re: PATCH: Configurable file mode mask |