On 05/01/2017 07:04 PM, Robert Haas wrote:
On Thu, Apr 27, 2017 at 3:22 AM, Heikki Linnakangas <hlinn...@iki.fi> 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 PQencryptPasswordConn(). But
I'd like to offer the convenience for the majority of applications that
don't mind blocking.
I still think that's borrowing trouble. It just seems like too
critical of a thing to have a default -- if the convenience logic gets
it wrong and encrypts the password in a manner not intended by the
user, that could (a) amount to a security vulnerability or (b) lock
you out of your account.
That's true for a lot of things. The logic isn't complicated; it runs
"SHOW password_encryption", and uses the value of that as the algorithm.
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.
If you ask your significant other "where do
you want to go to dinner?" and can't get a clear answer out of them
after some period of time, it's probably OK to assume they don't care
that much and you can just pick something. If you ask the
commander-in-chief "which country should we fire the missiles at?" and
you don't get a clear and unambiguous answer, just picking something
is not a very good idea.
I don't understand the analogy. If the application explicitly passes an
algorithm, we use that. If the application passes NULL, it means "you
decide, based on the documented rules". If the application passes
"mumble-mumble", you get an error. If the "SHOW password_encryption"
query fails or libpq doesn't understand the result, you also get an error.
What do you think we should do here, then? Make password_encryption
GUC_REPORT? Hard-code an algorithm in every application? Remove the
convenience logic from PQencryptionPasswordConn(), and document that for
a sensible default, the application should first run "SHOW
password_encryption", and use the result of that as the algorithm? Or go
with the current patch?
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
