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:

Previous
From: Álvaro Herrera
Date:
Subject: Re: obsolete autovacuum comment
Next
From: Tomas Vondra
Date:
Subject: Re: index prefetching