On Sun, Dec 20, 2020 at 05:59:09PM -0500, Stephen Frost wrote: > I do generally like the idea of having the single command able to be > used to either provide the KEK (where PG manages the keyring > internally), or called multiple times to retrieve the DEKs (in which > case PG wouldn't be managing the keyring). > > 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.
I agree with very little of this sub-discussion, but I am still reading it to see if I can get useful ideas from it. Looking at what we used to do with 'passphrase', we did the prompting in the script, and did the hash, HMAC validation, data key generation and its wrap in the server. With the 'cluster key' patch I just posted, the hashing of the passphrase is removed from the server and happens only in the script, because in many cases the hashing is not needed, and double-hashing is less secure, so that seems like a win. To go any further, you are starting to look at possible data key generation in the script, either at boot time, and then wrapped with a passphrase, or just retrieved on every boot. That would create a larger burden for any script, meaning a passphrase usage would have to not only hash, which it does now, but also verify its MAC, then decrypt keys stored in the file system, then echo those to its output, to be read by the server. I think this is the big point --- I have five scripts, and only one needs to hash its input (passphrase). If you go any farther in pushing code into the scripts, these scripts become much harder to write, and much harder to do error checks. I think the common case is passphrase, so I want to optimize for that. Pushing anymore features into the scripts is going to make that common case less reliable, which I am opposed to. Also, as far as Desirability, we only have _one_ person saying people will want more options. I need to hear from a lot more people before this gets added to Postgres. -- Bruce Momjian <br...@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
