Re: ssl passphrase callback

On Wed, Nov 6, 2019 at 7:24 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> On Fri, Nov 1, 2019 at 01:57:29PM -0400, Andrew Dunstan wrote:
> >
> > On 11/1/19 11:01 AM, Robert Haas wrote:
> > > On Thu, Oct 31, 2019 at 11:37 AM Andrew Dunstan
> > > <andrew(dot)dunstan(at)2ndquadrant(dot)com> wrote:
> > >> This patch provides a hook for a function that can supply an SSL
> > >> passphrase. The hook can be filled in by a shared preloadable module.
> In
> > >> order for that to be effective, the startup order is modified
> slightly.
> > >> There is a test attached that builds and uses one trivial
> > >> implementation, which just takes a configuration setting and rot13's
> it
> > >> before supplying the result as the passphrase.
> > > It seems to me that it would be a lot better to have an example in
> > > contrib that does something which might be of actual use to users,
> > > such as running a shell command and reading the passphrase from
> > > stdout.
> > >
> > > Features that are only accessible by writing C code are, in general,
> > > not as desirable as features which can be accessed via SQL or
> > > configuration.
> > >
> >
> >
> > Well, I tried to provide the most trivial and simple test I could come
> > up with. Running a shell command can already be accomplished via the
> > ssl_passphrase_command setting.
>
> What is the value of a shared library over a shell command?

For one, platforms where shell commands are a lot less convenient, such as
Windows.

> We had this
> discussion in relation to archive_command years ago, and decided on a
> shell command as the best API.
>
>
I don't recall that from back then, but that was a long time ago.

But it's interesting that you mention it, given the number of people I have
been discussing that with recently, under the topic of changing it from a
shell command into a shared library API (with there being a shell command
as one possible implementation of course).

One of the main reasons there being to be easily able to transfer more
state and give results other than just an exit code, no need to deal with
parameter escaping etc. Which probably wouldn't matter as much to an SSL
passphrase command, but still.

//Magnus