Peter Eisentraut <peter.eisentr...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers