Re: Extended test coverage and docs for SSL passphrase commands - Mailing list pgsql-hackers
| From | Daniel Gustafsson |
|---|---|
| Subject | Re: Extended test coverage and docs for SSL passphrase commands |
| Date | |
| Msg-id | F3321059-A28F-452A-9EDD-A19F1F8EEFA9@yesql.se Whole thread Raw |
| In response to | Re: Extended test coverage and docs for SSL passphrase commands (Peter Eisentraut <peter@eisentraut.org>) |
| Responses |
Re: Extended test coverage and docs for SSL passphrase commands
|
| List | pgsql-hackers |
> On 12 Nov 2025, at 15:15, Peter Eisentraut <peter@eisentraut.org> wrote:
>
> On 07.11.25 21:26, Daniel Gustafsson wrote:
>> When I was writing tests for the SSL SNI patch [0] I realized that the current
>> tests for ssl passphrase commands aren't fully exercising the feature, so I
>> extended them to better understand how it works. Attached is an extended set
>> of tests for passphrase protected keys where connection and reloads are tested
>> as well as their different characteristics on Windows.
>> The patchset also contains a small doc addition which documents the fact that
>> passphrase command reloading must be on when running on Windows (EXEC_BACKEND)
>> since every backend will issue a SSL configuration reload.
>
> Your test code conflates $windows_os with EXEC_BACKEND. It should work to enable EXEC_BACKEND on a non-Windows
systemand have everything work. So I think that code needs to extract the actual EXEC_BACKEND setting somehow, instead
ofusing the OS identity as a proxy.
As far as I know the only way to programmatically learn that from the Perl
testcode would be to check for the presence of the CONFIG_EXEC_PARAMS file in
$self->data_dir, which should be easy enough to do. Do you know of a better
way?
> About the behavior that your documentation patch describes, I would like to have some kind of reflection of that in
thecode as well. At least a comment near default_openssl_tls_init() maybe? I haven't traced the code through, but I
wouldbe curious about what is different in an EXEC_BACKEND environment. For example, is the argument isServerStart
alsotrue if it's not a server start? Or should the setting actually be enforced directly on the GUC system?
It is documented in src/backend/tcop/backend_startup.c with the following
comment in BackendMain():
#ifdef EXEC_BACKEND
/*
* Need to reinitialize the SSL library in the backend, since the context
* structures contain function pointers and cannot be passed through the
* parameter file.
*
* If for some reason reload fails (maybe the user installed broken key
* files), soldier on without SSL; that's better than all connections
* becoming impossible.
*
* XXX should we do this in all child processes? For the moment it's
* enough to do it in backend children.
*/
#ifdef USE_SSL
if (EnableSSL)
{
if (secure_initialize(false) == 0)
LoadedSSL = true;
Calling secure_initialize with isServerStart == false will force a reload which
in turn requires the passphrase command to be reloadable if it is to work at
all.
Not sure if we need too much more than that, but maybe a note could be added to
be_tls_init that isServerStart will reflect config reloads as well as
EXEC_BACKEND?
--
Daniel Gustafsson
pgsql-hackers by date: