Re: ssl passphrase callback - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: ssl passphrase callback
Date
Msg-id CAA8=A7_33eM7qCsG-XBe+jkFx=PAM8-WG_GTWDsoHFXqbJdB=Q@mail.gmail.com
Whole thread Raw
In response to Re: ssl passphrase callback  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: ssl passphrase callback  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
On Sun, Dec 8, 2019 at 9:02 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> > Well that pretty much brings us back to the patch as submitted :-)
>
> Yeah, pretty nearly.  Taking a quick look over the v3 patch, my
> only quibble is that it doesn't provide any convenient way for the
> external module to make decisions about how to interact with
> ssl_passphrase_command --- in particular, if it would like to allow
> that to take precedence, it can't because there's no way for it to
> invoke the static function ssl_external_passwd_cb.
>
> But rather than expose that globally, maybe the theory ought to be
> "set up the state as we'd normally do, then let loadable modules
> choose to override it".  So I'm tempted to propose a hook function
> with the signature
>
> void openssl_tls_init_hook(SSL_CTX *context, bool isServerStart);
>
> and invoke that somewhere in be_tls_init --- maybe fairly late,
> so that it can override other settings if it wants, not only the
> SSL_CTX_set_default_passwd_cb setting.
>


Not sure if the placement is what you want, but maybe something like this?

cheers

andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Hamid Akhtar
Date:
Subject: Do we need to handle orphaned prepared transactions in the server?
Next
From: Thomas Kellerer
Date:
Subject: Re: Do we need to handle orphaned prepared transactions in theserver?