Re: ssl passphrase callback
От | Tomas Vondra |
---|---|
Тема | Re: ssl passphrase callback |
Дата | |
Msg-id | 20191113202323.uonpscpef4v35oll@development обсуждение исходный текст |
Ответ на | Re: ssl passphrase callback (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: ssl passphrase callback
Re: ssl passphrase callback |
Список | pgsql-hackers |
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. > >> > 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. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: