Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> Yeah, it seems that if you want to know whether you are using SSL, then
> we already have that. I don't see the need for this new read-only setting.
I concur --- there might be use for more reporting about SSL status, but
that patch doesn't seem like quite the right thing.
I've pushed the main patch with some small adjustments; one notable one
that I made the EXEC_BACKEND reload path work like SIGHUP reload (press on
without SSL if fail) not server start (abort if fail). As it stood, if
you fat-fingered a change to your SSL files on Windows, the postmaster
would keep running but all backends would die instantly, whether or not
an SSL connection was being requested. That didn't seem helpful.
I also went ahead and downgraded the "hostssl record with SSL turned off"
case to a warning.
Before we leave this area, though, there is a loose end that requires
more thought. That is, what about passphrase-protected server keys?
Our documentation suggests that if you have one, the server will demand
the passphrase just once at server start and then all is good. I'm not
sure if that's at all practical in modern usage, but in any case it's
not going to be reasonable to put a passphrase in again at every SIGHUP.
On Windows things are even worse; you'd have to give the passphrase again
to every spawned backend. (But that was true already.)
I can think of at least three things we might do about this:
1. Leave the code as it stands, and change the documentation to state
that you cannot use a passphrase-protected server key, period.
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.
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.
I'm kinda leaning to the last choice; I don't want to leave things as they
are, but actually making password-protected keys work in a useful way
seems like a lot more effort than is justified.
regards, tom lane
