Re: Password identifiers, protocol aging and SCRAM protocol

On Sat, Mar 19, 2016 at 8:30 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)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