Bruce Momjian writes:
> Merlin Moncure wrote:
>>> I think we should just do PQinitOpenSSL(2 args) and be done with it.
>>
>> I was pushing for generic PQinit, but have come around and agree with
>> this point of view.
> OK, we are _go_ then.
Done. Let's hope this thread stays dead.
Andrew Chernow writes:
> I modified my previous patch to use a two-argument function solution.
Applied with minor changes (rename to PQinitOpenSSL per discussion,
some comment and docs improvements).
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hacker
Merlin Moncure wrote:
> On Mon, Mar 30, 2009 at 3:27 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> I guess that'd work but it might be overkill.
> >
> > The real bottom line is that *all* the proposals for generic init
> > functions are overkill. ?We have no evidence that we need one and
> > n
On Mon, Mar 30, 2009 at 3:27 PM, Tom Lane wrote:
> Robert Haas writes:
>> I guess that'd work but it might be overkill.
>
> The real bottom line is that *all* the proposals for generic init
> functions are overkill. We have no evidence that we need one and
> no certainty about what the requireme
Robert Haas writes:
> I guess that'd work but it might be overkill.
The real bottom line is that *all* the proposals for generic init
functions are overkill. We have no evidence that we need one and
no certainty about what the requirements for it would be if we did.
I think we should just do PQ
On Mon, Mar 30, 2009 at 2:59 PM, Andrew Chernow wrote:
> Robert Haas wrote:
>>
>> Or we might need a whole "char *" or "int" argument for some purpose
>> unrelated to SSL. Then we'll have a PQinit() function that pretends
>> to be a general-purpose initialization mechanism but really isn't.
>>
>
Robert Haas wrote:
Or we might need a whole "char *" or "int" argument for some purpose
unrelated to SSL. Then we'll have a PQinit() function that pretends
to be a general-purpose initialization mechanism but really isn't.
I proposed a PQinit() that included a void data pointer argument. The
Bruce Momjian wrote:
It seems having the init function return the bits it recognized would be
the logical return value.
That's what my first PQionitSecure patch did, actually it returned the
bits it didn't understand.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
S
On Mon, Mar 30, 2009 at 2:31 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian writes:
>> > Tom Lane wrote:
>> >> And we get into the whole question of error handling, which is what
>> >> shot down that proposal last time.
>>
>> > Can you remind me of the details? I don't remember that
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> And we get into the whole question of error handling, which is what
> >> shot down that proposal last time.
>
> > Can you remind me of the details? I don't remember that issue.
> > Currently PQinitSSL() returns void, so I don't see
Tom Lane wrote:
I think we should stick with the simple two-argument function and not
+100
Generic PQinit concept was already punted several times. Using a bit
mask for initsecure or something was also tried and rejected. The well
is dry on this.
--
Andrew Chernow
eSilo, LLC
every b
Bruce Momjian writes:
> Tom Lane wrote:
>> And we get into the whole question of error handling, which is what
>> shot down that proposal last time.
> Can you remind me of the details? I don't remember that issue.
> Currently PQinitSSL() returns void, so I don't see an issue there.
The point is
Tom Lane wrote:
> Magnus Hagander writes:
> > Bruce Momjian wrote:
> >> Are we sure we don't want to add a more general libpq initialization
> >> control at this time?
> >>
> >> PQinitOptions(PG_NO_SSL_INIT | PG_NO_CRYPTO_INIT);
>
> > Could be an option but if we go down that path, it needs to b
Magnus Hagander writes:
> Bruce Momjian wrote:
>> Are we sure we don't want to add a more general libpq initialization
>> control at this time?
>>
>> PQinitOptions(PG_NO_SSL_INIT | PG_NO_CRYPTO_INIT);
> Could be an option but if we go down that path, it needs to be
> PG_NO_OPENSSL_SSL_INIT and P
Bruce Momjian wrote:
> Magnus Hagander wrote:
>> On 30 mar 2009, at 17.24, Andrew Chernow wrote:
>>
>>> Tom Lane wrote:
BTW, unless someone objects I'd like to make the name of that
function
PQinitSecurity.
>>> Agreed. Although, both PQinitSecure and PQinitSecurity are very
>>>
Magnus Hagander wrote:
> On 30 mar 2009, at 17.24, Andrew Chernow wrote:
>
> > Tom Lane wrote:
> >> BTW, unless someone objects I'd like to make the name of that
> >> function
> >> PQinitSecurity.
> >
> > Agreed. Although, both PQinitSecure and PQinitSecurity are very
> > general names. "Se
On Mon, Mar 30, 2009 at 11:56 AM, Magnus Hagander wrote:
> On 30 mar 2009, at 17.24, Andrew Chernow wrote:
>
>> Tom Lane wrote:
>>>
>>> BTW, unless someone objects I'd like to make the name of that function
>>> PQinitSecurity.
>>
>> Agreed. Although, both PQinitSecure and PQinitSecurity are very
On 30 mar 2009, at 17.24, Andrew Chernow wrote:
Tom Lane wrote:
BTW, unless someone objects I'd like to make the name of that
function
PQinitSecurity.
Agreed. Although, both PQinitSecure and PQinitSecurity are very
general names. "Security" can mean a lot of things. Maybe the name
s
Tom Lane wrote:
BTW, unless someone objects I'd like to make the name of that function
PQinitSecurity.
Agreed. Although, both PQinitSecure and PQinitSecurity are very general
names. "Security" can mean a lot of things. Maybe the name should be
more particular, like PQinitOpenSSL. I th
Bruce Momjian wrote:
Merlin Moncure wrote:
On Mon, Mar 30, 2009 at 10:22 AM, Robert Haas wrote:
On Mon, Mar 30, 2009 at 9:36 AM, Andrew Chernow wrote:
Tom Lane wrote:
I personally would be happy with the two-argument function solution.
I modified my previous patch to use a two-argument fu
Merlin Moncure wrote:
> On Mon, Mar 30, 2009 at 10:22 AM, Robert Haas wrote:
> > On Mon, Mar 30, 2009 at 9:36 AM, Andrew Chernow wrote:
> >> Tom Lane wrote:
> >>>
> >>> I personally would be happy with the two-argument function solution.
> >>>
> >>
> >> I modified my previous patch to use a two-a
Merlin Moncure writes:
> On Mon, Mar 30, 2009 at 10:22 AM, Robert Haas wrote:
>> This looks OK to me, except I think we should modify the documentation
>> to PQinitSSL() to say that it you must not use both that function and
>> PQinitSecure(), and explain that if you need to control initializatio
Merlin Moncure wrote:
> On Mon, Mar 30, 2009 at 10:22 AM, Robert Haas wrote:
> > On Mon, Mar 30, 2009 at 9:36 AM, Andrew Chernow wrote:
> >> Tom Lane wrote:
> >>>
> >>> I personally would be happy with the two-argument function solution.
> >>>
> >>
> >> I modified my previous patch to use a two-a
On Mon, Mar 30, 2009 at 10:22 AM, Robert Haas wrote:
> On Mon, Mar 30, 2009 at 9:36 AM, Andrew Chernow wrote:
>> Tom Lane wrote:
>>>
>>> I personally would be happy with the two-argument function solution.
>>>
>>
>> I modified my previous patch to use a two-argument function solution.
>
> This lo
Tom Lane wrote:
Bruce Momjian writes:
Tom Lane wrote:
It sounds like everyone has converged on agreeing that this way is okay
for 8.4? Object now or hold your peace ...
What are we doing with PQinitSSL()?
Nothing, except improving the documentation.
My patch didn't change the docs at
Tom Lane wrote:
> Robert Haas writes:
> > This looks OK to me, except I think we should modify the documentation
> > to PQinitSSL() to say that it you must not use both that function and
> > PQinitSecure(), and explain that if you need to control initialization
> > of libcrypto and libssl, you sho
Tom Lane wrote:
> Andrew Chernow writes:
> > I modified my previous patch to use a two-argument function solution.
>
> It sounds like everyone has converged on agreeing that this way is okay
> for 8.4? Object now or hold your peace ...
What are we doing with PQinitSSL()?
--
Bruce Momjian
Robert Haas writes:
> This looks OK to me, except I think we should modify the documentation
> to PQinitSSL() to say that it you must not use both that function and
> PQinitSecure(), and explain that if you need to control initialization
> of libcrypto and libssl, you should use that function inst
On Mon, Mar 30, 2009 at 9:36 AM, Andrew Chernow wrote:
> Tom Lane wrote:
>>
>> I personally would be happy with the two-argument function solution.
>>
>
> I modified my previous patch to use a two-argument function solution.
This looks OK to me, except I think we should modify the documentation
t
Bruce Momjian writes:
> Tom Lane wrote:
>> It sounds like everyone has converged on agreeing that this way is okay
>> for 8.4? Object now or hold your peace ...
> What are we doing with PQinitSSL()?
Nothing, except improving the documentation.
regards, tom lane
--
Sen
Andrew Chernow writes:
> I modified my previous patch to use a two-argument function solution.
It sounds like everyone has converged on agreeing that this way is okay
for 8.4? Object now or hold your peace ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (p
Tom Lane wrote:
I personally would be happy with the two-argument function solution.
I modified my previous patch to use a two-argument function solution.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
Index: doc/src/sgml/libpq.sgml
==
On Sun, Mar 29, 2009 at 1:56 PM, Bruce Momjian wrote:
> I think this is where we got stuck because extending libpq with a new
> function is a larger API change, and not having a clear plan of what
> initialization stuff we might need in the future, it seems unwise, and
> also perhaps overkill.
ri
Tom Lane wrote:
> Bruce Momjian writes:
> > Andrew Chernow wrote:
> >> Adding PQinitSSL(new_value) seem reasonable to me. My only complaint
> >> has been that the API user has no way of knowing if the function
> >> understood their request.
>
> > I think doing PQinitSSL(new_value) is probably
Tom Lane wrote:
I personally would be happy with the two-argument function solution.
The patch I submitted pretty much does this, except it uses a flags argument
instead of 2 fixed arguments. It can be easily changed to support the 2
argument idea:
1. Change prototype to: void PQinitSecu
Bruce Momjian writes:
> Andrew Chernow wrote:
>> Adding PQinitSSL(new_value) seem reasonable to me. My only complaint
>> has been that the API user has no way of knowing if the function
>> understood their request.
> I think doing PQinitSSL(new_value) is probably the least invasive change
> to
Andrew Chernow wrote:
> Robert Haas wrote:
> >
> > Is there more substance here than meets the eye?
> >
>
> No, you about summed it up. We need a way to init libssl and libcrypto
> in any combo. Along the way, PQinit() was discussed which may have
> muddied the waters.
>
> I prefer leaving
Robert Haas wrote:
Is there more substance here than meets the eye?
No, you about summed it up. We need a way to init libssl and libcrypto
in any combo. Along the way, PQinit() was discussed which may have
muddied the waters.
I prefer leaving the PQinitSSL function alone, thus my patch
On Sat, Mar 28, 2009 at 3:51 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> Well, we are not the "Make Merlin Happy club". ;-)
>
> Merlin and Andrew were the ones complaining initially. If they feel
> that a proposed patch doesn't fix the problem, then I'd say that it
> isn't fixing the problem
On Sat, Mar 28, 2009 at 4:26 PM, Bruce Momjian wrote:
> Andrew Chernow wrote:
>> Tom Lane wrote:
>> > This is just a rehash of one of the patches that was discussed earlier.
>> > There wasn't consensus for it then, and there's not now.
>> >
>>
>> I am personally out of ideas. It feels like this i
Andrew Chernow wrote:
> Tom Lane wrote:
> > This is just a rehash of one of the patches that was discussed earlier.
> > There wasn't consensus for it then, and there's not now.
> >
>
> I am personally out of ideas. It feels like this issue has been beaten
> to death. There are only a few ways
Tom Lane wrote:
This is just a rehash of one of the patches that was discussed earlier.
There wasn't consensus for it then, and there's not now.
I am personally out of ideas. It feels like this issue has been beaten
to death. There are only a few ways to do it and I believe they have
all b
Bruce Momjian writes:
> Well, we are not the "Make Merlin Happy club". ;-)
Merlin and Andrew were the ones complaining initially. If they feel
that a proposed patch doesn't fix the problem, then I'd say that it
isn't fixing the problem.
> My personal opinion is that adding #defines to PQinitSS
Merlin Moncure wrote:
> It is still a bug in the sense that it is impossible to properly
> initialize crypto features in some scenarios. A doc patch (which I
> argued is the best way to go for 8.4) fails to properly raise the
> seriousness of the issue and also fails to suggest a workaround.
>
>
On Sat, Mar 28, 2009 at 9:23 AM, Merlin Moncure wrote:
> It is still a bug in the sense that it is impossible to properly
> initialize crypto features in some scenarios. A doc patch (which I
Meant to say: 'your doc patch"
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
On Fri, Mar 27, 2009 at 9:38 PM, Bruce Momjian wrote:
> I have applied the attached patch which does several things:
>
> o documents that libssl _and_ libcrypto initialization is
> turned off by PQinitSSL(0)
> o clarified cases where this behavior is important
> o
Andrew Chernow wrote:
> Bruce Momjian wrote:
>
> > I think there is a good argument that PQinitSSL(X) where X > 1 would
> > work fine for more fine-grained control. The new libpq init function
> > idea was interesting, but having a documented solution for
> > WSAStartup()/WSACleanup() usage, we n
Bruce Momjian wrote:
I think there is a good argument that PQinitSSL(X) where X > 1 would
work fine for more fine-grained control. The new libpq init function
idea was interesting, but having a documented solution for
WSAStartup()/WSACleanup() usage, we now don't have another libpq init
use-cas
Merlin Moncure wrote:
> On Tue, Feb 10, 2009 at 5:02 PM, Bruce Momjian wrote:
> > Merlin Moncure wrote:
> >> > PQinitSSL(0) was specifically designed to allow applications to set up
> >> > SSL on their own. How does this not work properly?
> >>
> >> this has nothing to do with who initializes ssl
Andrew Chernow wrote:
Andrew Chernow wrote:
> Maybe better, have it return a zero/nonzero error code; where one
of the
> possibilities for failure is "you passed a bit I didn't understand".
Why not just return those bit(s) instead of an arbitrary code? How
about:
-1 = error (if it ever
Andrew Chernow wrote:
> Maybe better, have it return a zero/nonzero error code; where one of the
> possibilities for failure is "you passed a bit I didn't understand".
Why not just return those bit(s) instead of an arbitrary code? How about:
-1 = error (if it ever does anything that can fai
> Maybe better, have it return a zero/nonzero error code; where one of the
> possibilities for failure is "you passed a bit I didn't understand".
Why not just return those bit(s) instead of an arbitrary code? How about:
-1 = error (if it ever does anything that can fail)
0 = success (all bits
Andrew Chernow writes:
> 4. int PQinitSecure(int init_mask)
> This works just like #3 but returns the bits it understood. It allows an app
> to
> determine if the loaded libpq supports a bit it has tried to use.
Maybe better, have it return a zero/nonzero error code; where one of the
possibili
So far, we have the below ideas:
1. void PQinitSSL(MAGIC_VALUES)
The idea is to use some magic values to add more options, converting the do_init
argument from a flag to an enumeration. The idea is choose magic values that
would most likely never be used by existing libpq applications. The do
> Personally, I still subscribe to the PNG design theory that
> conditionalizing code on overall version numbers isn't a very good idea.
> Version information should be tied as tightly as possible to the
> particular behavior for which it applies.
> http://www.w3.org/TR/PNG-Rationale.html#R.Chunk-n
Robert Haas writes:
>> BTW, the bitmask isn't perfect either --- doesn't it just reintroduce
>> the problem already complained of with your idea for PQinitSSL? That
>> is, how does the client know whether the function recognized all the
>> bits it passed?
> Well, if we add the PQgetLibraryVersio
On Fri, Feb 13, 2009 at 4:53 PM, Robert Haas wrote:
>> BTW, the bitmask isn't perfect either --- doesn't it just reintroduce
>> the problem already complained of with your idea for PQinitSSL? That
>> is, how does the client know whether the function recognized all the
>> bits it passed?
>
> Well,
> BTW, the bitmask isn't perfect either --- doesn't it just reintroduce
> the problem already complained of with your idea for PQinitSSL? That
> is, how does the client know whether the function recognized all the
> bits it passed?
Well, if we add the PQgetLibraryVersion() function I suggested
up
Tom Lane wrote:
is, how does the client know whether the function recognized all the
bits it passed?
How about returning the bits it could set?
int mask = PG_INITSSL | PG_INITCRYPTO;
if (!(PQinitSecure(mask) & PG_INITCRYPTO))
; // no support for crypto
...OR...
consider a generic PQinit c
Merlin Moncure writes:
> On Fri, Feb 13, 2009 at 3:06 PM, Tom Lane wrote:
>> +1 for thinking ahead to the next time, but is a bit mask the right thing?
> What would you suggest? struct pointer? varargs?
Not sure. By definition, we're trying to predict an unforeseen
requirement, and that's al
On Fri, Feb 13, 2009 at 3:06 PM, Tom Lane wrote:
> Andrew Chernow writes:
>> Maybe the argument to PQinitSSLExtended should be a bit mask, making
>> this version more extendable ... PG_INITSSL, PG_INITCRYPTO?
>
> +1 for thinking ahead to the next time, but is a bit mask the right thing?
What wou
Andrew Chernow writes:
> Maybe the argument to PQinitSSLExtended should be a bit mask, making
> this version more extendable ... PG_INITSSL, PG_INITCRYPTO?
+1 for thinking ahead to the next time, but is a bit mask the right thing?
regards, tom lane
--
Sent via pgsql-ha
Tom Lane wrote:
Andrew Chernow writes:
Also, this definition feels a bit wrong --- it's not possible for
all four cases to be valid, is it?
Yes it is.
PQinitSSLExtended(0, 0); // don't init anything, PQinitSSL(0)
PQinitSSLExtended(1, 0); // init ssl, don't init crypto
PQinitSSLExtended(0,
Andrew Chernow writes:
>> Also, this definition feels a bit wrong --- it's not possible for
>> all four cases to be valid, is it?
> Yes it is.
> PQinitSSLExtended(0, 0); // don't init anything, PQinitSSL(0)
> PQinitSSLExtended(1, 0); // init ssl, don't init crypto
> PQinitSSLExtended(0, 1); // d
Andrew Chernow wrote:
At this point I like Merlin's proposal of a third parameter value to
PQinitSSL the best.
I'm not opposed to it, although I don't think it is as clean as a new
function.
Also, this definition feels a bit wrong --- it's not possible for
all four cases to be valid, is it
At this point I like Merlin's proposal of a third parameter value to
PQinitSSL the best.
I'm not opposed to it, although I don't think it is as clean as a new
function.
Also, this definition feels a bit wrong --- it's not possible for
all four cases to be valid, is it?
Yes it is.
PQinit
Andrew Chernow writes:
>> One problem with this patch is that a libpq app using PQinitSSL(0) is
>> under the assumption that this shuts off ssl init and crypto init. That
>> app might be doing its own crypto init which would be overwritten by
>> libpq because the app is unaware of PQinitCrypto
Andrew Chernow wrote:
Andrew Chernow wrote:
Robert Haas wrote:
On Fri, Feb 13, 2009 at 12:06 PM, Andrew Chernow wrote:
Patch attached.
One thing I noticed is the ssl_open_connections variable is ref
counting
connections when pq_initssllib is true. But, it now only affects
crypto
library i
Andrew Chernow wrote:
Robert Haas wrote:
On Fri, Feb 13, 2009 at 12:06 PM, Andrew Chernow wrote:
Patch attached.
One thing I noticed is the ssl_open_connections variable is ref counting
connections when pq_initssllib is true. But, it now only affects crypto
library init and cleanup calls. P
Robert Haas wrote:
On Fri, Feb 13, 2009 at 12:06 PM, Andrew Chernow wrote:
Patch attached.
One thing I noticed is the ssl_open_connections variable is ref counting
connections when pq_initssllib is true. But, it now only affects crypto
library init and cleanup calls. Point is, ref counting i
On Fri, Feb 13, 2009 at 12:06 PM, Andrew Chernow wrote:
> Patch attached.
>
> One thing I noticed is the ssl_open_connections variable is ref counting
> connections when pq_initssllib is true. But, it now only affects crypto
> library init and cleanup calls. Point is, ref counting is only needed
Robert Haas wrote:
On Fri, Feb 13, 2009 at 9:17 AM, Andrew Chernow wrote:
Should I create a patch implementing the PQinitCrypto idea?
I think that would be helpful. Seeing the code will give everyone a
better idea of exactly what the proposed change is and whether it's
acceptable.
...Robert
On Fri, Feb 13, 2009 at 9:17 AM, Andrew Chernow wrote:
> Should I create a patch implementing the PQinitCrypto idea?
I think that would be helpful. Seeing the code will give everyone a
better idea of exactly what the proposed change is and whether it's
acceptable.
...Robert
--
Sent via pgsql-
Robert Haas wrote:
On Feb 11, 2009, at 12:12 AM, Andrew Chernow wrote:
Robert Haas wrote:
I am not in love with the idea of using PQinitSSL(SOME_MAGIC_VALUE)
The issue I see is the inability to toggle crypto initialization. I
think crypto init and ssl init are 2 different things. Thus, I
Robert Haas wrote:
On Feb 11, 2009, at 12:12 AM, Andrew Chernow wrote:
Robert Haas wrote:
I am not in love with the idea of using PQinitSSL(SOME_MAGIC_VALUE)
The issue I see is the inability to toggle crypto initialization. I
think crypto init and ssl init are 2 different things. Thus, I
On Feb 11, 2009, at 12:12 AM, Andrew Chernow wrote:
Robert Haas wrote:
I am not in love with the idea of using PQinitSSL(SOME_MAGIC_VALUE)
The issue I see is the inability to toggle crypto initialization.
I think crypto init and ssl init are 2 different things. Thus, I
proposed the bel
Robert Haas wrote:
I am not in love with the idea of using PQinitSSL(SOME_MAGIC_VALUE)
The issue I see is the inability to toggle crypto initialization. I
think crypto init and ssl init are 2 different things. Thus, I proposed
the below:
http://archives.postgresql.org/pgsql-hackers/2009-
On Tue, Feb 10, 2009 at 11:09 PM, Bruce Momjian wrote:
> Why not just call PQinitSSL(true) and do everything in your
> application?; from the libpq manual:
>
> If you are using SSL inside your application (in addition
> to inside libpq), you can use
> PQinitSSL(int) to tell libpq
> that t
Bruce Momjian wrote:
> Andrew Chernow wrote:
> >
> > > On Tue, Feb 10, 2009 at 5:02 PM, Bruce Momjian wrote:
> > >> PQinitSSL(false) initializes crypto? Please point me to exact function
> > >> calls that are the problem? Everything is very vague.
> >
> > File: src/interfaces/libpq/fe-secure.c
Andrew Chernow wrote:
>
> > On Tue, Feb 10, 2009 at 5:02 PM, Bruce Momjian wrote:
> >> PQinitSSL(false) initializes crypto? Please point me to exact function
> >> calls that are the problem? Everything is very vague.
>
> File: src/interfaces/libpq/fe-secure.c
> Func: init_ssl_system
> Line: 82
On Tue, Feb 10, 2009 at 5:02 PM, Bruce Momjian wrote:
PQinitSSL(false) initializes crypto? Please point me to exact function
calls that are the problem? Everything is very vague.
File: src/interfaces/libpq/fe-secure.c
Func: init_ssl_system
Line: 823
Starting at around line 853, this funct
On Tue, Feb 10, 2009 at 5:02 PM, Bruce Momjian wrote:
> Merlin Moncure wrote:
>> > PQinitSSL(0) was specifically designed to allow applications to set up
>> > SSL on their own. How does this not work properly?
>>
>> this has nothing to do with who initializes ssl. this is all about
>> *crypto*.
On Tue, Feb 10, 2009 at 1:02 PM, Magnus Hagander wrote:
> Merlin Moncure wrote:
>> On Tue, Feb 10, 2009 at 12:03 PM, Dave Page wrote:
>>> On Tue, Feb 10, 2009 at 4:57 PM, Merlin Moncure wrote:
>>>
PQinitSSL is *broken*. It's always been broken. Since it already
takes a parameter, I s
Merlin Moncure wrote:
> On Tue, Feb 10, 2009 at 12:03 PM, Dave Page wrote:
>> On Tue, Feb 10, 2009 at 4:57 PM, Merlin Moncure wrote:
>>
>>> PQinitSSL is *broken*. It's always been broken. Since it already
>>> takes a parameter, I say add a special switch...the backwards
>>> compatibility danger
On Tue, Feb 10, 2009 at 5:05 PM, Merlin Moncure wrote:
> PQinitSSL(SSL_ONLY) or something, where the constant is carefully
> chosen to not be accidentally passed in by older libpq users.
Ahh, OK. That would be painless.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
--
Sent via
On Tue, Feb 10, 2009 at 12:03 PM, Merlin Moncure wrote:
> On Tue, Feb 10, 2009 at 11:54 AM, Bruce Momjian wrote:
>> Merlin Moncure wrote:
>>> On Tue, Feb 10, 2009 at 11:52 AM, Bruce Momjian wrote:
>>> > Robert Haas wrote:
>>> >> > Would someone remind me why turning off ssl initialization in lib
On Tue, Feb 10, 2009 at 12:03 PM, Dave Page wrote:
> On Tue, Feb 10, 2009 at 4:57 PM, Merlin Moncure wrote:
>
>> PQinitSSL is *broken*. It's always been broken. Since it already
>> takes a parameter, I say add a special switch...the backwards
>> compatibility danger doesn't seem too bad.
>
> Ad
Bruce Momjian wrote:
Andrew Chernow wrote:
Tom Lane wrote:
If that's all you want, then PQinitSSLExtended is a perfectly good
answer.
How about PQinitCrypto(bool do_init), which would default to TRUE if
never called. PQinitSSL already handles the SSL part, just need control
over initializ
On Tue, Feb 10, 2009 at 4:57 PM, Merlin Moncure wrote:
> PQinitSSL is *broken*. It's always been broken. Since it already
> takes a parameter, I say add a special switch...the backwards
> compatibility danger doesn't seem too bad.
Add a switch to what? I get very nervous for our Windows users
On Tue, Feb 10, 2009 at 11:54 AM, Bruce Momjian wrote:
> Merlin Moncure wrote:
>> On Tue, Feb 10, 2009 at 11:52 AM, Bruce Momjian wrote:
>> > Robert Haas wrote:
>> >> > Would someone remind me why turning off ssl initialization in libpq does
>> >> > not work for this case?
>> >>
>> >> That initia
On Tue, Feb 10, 2009 at 11:14 AM, Tom Lane wrote:
> Robert Haas writes:
Well, you could create PQinitSSLExtended, but, as you say, the use
case is pretty narrow...
It would help if there were a PQgetLibraryVersion() function.
>>>
>>> Help how? There is nothing an app can do to wor
Merlin Moncure wrote:
> On Tue, Feb 10, 2009 at 11:52 AM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> > Would someone remind me why turning off ssl initialization in libpq does
> >> > not work for this case?
> >>
> >> That initializes both libcrypto and libssl. The problem arises when
> >> l
On Tue, Feb 10, 2009 at 11:52 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> > Would someone remind me why turning off ssl initialization in libpq does
>> > not work for this case?
>>
>> That initializes both libcrypto and libssl. The problem arises when
>> libcrypto has been initialized but li
Robert Haas wrote:
> > Would someone remind me why turning off ssl initialization in libpq does
> > not work for this case?
>
> That initializes both libcrypto and libssl. The problem arises when
> libcrypto has been initialized but libssl has not.
So initialize ssl in your application? What is
Andrew Chernow wrote:
> Tom Lane wrote:
> >
> > If that's all you want, then PQinitSSLExtended is a perfectly good
> > answer.
> >
>
> How about PQinitCrypto(bool do_init), which would default to TRUE if
> never called. PQinitSSL already handles the SSL part, just need control
> over initia
Tom Lane wrote:
If that's all you want, then PQinitSSLExtended is a perfectly good
answer.
How about PQinitCrypto(bool do_init), which would default to TRUE if
never called. PQinitSSL already handles the SSL part, just need control
over initializing crypto.
--
Andrew Chernow
eSilo, LLC
> Would someone remind me why turning off ssl initialization in libpq does
> not work for this case?
That initializes both libcrypto and libssl. The problem arises when
libcrypto has been initialized but libssl has not.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
On Tue, Feb 10, 2009 at 11:14 AM, Tom Lane wrote:
> Robert Haas writes:
Well, you could create PQinitSSLExtended, but, as you say, the use
case is pretty narrow...
It would help if there were a PQgetLibraryVersion() function.
>>>
>>> Help how? There is nothing an app can do to wor
Magnus Hagander wrote:
> Merlin Moncure wrote:
> > On Tue, Feb 10, 2009 at 9:32 AM, Magnus Hagander
> > wrote:
> >>> How we worked around it:
> >>> We solved it by copying the SSL init sequence from fe-secure.c. Doesn't
> >>> seem like something that would change very often. So we
> >>> init_ou
Robert Haas writes:
>>> Well, you could create PQinitSSLExtended, but, as you say, the use
>>> case is pretty narrow...
>>> It would help if there were a PQgetLibraryVersion() function.
>>
>> Help how? There is nothing an app can do to work around the problem
>> AFAICS. Or if there were, we sho
1 - 100 of 109 matches
Mail list logo
