Re: Some thoughts about SCRAM implementation

On Tue, Apr 11, 2017 at 9:20 AM, Álvaro Hernández Tortosa
<aht(at)8kdata(dot)com> wrote:
> LOL. Do you really want a half-baked Java programmer writing a patch in
> C for PostgreSQL? I once tried that and Magnus said my code was Java code
> that happened to compile with a C compiler.... ^_^
>
> Having said that, I take the bait, I like challenges and putting my
> words behind my code :)

Excellent, because that's how stuff gets done around here. Saying
that you want something and hoping other people will do it is fine,
but being will to put some effort into it is a lot more likely to get
it done. Not to be harsh, but showing up 3 days after feature freeze
to complain that a feature pending commit for 14 months is missing
something that you really need isn't really the right way to make
something happen. I'm pretty sure that the lack of channel binding
was discussed quite a bit earlier than now, so I think there was
adequate opportunity to protest, contribute a patch, etc. It's not
that I don't have sympathy for the way you feel about this: seeing
features you care about fall out of a release sucks, and I've
experienced a lot of that suckage quite recently, so the pain is fresh
in my mind. But it's something we all have to live with for the
overall good of the product. We used to not have a firm feature
freeze, and that was way worse.

In this case, I think it is abundantly clear that SCRAM without
channel binding is still a good feature. One piece of evidence for
that is that the standard uses the suffix -PLUS to denote the
availability of channel binding. That clearly conveys that channel
binding has value, but also that not having it does not make the whole
thing useless. Otherwise, they would have required it to be part of
every implementation, or they would have made you add -CRAPPY if you
didn't have it. The discussion elsewhere on this thread has
adequately underlined the value of what we've already got, so I won't
further belabor the point here.

Furthermore, I think that the state of this feature as it currently
exists in the tree is actually kind of concerning. There are
currently four open items pertaining to SCRAM at least two of which
look to my mind an awful lot like stuff that should have ideally been
handled pre-feature-freeze: \password support, and protocol
negotiation. I'm grateful for the hard work that has gone into this
feature, but these are pretty significant loose ends. \password
support is a basic usability issue. Protocol negotiation affects
anyone who may want to make their PG driver work with this feature,
and certainly can't be changed after final release, and ideally not
even after beta. We really, really need to get that stuff nailed down
ASAP or we're going to have big problems. So I think we should focus
on those things, not this.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company