On Wed, May 3, 2017 at 10:26 AM, Heikki Linnakangas <hlinn...@iki.fi> wrote:
> On 05/02/2017 07:47 PM, Robert Haas wrote: > >> On Tue, May 2, 2017 at 3:42 AM, Heikki Linnakangas <hlinn...@iki.fi> >> 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 going >>> to >>> be a hard-coded value or logic implemented in every application that uses >>> PQencryptPasswordConn(). I think looking at password_encryption makes the >>> most sense. The application is not in a good position to make the >>> decision, >>> and forcing the end-user to choose every time they change a password is >>> too >>> onerous. >>> >> >> I think there should be no default, and the caller should have to pass >> the algorithm explicitly. If they want to determine what default to >> pass by running 'SHOW password_encryption', that's their choice. >> > > 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 > behavior of doing "show password_encryption", and the changes to use it in > psql and createuser. This closes the open issue with \password. If we're basically just telling people to call SHOW manually, we might as well do it in the default case. I think the wording you put into the docs there is good, as it tells people exactly what happens and how to reproduce it locally. For the security perspective, perhaps we should have a link to the part of the docs that discusses the different algorithms? -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
