Re: ssl passphrase callback

On Thu, Nov 14, 2019 at 02:07:58PM -0300, Alvaro Herrera wrote:
> 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.

Yeah, I was unclear how the function name would be specified. I thought
it would just be hard-coded, but I like the above better. I am still
unclear how parameters are passed.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +