Horton

Re: ssl passphrase callback

Simon Riggs <simon@2ndquadrant.com>

View thread
From: Simon Riggs <simon@2ndquadrant.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Magnus Hagander <magnus@hagander.net>, Andrew Dunstan <andrew.dunstan@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-11-13T13:20:43Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Provide a TLS init hook

On Wed, 13 Nov 2019 at 13:08, Bruce Momjian <bruce@momjian.us> wrote:

> 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@momjian.us> wrote:
>
> > > 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?
>

Yes


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

Very good idea

-- 
Simon Riggs                http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Solutions for the Enterprise