Re: ssl passphrase callback
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-11-07T01:23:56Z
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 →
-
Provide a TLS init hook
- 896fcdb230e7 13.0 landed
On Fri, Nov 1, 2019 at 01:57:29PM -0400, Andrew Dunstan wrote: > > On 11/1/19 11:01 AM, Robert Haas wrote: > > On Thu, Oct 31, 2019 at 11:37 AM Andrew Dunstan > > <andrew.dunstan@2ndquadrant.com> wrote: > >> This patch provides a hook for a function that can supply an SSL > >> passphrase. The hook can be filled in by a shared preloadable module. In > >> order for that to be effective, the startup order is modified slightly. > >> There is a test attached that builds and uses one trivial > >> implementation, which just takes a configuration setting and rot13's it > >> before supplying the result as the passphrase. > > It seems to me that it would be a lot better to have an example in > > contrib that does something which might be of actual use to users, > > such as running a shell command and reading the passphrase from > > stdout. > > > > Features that are only accessible by writing C code are, in general, > > not as desirable as features which can be accessed via SQL or > > configuration. > > > > > Well, I tried to provide the most trivial and simple test I could come > up with. Running a shell command can already be accomplished via the > ssl_passphrase_command setting. What is the value of a shared library over a shell command? We had this discussion in relation to archive_command years ago, and decided on a shell command as the best API. -- Bruce Momjian <bruce@momjian.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 +