Re: ssl passphrase callback - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: ssl passphrase callback
Date
Msg-id CABUevEyzaWvfbwGR-t1HR1nonYMLLLRizNL-9061goUPi2rU9Q@mail.gmail.com
Whole thread Raw
In response to Re: ssl passphrase callback  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: ssl passphrase callback  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Wed, Nov 13, 2019 at 9:23 PM Tomas Vondra <tomas.vondra@2ndquadrant.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@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
>

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. 

--

pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions
Next
From: vignesh C
Date:
Subject: Re: dropdb --force