Re: ssl passphrase callback

On 12/6/19 6:20 PM, Tom Lane wrote:
> Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> writes:
>> I've just been looking at that. load_external_function() doesn't
>> actually do anything V1-ish with the value, it just looks up the symbol
>> using dlsym and returns it cast to a PGFunction. Is there any reason I
>> can't just use that and cast it again to the callback function type?
> TBH, I think this entire discussion has gone seriously off into the
> weeds. The original design where we just let a shared_preload_library
> function get into a hook is far superior to any of the overcomplicated
> kluges that are being discussed now. Something like this, for instance:
>
>>>> ssl_passphrase_command='#superlib.so,my_rot13_passphrase'
> makes me positively ill. It introduces problems that we don't need,
> like how to parse out the sub-parts of the string, and the
> quoting/escaping issues that will come along with that; while from
> the user's perspective it replaces a simple and intellectually-coherent
> variable definition with an unintelligible mess.
>
>

Yeah, you have a point.

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.

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."

cheers

andrew

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