On Tue, Aug 18, 2015 at 10:06 AM, Stephen Frost <sfrost@snowman.net> wrote:
> That was the imputus for my earlier suggestion that in a release or two,
> we actively make pg_upgrade error (or perhaps warn first, then error,
> across two releases) if any of the old verifiers exist.
I think there's basically no chance of that being acceptable. The
time at which it's possible to get rid of MD5 is going to vary widely
between installations. People who are using only libpq or
libpq-derived connectors will be able to get rid of it almost
immediately, if they want, though some won't. People who are using
obscure connectors that are poorly maintained may not even have a
version that supports SCRAM for 5 years. Think about how long it took
us to roll out the standard_conforming_strings changes, and there were
still people who got bitten.
> The other concern with a single password verifier is that we're locking
> ourselves into a one-verifier-per-role solution when most of the serious
> solutions in use today (Active Directory, Kerberos, certificate based
> systems) allow for more than one.
So what? If you want to delegate authentication to AD or Kerberos, we
already support that. That's not a reason to invent the same
functionality inside the server. If you've got a tangible plan, other
than SCRAM, that would require us to support multiple verifiers, then
please say what it is. If not, the mere fact that some other people
support it is not a reason why we should. In fact, we generally have
taken the approach that needs which are already handled adequately by
other tools to do not need to also be handled inside the database.
That's not a perfect approach and we always argue about it around the
edges, but generally, I think it's served us pretty well.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company