Re: Password identifiers, protocol aging and SCRAM protocol
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Stephen Frost <sfrost@snowman.net>, David Steele <david@pgmasters.net>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>,
Valery Popov <v.popov@postgrespro.ru>
Date: 2016-03-21T14:07:31Z
Lists: pgsql-hackers
On Sat, Mar 19, 2016 at 8:30 AM, Michael Paquier <michael.paquier@gmail.com> wrote: >> Doing that with the >> level of detail and care that it seems to me to require seems like an >> almost-impossible task. Most of the major features I've committed >> this CommitFest are patches where I've personally done multiple rounds >> of review on over the last several months, and in many cases, other >> people have been doing code reviews for months before that. I'm not >> denying that this patch has prompted a good deal of discussion and >> what I would call design review, but detailed code review? I just >> haven't seen much of that. > > There has been none, as well as no real discussion regarding what we > want to do. The current result, particularly for the management of > protocol aging, is based on things I wrote by myself which negate the > many negative opinions received up to now for the past patches (mainly > the feedback was "I don't like that", without real output or fresh > ideas during discussion to explain why that's the case). Well, I said before and I'll say again that I don't like the idea of multiple password verifiers. I think that's an accident waiting to happen, and I'm not prepared to put in the amount of time and energy that it would take to get that feature committed despite not wanting it myself, or for being responsible for it afterwards. I'd prefer we didn't do it at all, although I'm not going to dig in my heels. I might be willing to deal with SCRAM itself, but this whole area is not my strongest suit. So ideally some other committer would be willing to pick this up. But the problem isn't even just that somebody has to hit the final commit button - as we've both said, there's a woeful lack of any meaningful review on this thread, and this sort of change really needs quite a lot of review. This has implications for backward-compatibility, for connectors that don't use libpq, etc. Really, I'm not even sure we have consensus on the direction. I mean, Heikki's proposal to adopt SCRAM sounds good enough at a broad level, but I don't really know what the alternatives are, I'm mostly just taking his word for it, and like you say, there's been a fair amount of miscellaneous negativity floating around. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Support SCRAM-SHA-256 authentication (RFC 5802 and 7677).
- 818fd4a67d61 10.0 landed
-
Refactor SHA2 functions and move them to src/common/.
- 273c458a2b3a 10.0 landed
-
Replace isMD5() with a more future-proof way to check if pw is encrypted.
- dbd69118c05d 10.0 landed
-
Remove bogus notice that older clients might not work with MD5 passwords.
- 7e3ae5455948 9.2.20 landed
- 470af1f41c8b 9.3.16 landed
- ada2cdb61015 9.4.11 landed
- 65a7f190b253 9.5.6 landed
- 7546c135dc30 9.6.2 landed
- 31c54096a18f 10.0 landed
-
Refactor the code for verifying user's password.
- e7f051b8f9a6 10.0 landed
-
Replace PostmasterRandom() with a stronger source, second attempt.
- fe0a0b5993df 10.0 landed
-
Remove support for (insecure) crypt authentication.
- 53a5026b5cb3 8.4.0 cited