Re: ssl passphrase callback

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: ssl passphrase callback
Date: 2019-11-14 10:42:05
Message-ID: CABUevEyzaWvfbwGR-t1HR1nonYMLLLRizNL-9061goUPi2rU9Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 13, 2019 at 9:23 PM Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
wrote:

> On Wed, Nov 13, 2019 at 01:20:43PM +0000, Simon Riggs wrote:
> >On Wed, 13 Nov 2019 at 13:08, Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)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
> >
>
> I think it would be beneficial to explain why shared object is more
> secure than an OS command. Perhaps it's common knowledge, but it's not
> quite obvious to me.
>

Yeah, that probably wouldn't hurt. It's also securely passing from more
than one perspective -- both from the "cannot be eavesdropped" (like
putting the password on the commandline for example) and the requirement
for escaping.

>
> >
> >> > 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
> >
>
> If it's about securely passing sensitive information (i.e. passphrase)
> as was suggested, then I think that only applies to fairly small number
> of GUCs.
>

There aren't exactly a large number of GUCs that take OS commands in total.
Consistency itself certainly has some value.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2019-11-14 11:12:09 Re: dropdb --force
Previous Message Dilip Kumar 2019-11-14 10:09:56 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions