Re: Password identifiers, protocol aging and SCRAM protocol - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: Password identifiers, protocol aging and SCRAM protocol |
Date | |
Msg-id | CA+TgmobPNhnnMjOwG6s7zFznzh7g3JsUkLFvQBnh4+Ua++_6qA@mail.gmail.com Whole thread Raw |
In response to | Re: Password identifiers, protocol aging and SCRAM protocol (Stephen Frost <sfrost@snowman.net>) |
Responses |
Re: Password identifiers, protocol aging and SCRAM protocol
|
List | pgsql-hackers |
On Fri, Mar 18, 2016 at 2:12 PM, Stephen Frost <sfrost@snowman.net> wrote: > I'm not sure that I agree with the above. This patch has been through > the ringer multiple times regarding the user-facing bits and, by and > large, the results appear reasonable. Further, getting a better auth > method into PG is something which I do view as a priority considering > the concerns and complaints that have been, justifiably, raised against > our current password-based authentication support. > > This isn't a new patch set either, it was submitted initially over the > summer after it was pointed out, over a year ago, that people actually > do care about the problems with our current implementation (amusingly, I > recall having pointed out the same 5+ years ago, but only did so to this > list). I am not disputing the importance of the topic, and I do realize that the patch has been around in some form since March. However, I don't think there's been a whole heck of a lot in terms of detailed code-level review, and I think that's pretty important for something that necessarily involves wire protocol changes. 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. >> And I'd rather see all of the changes in one release than split them >> across two releases. > > I agree with this. If we aren't going to get SCRAM into 9.6 then the > rest is just breaking things with little benefit. I'm optomistic that > we will be able to include SCRAM support in 9.6, but if that ends up not > being feasible then we need to put all of the changes to the next > release. OK, glad we agree on that. > I do think that if we push this off to 9.7 then we're going to have > SCRAM *plus* a bunch of other changes around password policies in that > release, and it'd be better to introduce SCRAM independently of the > other changes. Well, for my part, I'd be happy enough to do all of that in a release cycle - maybe SCRAM at the beginning and those other changes a little later on. I don't see that as a real conflict, and in fact, sometimes when you do several things like that in a single cycle, people start to see whatever the common theme is - security, say - as part of the message of that release a little more than they would if a feature lands here and another there. That's not all a bad thing. > All that said, this is just my voice from having followed this thread > and discussing it with David and I'm not trying to force anything. It'd > certainly be nice to have and to be able to tell people that we do have > a strong and recognized approach to password-based authentication in PG, > but I've long been telling everyone that they should be using GSSAPI > and/or SSL and can continue to do so for another year if necessary. I agree it's unfortunate, but IMHO that's kinda where we are at. If Heikki were still involved and had been working on this, I strongly suspect it would have been committed already. But he's not, and it's not clear when or if he's coming back, and I cannot imagine how we are going to begin and complete pushing in a feature of this magnitude in the three weeks before feature freeze without a lot of collateral damage. That is an opinion, not a fact, but it's one I feel pretty confident about. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
pgsql-hackers by date: