On Sun, Dec 20, 2020 at 05:59:09PM -0500, Stephen Frost wrote:
> However, after chatting with Bruce about it for a bit this weekend, I'm
> not sure that we need to tackle the second case today. I don't think
> there's any doubt that there will be users who will want PG to manage
> the keyring and to be able to work with just a passphrase, as Bruce has
> worked to make happen here and which we have a patch for. I'm hoping
> Bruce will post a new patch soon based on the work that he and I
> discussed today (mostly just clarifications around keys vs. passphrases
> and having the PG side accept a key which the command that's run will
> produce). With that, I'm feeling pretty comfortable that we can move
> forward and at least get this initial work committed.
OK, here it the updated patch. The major change, as Stephen pointed
out, is that the cluser_key_command (was cluster_passphrase_command) now
returns a hex-string representing the 32-byte KEK, rather than having
the server hash whatever the command used to return. This avoids
double-hashing in cases where you are _not_ using a passphrase, but are
computing a random 32-byte value in the script. This does mean the
script has to run sha256 for passphrases, but it seems like a win.
Updated script are attached too.
The URLs are still accurate:
https://github.com/postgres/postgres/compare/master...bmomjian:key.diff
https://github.com/bmomjian/postgres/compare/key...bmomjian:key-alter.diff
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee