Re: ssl passphrase callback

On 2019-Nov-14, Bruce Momjian wrote:

> I was assuming if the variable starts with a #, it is a shared object,
> if not, it is a shell command:
>
> ssl_passphrase_command='#/lib/x.so'
> ssl_passphrase_command='my_command a b c'

Note that the proposed patch doesn't use a separate GUC -- it just uses
shared_preload_libraries, and then it is the library that's in charge of
setting up the function. We probably wouldn't like to have multiple
settings that all do the same thing, such as recovery target (which
seems to be a plentiful source of confusion).

Changing the interface so that the user has to specify the function name
(not the library name) in ssl_passphrase_command closes that ambiguity
hole.

Note that if you specify only the library name, it becomes redundant
w.r.t. shared_preload_libraries; you could have more than one library
setting the function callback and it's hard to see which one wins.

I think something like this would do it:
ssl_passphrase_command='#superlib.so,my_rot13_passphrase'

This way, the library can still create any custom GUCs it pleases/needs,
but there's no possible confusion as to the function that's going to be
called.

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