Josh,
* Josh Berkus (josh@agliodbs.com) wrote:
> Actually, I think older client <-> newer server is the least critical. We'd
> be incrementing libpq for this. Right, Bruce?
I'm not 100% sure that libpq's API/ABI would need to change for this,
which is what would cause an SONAME change. This will probably require
a protocol change if we're going to continue to support the 'md5' option
in pg_hba.conf so that the protocol will allow for the server to send
the randomly generated salt to the client.
> While you're at it, maybe you should look at ways that pg_shadow could be
> double-encrypted on backup but still restored easily?
That's an interesting thought. That's actually what a Kerberos KDC does
(encrypts the database with all of the hashes to protect tem) since
the hashes are the keys in Kerberos (and as such the users actual
original password isn't necessary). Of course, to do it safely you'd
have to *not* store the 'master' pg_shadow password on the system, which
means you'd have to have someone manually start Postgres after the box
boots.
I do this for my KDCs but thankfully there's only very few of those,
doing it for Postgres would probably be much more annoying I'd think-
but then, if you're having Postgres store your passwords instead of
Kerberos (which is what I *normally* do, this particular case is a
special one for me where I can't use Kerberos) then perhaps it makes
sense, at least as an option.
Thanks, Stephen
