Re: ssl passphrase callback - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: ssl passphrase callback
Date
Msg-id CABUevEzyiifTZZ-Wpt2T4r+js+3RT6NyTHLY4A3YhOxG0cVTHA@mail.gmail.com
Whole thread Raw
In response to Re: ssl passphrase callback  (Bruce Momjian <bruce@momjian.us>)
Responses Re: ssl passphrase callback  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Wed, Nov 6, 2019 at 7:24 PM Bruce Momjian <bruce@momjian.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.dunstan@2ndquadrant.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

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Using multiple extended statistics for estimates
Next
From: Tom Lane
Date:
Subject: pg_upgrade fails to detect unsupported arrays and ranges