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@momjian.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 +