Re: ssl passphrase callback

On Tue, Nov 12, 2019 at 09:51:33PM -0500, Bruce Momjian wrote:
> On Sun, Nov 10, 2019 at 01:01:17PM -0600, Magnus Hagander wrote:
> > On Wed, Nov 6, 2019 at 7:24 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >   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.
>
> I get the callback-is-easier issue with shared objects, but are we
> expecting to pass in more information here than we do for
> archive_command? I would think not. What I am saying is that if we
> don't think passing things in works, we should fix all these external
> commands, or something. I don't see why ssl_passphrase_command is
> different, except that it is new. Or is it related to _securely_
> passing something?
>
> Also, why was this patch posted without any discussion of these issues?
> Shouldn't we ideally discuss the API first?

I wonder if every GUC that takes an OS command should allow a shared
object to be specified --- maybe control that if the command string
starts with a # or something.

--
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 +