ssl passphrase callback

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
48 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: ssl passphrase callback

Tomas Vondra-4
On Thu, Nov 14, 2019 at 11:34:24AM -0500, Andrew Dunstan wrote:

>
>On 11/14/19 11:07 AM, Bruce Momjian wrote:
>> On Thu, Nov 14, 2019 at 11:42:05AM +0100, Magnus Hagander wrote:
>>> On Wed, Nov 13, 2019 at 9:23 PM Tomas Vondra <[hidden email]>
>>>     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.
>> I think a bigger issue is that if you want to give people the option of
>> using a shell command or a shared object, and if you use two commands to
>> control it, it isn't clear what happens if both are defined.  By using
>> some character prefix to control if a shared object is used, you can use
>> a single variable and there is no confusion over having two variables
>> and their conflicting behavior.
>>
>
>
>I'm  not sure how that would work in the present instance. The shared
>preloaded module installs a function and defines the params it wants. If
>we somehow unify the params with ssl_passphrase_command that could look
>icky, and the module would have to parse the settings string. That's not
>a problem for the sample module which only needs one param, but it will
>be for other more complex implementations.
>
>I'm quite open to suggestions, but I want things to be tolerably clean.
>

I agree it's better to have two separate GUCs - one for command, one for
shared object, and documented order of precedence. I suppose we may log
a warning when both are specified, or perhaps "reset" the value with
lower order of precedence.

regards

--
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Reply | Threaded
Open this post in threaded view
|

Re: ssl passphrase callback

Bruce Momjian
In reply to this post by Andrew Dunstan-8
On Thu, Nov 14, 2019 at 11:34:24AM -0500, Andrew Dunstan wrote:

>
> On 11/14/19 11:07 AM, Bruce Momjian wrote:
> > On Thu, Nov 14, 2019 at 11:42:05AM +0100, Magnus Hagander wrote:
> >> On Wed, Nov 13, 2019 at 9:23 PM Tomas Vondra <[hidden email]>
> >>     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.
> > I think a bigger issue is that if you want to give people the option of
> > using a shell command or a shared object, and if you use two commands to
> > control it, it isn't clear what happens if both are defined.  By using
> > some character prefix to control if a shared object is used, you can use
> > a single variable and there is no confusion over having two variables
> > and their conflicting behavior.
> >
>
>
> I'm  not sure how that would work in the present instance. The shared
> preloaded module installs a function and defines the params it wants. If
> we somehow unify the params with ssl_passphrase_command that could look
> icky, and the module would have to parse the settings string. That's not
> a problem for the sample module which only needs one param, but it will
> be for other more complex implementations.
>
> I'm quite open to suggestions, but I want things to be tolerably clean.

I was assuming if the variable starts with a #, it is a shared object,
if not, it is a shell command:

        ssl_passphrase_command='#/lib/x.so'
        ssl_passphrase_command='my_command a b c'

Can you show what you are talking about?

--
  Bruce Momjian  <[hidden email]>        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 +


Reply | Threaded
Open this post in threaded view
|

Re: ssl passphrase callback

Alvaro Herrera-9
On 2019-Nov-14, Bruce Momjian wrote:

> I was assuming if the variable starts with a #, it is a shared object,
> if not, it is a shell command:
>
> ssl_passphrase_command='#/lib/x.so'
> ssl_passphrase_command='my_command a b c'

Note that the proposed patch doesn't use a separate GUC -- it just uses
shared_preload_libraries, and then it is the library that's in charge of
setting up the function.  We probably wouldn't like to have multiple
settings that all do the same thing, such as recovery target (which
seems to be a plentiful source of confusion).

Changing the interface so that the user has to specify the function name
(not the library name) in ssl_passphrase_command closes that ambiguity
hole.

Note that if you specify only the library name, it becomes redundant
w.r.t. shared_preload_libraries; you could have more than one library
setting the function callback and it's hard to see which one wins.

I think something like this would do it:
  ssl_passphrase_command='#superlib.so,my_rot13_passphrase'

This way, the library can still create any custom GUCs it pleases/needs,
but there's no possible confusion as to the function that's going to be
called.

--
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Reply | Threaded
Open this post in threaded view
|

Re: ssl passphrase callback

Bruce Momjian
On Thu, Nov 14, 2019 at 02:07:58PM -0300, Alvaro Herrera wrote:

> On 2019-Nov-14, Bruce Momjian wrote:
>
> > I was assuming if the variable starts with a #, it is a shared object,
> > if not, it is a shell command:
> >
> > ssl_passphrase_command='#/lib/x.so'
> > ssl_passphrase_command='my_command a b c'
>
> Note that the proposed patch doesn't use a separate GUC -- it just uses
> shared_preload_libraries, and then it is the library that's in charge of
> setting up the function.  We probably wouldn't like to have multiple
> settings that all do the same thing, such as recovery target (which
> seems to be a plentiful source of confusion).
>
> Changing the interface so that the user has to specify the function name
> (not the library name) in ssl_passphrase_command closes that ambiguity
> hole.
>
> Note that if you specify only the library name, it becomes redundant
> w.r.t. shared_preload_libraries; you could have more than one library
> setting the function callback and it's hard to see which one wins.
>
> I think something like this would do it:
>   ssl_passphrase_command='#superlib.so,my_rot13_passphrase'
>
> This way, the library can still create any custom GUCs it pleases/needs,
> but there's no possible confusion as to the function that's going to be
> called.

Yeah, I was unclear how the function name would be specified.  I thought
it would just be hard-coded, but I like the above better.  I am still
unclear how parameters are passed.

--
  Bruce Momjian  <[hidden email]>        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 +


Reply | Threaded
Open this post in threaded view
|

Re: ssl passphrase callback

Andrew Dunstan-8
In reply to this post by Alvaro Herrera-9

On 11/14/19 12:07 PM, Alvaro Herrera wrote:

> On 2019-Nov-14, Bruce Momjian wrote:
>
>> I was assuming if the variable starts with a #, it is a shared object,
>> if not, it is a shell command:
>>
>> ssl_passphrase_command='#/lib/x.so'
>> ssl_passphrase_command='my_command a b c'
> Note that the proposed patch doesn't use a separate GUC -- it just uses
> shared_preload_libraries, and then it is the library that's in charge of
> setting up the function.  We probably wouldn't like to have multiple
> settings that all do the same thing, such as recovery target (which
> seems to be a plentiful source of confusion).
>
> Changing the interface so that the user has to specify the function name
> (not the library name) in ssl_passphrase_command closes that ambiguity
> hole.
>
> Note that if you specify only the library name, it becomes redundant
> w.r.t. shared_preload_libraries; you could have more than one library
> setting the function callback and it's hard to see which one wins.
>
> I think something like this would do it:
>   ssl_passphrase_command='#superlib.so,my_rot13_passphrase'
>
> This way, the library can still create any custom GUCs it pleases/needs,
> but there's no possible confusion as to the function that's going to be
> called.


I guess this would work. There would have to be a deal of code to load
the library and lookup the symbol. Do we really think it's worth it?
Leveraging shared_preload_libraries makes this comparatively simple.


Also, calling this 'ssl_passphrase_command' seems a little odd.


A simpler way to handle it might be simply to error out and refuse to
start if both ssl_passphrase_function is set and ssl_passphrase_command
is set.


cheers


andrew

--
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Reply | Threaded
Open this post in threaded view
|

Re: ssl passphrase callback

Alvaro Herrera-9
On 2019-Nov-14, Andrew Dunstan wrote:

> I guess this would work. There would have to be a deal of code to load
> the library and lookup the symbol. Do we really think it's worth it?
> Leveraging shared_preload_libraries makes this comparatively simple.

Using the generic interface has the drawback that the user can make more
mistakes.  I think that's part of Bruce's issue with it (although I may
misinterpret.)

I think if you add most of it as a new entry point in dfmgr.c (where you
can leverage internal_library_load) and returns a function pointer to
the user specified function, it's all that much additional code.

(I don't think you can use load_external_function as is, because it
assumes fmgr V1 calling convention, which I'm not sure serves your case.
But then maybe it does.  And if not, then those 10 lines should be very
similar to the code you'd need to add.)

> A simpler way to handle it might be simply to error out and refuse to
> start if both ssl_passphrase_function is set and ssl_passphrase_command
> is set.

Yeah, you can do that too I guess, but I'm not sure I see that as simpler.

> Also, calling this 'ssl_passphrase_command' seems a little odd.

We could just rename ssl_passphrase_command to something more
generic, and add the existing name to map_old_guc_names to preserve
compatibility with pg12.  Maybe the new name could be simply
ssl_passphrase or perhaps ssl_passphrase_{reader,getter,pinentry}.

--
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Reply | Threaded
Open this post in threaded view
|

Re: ssl passphrase callback

Andrew Dunstan-8

On 11/14/19 3:21 PM, Alvaro Herrera wrote:

> On 2019-Nov-14, Andrew Dunstan wrote:
>
>> I guess this would work. There would have to be a deal of code to load
>> the library and lookup the symbol. Do we really think it's worth it?
>> Leveraging shared_preload_libraries makes this comparatively simple.
> Using the generic interface has the drawback that the user can make more
> mistakes.  I think that's part of Bruce's issue with it (although I may
> misinterpret.)
>
> I think if you add most of it as a new entry point in dfmgr.c (where you
> can leverage internal_library_load) and returns a function pointer to
> the user specified function, it's all that much additional code.
>
> (I don't think you can use load_external_function as is, because it
> assumes fmgr V1 calling convention, which I'm not sure serves your case.
> But then maybe it does.  And if not, then those 10 lines should be very
> similar to the code you'd need to add.)



In the absence of further comment I will try to code up something along
these lines.


cheers


andrew


--
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Reply | Threaded
Open this post in threaded view
|

Re: ssl passphrase callback

Craig Ringer-3
In reply to this post by Andrew Dunstan-8
On Fri, 15 Nov 2019 at 00:34, Andrew Dunstan <[hidden email]> wrote:

On 11/14/19 11:07 AM, Bruce Momjian wrote:
> On Thu, Nov 14, 2019 at 11:42:05AM +0100, Magnus Hagander wrote:
>> On Wed, Nov 13, 2019 at 9:23 PM Tomas Vondra <[hidden email]>
>>     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.
> I think a bigger issue is that if you want to give people the option of
> using a shell command or a shared object, and if you use two commands to
> control it, it isn't clear what happens if both are defined.  By using
> some character prefix to control if a shared object is used, you can use
> a single variable and there is no confusion over having two variables
> and their conflicting behavior.
>


I'm  not sure how that would work in the present instance. The shared
preloaded module installs a function and defines the params it wants. If
we somehow unify the params with ssl_passphrase_command that could look
icky, and the module would have to parse the settings string. That's not
a problem for the sample module which only needs one param, but it will
be for other more complex implementations.

I'm quite open to suggestions, but I want things to be tolerably clean.

If someone wants a shell command wrapper, they can load a contrib that delegates the hook to a shell command. So we can just ship a contrib, which acts both as test coverage for the feature, and a shell-command-support wrapper for anyone who desires that. 


--
 Craig Ringer                   http://www.2ndQuadrant.com/
 2ndQuadrant - PostgreSQL Solutions for the Enterprise
Reply | Threaded
Open this post in threaded view
|

Re: ssl passphrase callback

Andrew Dunstan-8
In reply to this post by Andrew Dunstan-8

On 11/15/19 8:59 AM, Andrew Dunstan wrote:

> On 11/14/19 3:21 PM, Alvaro Herrera wrote:
>> On 2019-Nov-14, Andrew Dunstan wrote:
>>
>>> I guess this would work. There would have to be a deal of code to load
>>> the library and lookup the symbol. Do we really think it's worth it?
>>> Leveraging shared_preload_libraries makes this comparatively simple.
>> Using the generic interface has the drawback that the user can make more
>> mistakes.  I think that's part of Bruce's issue with it (although I may
>> misinterpret.)
>>
>> I think if you add most of it as a new entry point in dfmgr.c (where you
>> can leverage internal_library_load) and returns a function pointer to
>> the user specified function, it's all that much additional code.
>>
>> (I don't think you can use load_external_function as is, because it
>> assumes fmgr V1 calling convention, which I'm not sure serves your case.
>> But then maybe it does.  And if not, then those 10 lines should be very
>> similar to the code you'd need to add.)


I've just been looking at that. load_external_function() doesn't
actually do anything V1-ish with the value, it just looks up the symbol
using dlsym and returns it cast to a PGFunction. Is there any reason I
can't just use that and cast it again to the callback function type?


cheers


andrew



--
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Reply | Threaded
Open this post in threaded view
|

Re: ssl passphrase callback

Tom Lane-2
Andrew Dunstan <[hidden email]> writes:
> I've just been looking at that. load_external_function() doesn't
> actually do anything V1-ish with the value, it just looks up the symbol
> using dlsym and returns it cast to a PGFunction. Is there any reason I
> can't just use that and cast it again to the callback function type?

TBH, I think this entire discussion has gone seriously off into the
weeds.  The original design where we just let a shared_preload_library
function get into a hook is far superior to any of the overcomplicated
kluges that are being discussed now.  Something like this, for instance:

>>> ssl_passphrase_command='#superlib.so,my_rot13_passphrase'

makes me positively ill.  It introduces problems that we don't need,
like how to parse out the sub-parts of the string, and the
quoting/escaping issues that will come along with that; while from
the user's perspective it replaces a simple and intellectually-coherent
variable definition with an unintelligible mess.

                        regards, tom lane


Reply | Threaded
Open this post in threaded view
|

Re: ssl passphrase callback

Andrew Dunstan-8

On 12/6/19 6:20 PM, Tom Lane wrote:

> Andrew Dunstan <[hidden email]> writes:
>> I've just been looking at that. load_external_function() doesn't
>> actually do anything V1-ish with the value, it just looks up the symbol
>> using dlsym and returns it cast to a PGFunction. Is there any reason I
>> can't just use that and cast it again to the callback function type?
> TBH, I think this entire discussion has gone seriously off into the
> weeds.  The original design where we just let a shared_preload_library
> function get into a hook is far superior to any of the overcomplicated
> kluges that are being discussed now.  Something like this, for instance:
>
>>>> ssl_passphrase_command='#superlib.so,my_rot13_passphrase'
> makes me positively ill.  It introduces problems that we don't need,
> like how to parse out the sub-parts of the string, and the
> quoting/escaping issues that will come along with that; while from
> the user's perspective it replaces a simple and intellectually-coherent
> variable definition with an unintelligible mess.
>
>



Yeah, you have a point.


Bruce was worried about what would happen if we defined both
ssl_passphrase_command and ssl_passphrase_callback. The submitted patch
let's the callback have precedence, but it might be cleaner to error out
with such a config. OTOH, that wouldn't be so nice on a reload, so it
might be better just to document the behaviour.


He was also worried that multiple shared libraries might try to provide
the hook. I think that's fairly fanciful, TBH. It comes into the
category of "Don't do that."


cheers


andrew



--
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Reply | Threaded
Open this post in threaded view
|

Re: ssl passphrase callback

Tom Lane-2
Andrew Dunstan <[hidden email]> writes:
> Bruce was worried about what would happen if we defined both
> ssl_passphrase_command and ssl_passphrase_callback. The submitted patch
> let's the callback have precedence, but it might be cleaner to error out
> with such a config. OTOH, that wouldn't be so nice on a reload, so it
> might be better just to document the behaviour.

I think it would be up to the extension that's using the hook to
decide what to do if ssl_passphrase_command is set.  It would not
be our choice, and it would certainly not fall to us to document it.

> He was also worried that multiple shared libraries might try to provide
> the hook. I think that's fairly fanciful, TBH. It comes into the
> category of "Don't do that."

Again, it's somebody else's problem.  We have plenty of hooks that
are of dubious use for multiple extensions, so why should this one be
held to a higher standard?

                        regards, tom lane


Reply | Threaded
Open this post in threaded view
|

Re: ssl passphrase callback

Andrew Dunstan-8

On 12/7/19 12:16 PM, Tom Lane wrote:

> Andrew Dunstan <[hidden email]> writes:
>> Bruce was worried about what would happen if we defined both
>> ssl_passphrase_command and ssl_passphrase_callback. The submitted patch
>> let's the callback have precedence, but it might be cleaner to error out
>> with such a config. OTOH, that wouldn't be so nice on a reload, so it
>> might be better just to document the behaviour.
> I think it would be up to the extension that's using the hook to
> decide what to do if ssl_passphrase_command is set.  It would not
> be our choice, and it would certainly not fall to us to document it.
>
>> He was also worried that multiple shared libraries might try to provide
>> the hook. I think that's fairly fanciful, TBH. It comes into the
>> category of "Don't do that."
> Again, it's somebody else's problem.  We have plenty of hooks that
> are of dubious use for multiple extensions, so why should this one be
> held to a higher standard?
>
>


Well that pretty much brings us back to the patch as submitted :-)


cheers


andrew

--
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Reply | Threaded
Open this post in threaded view
|

Re: ssl passphrase callback

Tom Lane-2
Andrew Dunstan <[hidden email]> writes:
> Well that pretty much brings us back to the patch as submitted :-)

Yeah, pretty nearly.  Taking a quick look over the v3 patch, my
only quibble is that it doesn't provide any convenient way for the
external module to make decisions about how to interact with
ssl_passphrase_command --- in particular, if it would like to allow
that to take precedence, it can't because there's no way for it to
invoke the static function ssl_external_passwd_cb.

But rather than expose that globally, maybe the theory ought to be
"set up the state as we'd normally do, then let loadable modules
choose to override it".  So I'm tempted to propose a hook function
with the signature

void openssl_tls_init_hook(SSL_CTX *context, bool isServerStart);

and invoke that somewhere in be_tls_init --- maybe fairly late,
so that it can override other settings if it wants, not only the
SSL_CTX_set_default_passwd_cb setting.

                        regards, tom lane


Reply | Threaded
Open this post in threaded view
|

Re: ssl passphrase callback

Craig Ringer-3
In reply to this post by Tom Lane-2
On Sat, 7 Dec 2019 at 07:21, Tom Lane <[hidden email]> wrote:
Andrew Dunstan <[hidden email]> writes:
> I've just been looking at that. load_external_function() doesn't
> actually do anything V1-ish with the value, it just looks up the symbol
> using dlsym and returns it cast to a PGFunction. Is there any reason I
> can't just use that and cast it again to the callback function type?

TBH, I think this entire discussion has gone seriously off into the
weeds.  The original design where we just let a shared_preload_library
function get into a hook is far superior to any of the overcomplicated
kluges that are being discussed now.  Something like this, for instance:

>>> ssl_passphrase_command='#superlib.so,my_rot13_passphrase'

makes me positively ill.  It introduces problems that we don't need,
like how to parse out the sub-parts of the string, and the
quoting/escaping issues that will come along with that; while from
the user's perspective it replaces a simple and intellectually-coherent
variable definition with an unintelligible mess.

+1000 from me on that. 


--
 Craig Ringer                   http://www.2ndQuadrant.com/
 2ndQuadrant - PostgreSQL Solutions for the Enterprise
Reply | Threaded
Open this post in threaded view
|

Re: ssl passphrase callback

Andrew Dunstan-8
In reply to this post by Tom Lane-2
On Sun, Dec 8, 2019 at 9:02 AM Tom Lane <[hidden email]> wrote:

>
> Andrew Dunstan <[hidden email]> writes:
> > Well that pretty much brings us back to the patch as submitted :-)
>
> Yeah, pretty nearly.  Taking a quick look over the v3 patch, my
> only quibble is that it doesn't provide any convenient way for the
> external module to make decisions about how to interact with
> ssl_passphrase_command --- in particular, if it would like to allow
> that to take precedence, it can't because there's no way for it to
> invoke the static function ssl_external_passwd_cb.
>
> But rather than expose that globally, maybe the theory ought to be
> "set up the state as we'd normally do, then let loadable modules
> choose to override it".  So I'm tempted to propose a hook function
> with the signature
>
> void openssl_tls_init_hook(SSL_CTX *context, bool isServerStart);
>
> and invoke that somewhere in be_tls_init --- maybe fairly late,
> so that it can override other settings if it wants, not only the
> SSL_CTX_set_default_passwd_cb setting.
>

Not sure if the placement is what you want, but maybe something like this?

cheers

andrew


--
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

ssl-passphrase-callback-4.patch (13K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ssl passphrase callback

Robert Haas
In reply to this post by Sehrope Sarkuni
On Thu, Nov 14, 2019 at 8:54 AM Sehrope Sarkuni <[hidden email]> wrote:
> Has the idea of using environment variables (rather than command line
> args) for external commands been brought up before? I couldn't find
> anything in the mailing list archives.

Passing data through environment variables isn't secure. Try 'ps -E'
on MacOS, or something like 'ps axe' on Linux.

If we want to pass data securely to child processes, the way to do it
is via stdin. Data sent back and forth via file descriptors can't
easily be snooped by other users on the system.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


Reply | Threaded
Open this post in threaded view
|

Re: ssl passphrase callback

Thomas Munro-5
In reply to this post by Andrew Dunstan-8
On Wed, Jan 22, 2020 at 8:02 PM Andrew Dunstan
<[hidden email]> wrote:
> Not sure if the placement is what you want, but maybe something like this?

Hi Andrew, FYI this failed here:

t/001_testfunc.pl .. Bailout called. Further testing stopped: pg_ctl
start failed
FAILED--Further testing stopped: pg_ctl start failed
Makefile:23: recipe for target 'prove-check' failed

Unfortunately my robot is poorly trained and does not dump any of the
interesting logs for this case, but it looks like it's failing that
way every time.

https://travis-ci.org/postgresql-cfbot/postgresql/builds/651756191


Reply | Threaded
Open this post in threaded view
|

Re: ssl passphrase callback

Andrew Dunstan-8
On Tue, Feb 18, 2020 at 2:01 PM Thomas Munro <[hidden email]> wrote:

>
> On Wed, Jan 22, 2020 at 8:02 PM Andrew Dunstan
> <[hidden email]> wrote:
> > Not sure if the placement is what you want, but maybe something like this?
>
> Hi Andrew, FYI this failed here:
>
> t/001_testfunc.pl .. Bailout called. Further testing stopped: pg_ctl
> start failed
> FAILED--Further testing stopped: pg_ctl start failed
> Makefile:23: recipe for target 'prove-check' failed
>
> Unfortunately my robot is poorly trained and does not dump any of the
> interesting logs for this case, but it looks like it's failing that
> way every time.
>
> https://travis-ci.org/postgresql-cfbot/postgresql/builds/651756191


Thanks for letting me know, I will investigate.

cheers

andrew


--
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Reply | Threaded
Open this post in threaded view
|

Re: ssl passphrase callback

Andrew Dunstan-8
On Wed, Feb 19, 2020 at 7:10 AM Andrew Dunstan
<[hidden email]> wrote:

>
> On Tue, Feb 18, 2020 at 2:01 PM Thomas Munro <[hidden email]> wrote:
> >
> > On Wed, Jan 22, 2020 at 8:02 PM Andrew Dunstan
> > <[hidden email]> wrote:
> > > Not sure if the placement is what you want, but maybe something like this?
> >
> > Hi Andrew, FYI this failed here:
> >
> > t/001_testfunc.pl .. Bailout called. Further testing stopped: pg_ctl
> > start failed
> > FAILED--Further testing stopped: pg_ctl start failed
> > Makefile:23: recipe for target 'prove-check' failed
> >
> > Unfortunately my robot is poorly trained and does not dump any of the
> > interesting logs for this case, but it looks like it's failing that
> > way every time.
> >
> > https://travis-ci.org/postgresql-cfbot/postgresql/builds/651756191
>
>
> Thanks for letting me know, I will investigate.
>

This should fix the issue, it happened when I switched to using a
pre-generated cert/key.

cheers

andrew

--
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

ssl-passphrase-callback-5.patch (22K) Download Attachment
123