Re: ssl passphrase callback

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: ssl passphrase callback
Date: 2019-12-07 22:32:01
Message-ID: 18927.1575757921@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Shinoda, Noriyoshi (PN Japan A&PS Delivery) 2019-12-07 22:54:25 RE: psql small improvement patch
Previous Message Tom Lane 2019-12-07 21:40:25 Re: log bind parameter values on error