* Magnus Hagander (mag...@hagander.net) wrote: > On Tue, Jan 3, 2017 at 4:54 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > > Magnus Hagander <mag...@hagander.net> writes: > > > On Tue, Jan 3, 2017 at 4:02 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > >> Before we leave this area, though, there is a loose end that requires > > >> more thought. That is, what about passphrase-protected server keys? > > >> ... > > >> 2. Add a password callback function that would supply the passphrase > > >> when needed. The question is, where would it get that from? It'd > > >> be straightforward to supply it from a string GUC, but from a security > > >> POV it seems pretty silly to have the password in postgresql.conf. > > > > > Yeah, that seems like a really bad idea. If you want to do that, then you > > > might as well just remove the passphrase from the key. > > > > Agreed. It's difficult to imagine a situation in which postgresql.conf > > could be considered more secure than server.key, and usually it'd be less > > so. > > > > >> 3. Add a password callback function that just returns an empty string, > > >> thereby ensuring a clean failure if the server tries to load a > > >> passphrase-protected key. We'd still need to change the documentation > > >> but at least the behavior would be reasonably clean. > > > > > Another option would be to use a callback to get the key value the first > > > time, and then cache it so we can re-use it. That means we can make it > > work > > > if the new key has the same password, but it also means we need to take > > > care of protecting that passphrase. But I'm not sure that's any worse > > than > > > the fact that we keep the private key around unlocked today? > > > > Yeah, I'm not terribly fussed about having the passphrase sitting in > > postmaster memory. But the above is work I don't care to do ATM. > > > > I think probably the right thing for now is to install a do-nothing > > callback, so that at least we don't have the issue of the postmaster > > freezing at SIGHUP. If someone feels like trying to revive support > > of passphrase-protected server keys, that would be a perfectly fine > > base to build on; they'd need a callback there anyway. > > Does it still support passphrase protected ones on startup, or did that get > thrown out with the bathwater? I think that's definitely a separate thing > and there are a nontrivial number of people who would be interested in a > setup where they can use a passphrase to protect it initially, just not > reload it.
+1 Thanks! Stephen
signature.asc
Description: Digital signature
