Re: [HACKERS] scram and \password

On Wed, May 3, 2017 at 5:26 PM, Heikki Linnakangas wrote: > Ok, gotcha. I disagree, I think we should provide a default. Libpq is in a > better position to make a good choice than most applications. > > I've committed the new PQencryptPasswordConn function, with the default >

Re: [HACKERS] scram and \password

On Wed, May 3, 2017 at 10:26 AM, Heikki Linnakangas wrote: > On 05/02/2017 07:47 PM, Robert Haas wrote: > >> On Tue, May 2, 2017 at 3:42 AM, Heikki Linnakangas >> wrote: >> >>> There's going to be a default, one way or another. The default is going >>> to >>>

Re: [HACKERS] scram and \password

On 05/02/2017 07:47 PM, Robert Haas wrote: On Tue, May 2, 2017 at 3:42 AM, Heikki Linnakangas wrote: There's going to be a default, one way or another. The default is going to come from password_encryption, or it's going to be a hard-coded value or logic based on

Re: [HACKERS] scram and \password

On Tue, May 2, 2017 at 3:42 AM, Heikki Linnakangas wrote: > There's going to be a default, one way or another. The default is going to > come from password_encryption, or it's going to be a hard-coded value or > logic based on server-version in PQencryptPasswordConn(). Or it's

Re: [HACKERS] scram and \password

On 05/01/2017 07:04 PM, Robert Haas wrote: On Thu, Apr 27, 2017 at 3:22 AM, Heikki Linnakangas wrote: You could argue, that since we need to document how to avoid the query and the blocking, we might as well always require the application to run the "show password_encryption"

Re: [HACKERS] scram and \password

On Thu, Apr 27, 2017 at 3:22 AM, Heikki Linnakangas wrote: > You could argue, that since we need to document how to avoid the query and > the blocking, we might as well always require the application to run the > "show password_encryption" query before calling

Re: [HACKERS] scram and \password

On 04/28/2017 07:49 AM, Noah Misch wrote: On Fri, Apr 21, 2017 at 11:04:14PM +0300, Heikki Linnakangas wrote: I'll continue reviewing the rest of the patch on Monday, but [...] This PostgreSQL 10 open item is past due for your status update. Kindly send a status update within 24 hours, and

Re: [HACKERS] scram and \password

On Fri, Apr 21, 2017 at 11:04:14PM +0300, Heikki Linnakangas wrote: > I'll continue reviewing the rest of the patch on Monday, but [...] 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

Re: [HACKERS] scram and \password

On 04/26/2017 07:57 PM, Tom Lane wrote: Robert Haas writes: On Wed, Apr 26, 2017 at 6:22 AM, Heikki Linnakangas wrote: * If algorithm is not given explicitly, PQencryptPasswordConn() queries "SHOW password_encryption", and uses that. That is

Re: [HACKERS] scram and \password

On Thu, Apr 27, 2017 at 9:57 AM, Michael Paquier wrote: > On Thu, Apr 27, 2017 at 1:25 PM, Ashesh Vashi > wrote: > > - Do we need to provide the method here? > > We have connection object itself, it can decide from the type of >

Re: [HACKERS] scram and \password

On Thu, Apr 27, 2017 at 1:25 PM, Ashesh Vashi wrote: > - Do we need to provide the method here? > We have connection object itself, it can decide from the type of connection, > which method to be used. Providing the method is not mandatory. If you look upthread...

Re: [HACKERS] scram and \password

On Tue, Apr 25, 2017 at 8:56 PM, Heikki Linnakangas wrote: > On 04/22/2017 01:20 AM, Michael Paquier wrote: > >> On Sat, Apr 22, 2017 at 5:04 AM, Heikki Linnakangas >> wrote: >> >>> I'll continue reviewing the rest of the patch on Monday, but one glaring >>>

Re: [HACKERS] scram and \password

On Wed, Apr 26, 2017 at 7:22 PM, Heikki Linnakangas wrote: > We talked about the alternative where PQencryptPasswordConn() would not look > at password_encryption, but would always use the strongest possible > algorithm supported by the server. That would avoid querying the

Re: [HACKERS] scram and \password

On Wed, Apr 26, 2017 at 12:57 PM, Tom Lane wrote: > Would it be worth making password_encryption be GUC_REPORT so that > it could be guaranteed available, without a server transaction, > from any valid connection? I'm generally resistant to adding > GUC_REPORT flags, but

Re: [HACKERS] scram and \password

Robert Haas writes: > On Wed, Apr 26, 2017 at 6:22 AM, Heikki Linnakangas wrote: >> * If algorithm is not given explicitly, PQencryptPasswordConn() queries >> "SHOW password_encryption", and uses that. That is documented, and it is >> also documented that

Re: [HACKERS] scram and \password

On Wed, Apr 26, 2017 at 6:22 AM, Heikki Linnakangas wrote: > On 04/25/2017 06:26 PM, Heikki Linnakangas wrote: >> Thoughts? Unless someone has better ideas or objections, I'll go >> implement that. > This is what I came up with in the end. Some highlights and differences vs > the

Re: [HACKERS] scram and \password

On 04/25/2017 06:26 PM, Heikki Linnakangas wrote: Thoughts? Unless someone has better ideas or objections, I'll go implement that. This is what I came up with in the end. Some highlights and differences vs the plan I posted earlier: * If algorithm is not given explicitly,

Re: [HACKERS] scram and \password

On Wed, Apr 26, 2017 at 12:26 AM, Heikki Linnakangas wrote: > Yeah, there is that. But we simply cannot change the signature of an > existing function. It would not only produce compile-time errors when > building old applications, which would arguably be a good thing, but it >

Re: [HACKERS] scram and \password

On Tue, Apr 25, 2017 at 8:29 PM, Tom Lane wrote: > Robert Haas writes: > > On Tue, Apr 25, 2017 at 11:26 AM, Heikki Linnakangas > wrote: > >> A) Have PQencryptPassword() return an md5 hash. > >> > >> B) Have PQencryptPassword() return

Re: [HACKERS] scram and \password

Robert Haas writes: > On Tue, Apr 25, 2017 at 11:26 AM, Heikki Linnakangas wrote: >> A) Have PQencryptPassword() return an md5 hash. >> >> B) Have PQencryptPassword() return a SCRAM verifier >> >> C) Have PQencryptPassword() return a SCRAM verifier if

Re: [HACKERS] scram and \password

On Tue, Apr 25, 2017 at 11:26 AM, Heikki Linnakangas wrote: > algorithm as argument. But there are open decisions on what the old > PQencryptPassword() function should do, and also what the new function > should do by default, if you don't specify an algorithm: > > A) Have

Re: [HACKERS] scram and \password

On 04/22/2017 01:20 AM, Michael Paquier wrote: On Sat, Apr 22, 2017 at 5:04 AM, Heikki Linnakangas wrote: I'll continue reviewing the rest of the patch on Monday, but one glaring issue is that we cannot add an argument to the existing libpq PQencryptPassword() function,

Re: [HACKERS] scram and \password

On Sat, Apr 22, 2017 at 7:20 AM, Michael Paquier wrote: > Do we really want to add a new function or have a hard failure? Any > application calling PQencryptPassword may trap itself silently if the > server uses scram as hba key or if the default is switched to that, >

Re: [HACKERS] scram and \password

On Sat, Apr 22, 2017 at 5:04 AM, Heikki Linnakangas wrote: > I'll continue reviewing the rest of the patch on Monday, but one glaring > issue is that we cannot add an argument to the existing libpq > PQencryptPassword() function, because that's part of the public API. It > would

Re: [HACKERS] scram and \password

On 04/10/2017 08:42 AM, Michael Paquier wrote: As there have been some conflicts because of the commit of SASLprep, here is a rebased set of patches. I've committed a modified version of the first patch, to change the on-disk format to RFC 5803, as mentioned on the other thread

Re: [HACKERS] scram and \password

On 18 April 2017 at 09:25, Heikki Linnakangas wrote: > On 04/18/2017 11:15 AM, Simon Riggs wrote: >> >> As a potential open item, if we treat "md5" as ">= md5" >> should we not also treat "password" as ">=password"? >> >> It seems strange that we still support "password" and yet

Re: [HACKERS] scram and \password

On 04/18/2017 08:44 AM, Noah Misch wrote: On Tue, Apr 11, 2017 at 10:07:12PM +0300, Heikki Linnakangas wrote: Thanks! I've been busy on the other thread on future-proofing the protocol with negotiating the SASL mechanism, I'll come back to this once we get that settled. By the end of the week,

Re: [HACKERS] scram and \password

On 04/18/2017 11:15 AM, Simon Riggs wrote: As a potential open item, if we treat "md5" as ">= md5" should we not also treat "password" as ">=password"? It seems strange that we still support "password" and yet tell everyonenot to use it. I'd like PG10 to be the version where I don't have to

Re: [HACKERS] scram and \password

On 14 March 2017 at 15:40, Tom Lane wrote: >> I was also thinking about that. Basically a primary method and a >> fallback. If that were the case, a gradual transition could happen, and >> if we want \password to enforce best practice it would be ok. > > Why exactly would

Re: [HACKERS] scram and \password

On Tue, Apr 11, 2017 at 10:07:12PM +0300, Heikki Linnakangas wrote: > On 04/10/2017 08:42 AM, Michael Paquier wrote: > >As there have been some conflicts because of the commit of SASLprep, > >here is a rebased set of patches. A couple of things worth noting: > >- SASLprep does an allocation of the

Re: [HACKERS] scram and \password

On 04/10/2017 08:42 AM, Michael Paquier wrote: As there have been some conflicts because of the commit of SASLprep, here is a rebased set of patches. A couple of things worth noting: - SASLprep does an allocation of the prepared password string. It is definitely better to do all the ground work

Re: [HACKERS] scram and \password

On Mon, Apr 10, 2017 at 12:53 PM, Noah Misch wrote: > On Wed, Apr 05, 2017 at 08:11:25PM +0300, Heikki Linnakangas wrote: >> >Heikki, are you going to do something about these? We're running out of >> >time. >> >> Sorry I've been procrastinating. I'm on it now. (We need to do

Re: [HACKERS] scram and \password

On Wed, Apr 05, 2017 at 08:11:25PM +0300, Heikki Linnakangas wrote: > On 04/05/2017 06:53 PM, Robert Haas wrote: > >On Sat, Mar 25, 2017 at 1:10 AM, Michael Paquier > > wrote: > >>On Fri, Mar 24, 2017 at 10:12 PM, Heikki Linnakangas > >>wrote: > >>>On

Re: [HACKERS] scram and \password

On Thu, Apr 6, 2017 at 8:04 AM, Michael Paquier wrote: > On Thu, Apr 6, 2017 at 2:11 AM, Heikki Linnakangas wrote: >> At a quick glance, moving pg_frontend_random() to src/common looks like a >> non-starter. It uses pglock_thread() which is internal to

Re: [HACKERS] scram and \password

On Thu, Apr 6, 2017 at 2:11 AM, Heikki Linnakangas wrote: > At a quick glance, moving pg_frontend_random() to src/common looks like a > non-starter. It uses pglock_thread() which is internal to libpq, so it won't > compile as it is. I think I'm going to change

Re: [HACKERS] scram and \password

On 04/05/2017 06:53 PM, Robert Haas wrote: On Sat, Mar 25, 2017 at 1:10 AM, Michael Paquier wrote: On Fri, Mar 24, 2017 at 10:12 PM, Heikki Linnakangas wrote: On 03/24/2017 03:02 PM, Michael Paquier wrote: In order to close this thread, I propose

Re: [HACKERS] scram and \password

On Sat, Mar 25, 2017 at 1:10 AM, Michael Paquier wrote: > On Fri, Mar 24, 2017 at 10:12 PM, Heikki Linnakangas wrote: >> On 03/24/2017 03:02 PM, Michael Paquier wrote: >>> >>> In order to close this thread, I propose to reuse the patches I sent >>>

Re: [HACKERS] scram and \password

On Fri, Mar 24, 2017 at 10:12 PM, Heikki Linnakangas wrote: > On 03/24/2017 03:02 PM, Michael Paquier wrote: >> >> In order to close this thread, I propose to reuse the patches I sent >> here to make scram_build_verifier() available to frontends: >> >>

Re: [HACKERS] scram and \password

On 03/24/2017 03:02 PM, Michael Paquier wrote: In order to close this thread, I propose to reuse the patches I sent here to make scram_build_verifier() available to frontends: https://www.postgresql.org/message-id/CAB7nPqT4yc3u8wspYkWbG088Ndp6asMH3=zb___ck89ctvz...@mail.gmail.com And on top of

Re: [HACKERS] scram and \password

On Fri, Mar 24, 2017 at 8:36 PM, Heikki Linnakangas wrote: > On 03/23/2017 06:41 AM, Michael Paquier wrote: >> >> And after a lookup the failure is here: >> - result = get_role_password(port->user_name, _pass, logdetail); >> + shadow_pass = get_role_password(port->user_name,

Re: [HACKERS] scram and \password

On 03/23/2017 06:41 AM, Michael Paquier wrote: And after a lookup the failure is here: - result = get_role_password(port->user_name, _pass, logdetail); + shadow_pass = get_role_password(port->user_name, logdetail); if (result == STATUS_OK) result is never setup in this code path, so that

Re: [HACKERS] scram and \password

On Wed, Mar 22, 2017 at 8:54 PM, Heikki Linnakangas wrote: > On 03/17/2017 05:38 AM, Michael Paquier wrote: >> >> Regression tests are proving to be useful here (it would be nice to >> get those committed first!). I am noticing that this patch breaks >> connection for users with

Re: [HACKERS] scram and \password

On 03/17/2017 05:38 AM, Michael Paquier wrote: Regression tests are proving to be useful here (it would be nice to get those committed first!). I am noticing that this patch breaks connection for users with cleartext or md5-hashed verifier when "password" is used in pg_hba.conf. Are you sure?

Re: [HACKERS] scram and \password

Robert Haas writes: > On Fri, Mar 17, 2017 at 8:32 AM, Heikki Linnakangas wrote: >> It would make sense to have \password obey password_encryption GUC. Then >> \password and ALTER USER would do the same thing, which would be less >> surprising. Although

Re: [HACKERS] scram and \password

On Fri, Mar 17, 2017 at 8:32 AM, Heikki Linnakangas wrote: > It would make sense to have \password obey password_encryption GUC. Then > \password and ALTER USER would do the same thing, which would be less > surprising. Although it's also a bit weird for a GUC to affect

Re: [HACKERS] scram and \password

On 03/17/2017 02:01 PM, Robert Haas wrote: On Thu, Mar 16, 2017 at 11:38 PM, Michael Paquier wrote: At least this has the merit of making \password simpler from psql without a kind of --method option: if the backend is 9.6 or older, just generate a MD5-hash, and

Re: [HACKERS] scram and \password

On Thu, Mar 16, 2017 at 11:38 PM, Michael Paquier wrote: > On Thu, Mar 16, 2017 at 10:52 PM, Heikki Linnakangas wrote: >> On 03/14/2017 11:14 PM, Tom Lane wrote: >>> >>> In short, I don't think that argument refutes my position that "md5" >>> in

Re: [HACKERS] scram and \password

On Thu, Mar 16, 2017 at 10:52 PM, Heikki Linnakangas wrote: > On 03/14/2017 11:14 PM, Tom Lane wrote: >> >> In short, I don't think that argument refutes my position that "md5" >> in pg_hba.conf should be understood as allowing SCRAM passwords too. > > > Yeah, let's do that.

Re: [HACKERS] scram and \password

On 03/16/2017 06:52 AM, Heikki Linnakangas wrote: > On 03/14/2017 11:14 PM, Tom Lane wrote: >> In short, I don't think that argument refutes my position that "md5" >> in pg_hba.conf should be understood as allowing SCRAM passwords too. > > Yeah, let's do that. Here's a patch. > > I had some

Re: [HACKERS] scram and \password

On 03/14/2017 11:14 PM, Tom Lane wrote: In short, I don't think that argument refutes my position that "md5" in pg_hba.conf should be understood as allowing SCRAM passwords too. Yeah, let's do that. Here's a patch. I had some terminology trouble with the docs. What do you call a user that

Re: [HACKERS] scram and \password

On Thu, Mar 16, 2017 at 6:46 AM, Joe Conway wrote: > On 03/15/2017 08:48 AM, Michael Paquier wrote: >> I have been hacking my way through this thing, and making >> scram_build_verifier is requiring a bit more refactoring than I >> thought first: >> - stored and server keys are

Re: [HACKERS] scram and \password

On 03/15/2017 08:48 AM, Michael Paquier wrote: > I have been hacking my way through this thing, and making > scram_build_verifier is requiring a bit more refactoring than I > thought first: > - stored and server keys are hex-encoded using a backend-only routine. > I think that those should be

Re: [HACKERS] scram and \password

On Wed, Mar 15, 2017 at 6:14 AM, Tom Lane wrote: > Jeff Janes writes: >> On Tue, Mar 14, 2017 at 8:40 AM, Tom Lane wrote: >>> Why exactly would anyone want "md5 only"? I should think that "scram >>> only" is a sensible pg_hba

Re: [HACKERS] scram and \password

On Tue, Mar 14, 2017 at 5:14 PM, Tom Lane wrote: >> Without md5-only, a user who uses \password to change their password from a >> newer client would lock themselves out of connecting again from older >> clients. As a conscious decision (either of the DBA or the user) that >>

Re: [HACKERS] scram and \password

Jeff Janes writes: > On Tue, Mar 14, 2017 at 8:40 AM, Tom Lane wrote: >> Why exactly would anyone want "md5 only"? I should think that "scram >> only" is a sensible pg_hba setting, if the DBA feels that md5 is too >> insecure, but I do not see the point

Re: [HACKERS] scram and \password

On Tue, Mar 14, 2017 at 8:40 AM, Tom Lane wrote: > Joe Conway writes: > > > I was also thinking about that. Basically a primary method and a > > fallback. If that were the case, a gradual transition could happen, and > > if we want \password to enforce

Re: [HACKERS] scram and \password

On Tue, Mar 14, 2017 at 3:15 AM, Heikki Linnakangas wrote: > On 03/14/2017 04:47 AM, Tom Lane wrote: > >> Robert Haas writes: >> >>> I'm not talking about changing the default, just having it be possible >>> to use \password with the new system as it was

Re: [HACKERS] scram and \password

On 03/14/2017 08:40 AM, Tom Lane wrote: > Joe Conway writes: >> On 03/14/2017 03:15 AM, Heikki Linnakangas wrote: >>> It would be a lot more sensible, if there was a way to specify in >>> pg_hba.conf, "scram-or-md5". We punted on that for PostgreSQL 10, but >>> perhaps we

Re: [HACKERS] scram and \password

Joe Conway writes: > On 03/14/2017 03:15 AM, Heikki Linnakangas wrote: >> If the server isn't set up to do SCRAM authentication, i.e. there are no >> "scram" entries in pg_hba.conf, and you set yourself a SCRAM verifier, >> you have just locked yourself out of the system. I

Re: [HACKERS] scram and \password

On 03/14/2017 03:15 AM, Heikki Linnakangas wrote: > On 03/14/2017 04:47 AM, Tom Lane wrote: >> Robert Haas writes: >>> I'm not talking about changing the default, just having it be possible >>> to use \password with the new system as it was with the old, whatever >>>

Re: [HACKERS] scram and \password

On 03/14/2017 04:47 AM, Tom Lane wrote: Robert Haas writes: I'm not talking about changing the default, just having it be possible to use \password with the new system as it was with the old, whatever exactly we think that means. Seems to me the intended behavior of

Re: [HACKERS] scram and \password

On Tue, Mar 14, 2017 at 12:34 PM, Tom Lane wrote: > Michael Paquier writes: > If some other practice becomes better in v12, then we teach it about that > one. It's not like psql hasn't got many other server-version-dependent > behaviors. Okay.

Re: [HACKERS] scram and \password

Michael Paquier writes: > On Tue, Mar 14, 2017 at 11:47 AM, Tom Lane wrote: >> Seems to me the intended behavior of \password is to use the best >> available practice. So my guess is that it ought to use SCRAM when >> talking to a >= 10.0 server.

Re: [HACKERS] scram and \password

On Tue, Mar 14, 2017 at 11:47 AM, Tom Lane wrote: > Robert Haas writes: >> I'm not talking about changing the default, just having it be possible >> to use \password with the new system as it was with the old, whatever >> exactly we think that means. I

Re: [HACKERS] scram and \password

Robert Haas writes: > I'm not talking about changing the default, just having it be possible > to use \password with the new system as it was with the old, whatever > exactly we think that means. Seems to me the intended behavior of \password is to use the best available

Re: [HACKERS] scram and \password

On Sun, Mar 12, 2017 at 11:14 PM, Michael Paquier wrote: > On Mon, Mar 13, 2017 at 9:15 AM, Robert Haas wrote: >> On Fri, Mar 10, 2017 at 5:43 PM, Michael Paquier >> wrote: >>> On Sat, Mar 11, 2017 at 2:53 AM, Jeff

Re: [HACKERS] scram and \password

On Tue, Mar 14, 2017 at 9:54 AM, Joe Conway wrote: > On 03/12/2017 08:10 PM, Michael Paquier wrote: >> OK, so what about doing the following then: >> 1) Create pg_role_password_type(oid), taking a role OID in input and >> returning the type. > > That version would make sense

Re: [HACKERS] scram and \password

On 03/12/2017 08:10 PM, Michael Paquier wrote: > OK, so what about doing the following then: > 1) Create pg_role_password_type(oid), taking a role OID in input and > returning the type. That version would make sense for administrative use. I still think we might want a version of this that takes

Re: [HACKERS] scram and \password

On Fri, Mar 10, 2017 at 2:43 PM, Michael Paquier wrote: > On Sat, Mar 11, 2017 at 2:53 AM, Jeff Janes wrote: > > Should the \password tool in psql inspect password_encryption and act on > it > > being 'scram'? > > Not sure if it is wise to change

Re: [HACKERS] scram and \password

On Mon, Mar 13, 2017 at 12:48 AM, Joe Conway wrote: > On 03/11/2017 11:07 PM, Michael Paquier wrote: >> Having a RLS on pg_authid to allow a user to look at its own password >> type is an idea. > > Given that that is not likely at this stage of the dev cycle, what about > a

Re: [HACKERS] scram and \password

On Mon, Mar 13, 2017 at 9:15 AM, Robert Haas wrote: > On Fri, Mar 10, 2017 at 5:43 PM, Michael Paquier > wrote: >> On Sat, Mar 11, 2017 at 2:53 AM, Jeff Janes wrote: >>> Should the \password tool in psql inspect

Re: [HACKERS] scram and \password

On Fri, Mar 10, 2017 at 5:43 PM, Michael Paquier wrote: > On Sat, Mar 11, 2017 at 2:53 AM, Jeff Janes 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

Re: [HACKERS] scram and \password

On 03/11/2017 11:07 PM, Michael Paquier wrote: > Having a RLS on pg_authid to allow a user to look at its own password > type is an idea. Given that that is not likely at this stage of the dev cycle, what about a special purpose SQL function that returns the password type for the current user? Or

Re: [HACKERS] scram and \password

On Sun, Mar 12, 2017 at 9:10 AM, Joe Conway wrote: > On 03/11/2017 03:15 PM, Michael Paquier wrote: >> Yeah but it can be called as well while the application is calling >> PQgetResult() and still looping until it gets a NULL result. Not sure >> if this is a use-case to worry

Re: [HACKERS] scram and \password

On 03/11/2017 03:15 PM, Michael Paquier wrote: > Yeah but it can be called as well while the application is calling > PQgetResult() and still looping until it gets a NULL result. Not sure > if this is a use-case to worry about, but sending a query to the > server in PQencryptPassword() could as

Re: [HACKERS] scram and \password

On Sun, Mar 12, 2017 at 8:04 AM, Joe Conway wrote: > On 03/11/2017 02:21 PM, Michael Paquier wrote: >> On Sun, Mar 12, 2017 at 5:35 AM, Joe Conway wrote: >>> So if the password is not already set, \password uses >>> password_encryption to determine which

Re: [HACKERS] scram and \password

On 03/11/2017 02:21 PM, Michael Paquier wrote: > On Sun, Mar 12, 2017 at 5:35 AM, Joe Conway wrote: >> So if the password is not already set, \password uses >> password_encryption to determine which format to use, and if the >> password is already set, then the current method

Re: [HACKERS] scram and \password

On Sun, Mar 12, 2017 at 5:35 AM, Joe Conway wrote: > On 03/10/2017 02:43 PM, Michael Paquier wrote: >> Instead of changing the default, I think that we should take this >> occasion to rename PQencryptPassword to something like >> PQhashPassword(), and extend it with a method

Re: [HACKERS] scram and \password

On 03/10/2017 02:43 PM, Michael Paquier wrote: > On Sat, Mar 11, 2017 at 2:53 AM, Jeff Janes 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

Re: [HACKERS] scram and \password

On Sat, Mar 11, 2017 at 2:53 AM, Jeff Janes 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 didn't see this issue discussed, but the ability to search

[HACKERS] scram and \password

Should the \password tool in psql inspect password_encryption and act on it being 'scram'? I didn't see this issue discussed, but the ability to search the archives for backslashes is rather limited. Cheers, Jeff