Horton

Re: ssl passphrase callback

Andrew Dunstan <andrew.dunstan@2ndquadrant.com>

View thread
From: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Bruce Momjian <bruce@momjian.us>, Magnus Hagander <magnus@hagander.net>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Simon Riggs <simon@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-12-07T21:03:27Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Provide a TLS init hook

On 12/7/19 12:16 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>> Bruce was worried about what would happen if we defined both
>> ssl_passphrase_command and ssl_passphrase_callback. The submitted patch
>> let's the callback have precedence, but it might be cleaner to error out
>> with such a config. OTOH, that wouldn't be so nice on a reload, so it
>> might be better just to document the behaviour.
> I think it would be up to the extension that's using the hook to
> decide what to do if ssl_passphrase_command is set.  It would not
> be our choice, and it would certainly not fall to us to document it.
>
>> He was also worried that multiple shared libraries might try to provide
>> the hook. I think that's fairly fanciful, TBH. It comes into the
>> category of "Don't do that."
> Again, it's somebody else's problem.  We have plenty of hooks that
> are of dubious use for multiple extensions, so why should this one be
> held to a higher standard?
>
> 			


Well that pretty much brings us back to the patch as submitted :-)


cheers


andrew

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