Re: Password identifiers, protocol aging and SCRAM protocol

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Valery Popov <v(dot)popov(at)postgrespro(dot)ru>
Subject: Re: Password identifiers, protocol aging and SCRAM protocol
Date: 2016-03-18 18:52:08
Message-ID: CA+TgmobPNhnnMjOwG6s7zFznzh7g3JsUkLFvQBnh4+Ua++_6qA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 18, 2016 at 2:12 PM, Stephen Frost <sfrost(at)snowman(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-03-18 18:55:54 Re: Performance degradation in commit ac1d794
Previous Message Alvaro Herrera 2016-03-18 18:49:51 Re: Performance degradation in commit ac1d794