Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> I guess you guys already found a solution that works, but there's yet
>> another function, "BIO *BIO_new_mem_buf(void *data, int len)", that we
>> could use. We could open and read the file all by ourselves into memory,
>> then cal
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I guess you guys already found a solution that works, but there's yet
> another function, "BIO *BIO_new_mem_buf(void *data, int len)", that we
> could use. We could open and read the file all by ourselves into memory,
> then call BIO_new_mem_buf and
Magnus Hagander wrote:
> Tom Lane wrote:
>> Magnus Hagander <[EMAIL PROTECTED]> writes:
>>> On Mon, Oct 01, 2007 at 10:51:01AM -0400, Tom Lane wrote:
I'd vote for backpatching, but only as far as 8.2, seeing that we're
abandoning the older branches on Windows.
>>> Should we backpatch a ve
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> On Mon, Oct 01, 2007 at 10:51:01AM -0400, Tom Lane wrote:
>>> I'd vote for backpatching, but only as far as 8.2, seeing that we're
>>> abandoning the older branches on Windows.
>
>> Should we backpatch a version of it to previous ver
Magnus Hagander <[EMAIL PROTECTED]> writes:
> On Mon, Oct 01, 2007 at 10:51:01AM -0400, Tom Lane wrote:
>> I'd vote for backpatching, but only as far as 8.2, seeing that we're
>> abandoning the older branches on Windows.
> Should we backpatch a version of it to previous versions that does just the
On Mon, Oct 01, 2007 at 10:51:01AM -0400, Tom Lane wrote:
> Dave Page <[EMAIL PROTECTED]> writes:
> > Magnus Hagander wrote:
> >> Should we backpatch all the stuff, or just the error push/pop thing?
>
> > All of it. Anyone building just libpq/psql using the old MSVC makefiles
> > will probably se
Dave Page <[EMAIL PROTECTED]> writes:
> Magnus Hagander wrote:
>> Should we backpatch all the stuff, or just the error push/pop thing?
> All of it. Anyone building just libpq/psql using the old MSVC makefiles
> will probably see the applink problem if they try to use client certs.
I'd vote for b
Magnus Hagander wrote:
Yes, that was the problem. Attached patch fixes the problem for me on
Windows and Linux using the error mark functionality. It seems a lot
cleaner than the other option.
>
Dave - can you test this one? Assuming that works, I'll go ahead and apply
it.
Yep, looks good her
On Mon, Oct 01, 2007 at 03:16:13PM +0200, Magnus Hagander wrote:
> On Mon, Oct 01, 2007 at 02:37:44PM +0200, Magnus Hagander wrote:
> > On Sat, Sep 29, 2007 at 09:01:16PM +0100, Dave Page wrote:
> > > Tom Lane wrote:
> > > > "Dave Page" <[EMAIL PROTECTED]> writes:
> > > >>> From: Tom Lane <[EMAIL P
On Mon, Oct 01, 2007 at 02:37:44PM +0200, Magnus Hagander wrote:
> On Sat, Sep 29, 2007 at 09:01:16PM +0100, Dave Page wrote:
> > Tom Lane wrote:
> > > "Dave Page" <[EMAIL PROTECTED]> writes:
> > >>> From: Tom Lane <[EMAIL PROTECTED]>
> > >>> ... It's not entirely clear whether BIO_new_fp() would a
On Sat, Sep 29, 2007 at 09:01:16PM +0100, Dave Page wrote:
> Tom Lane wrote:
> > "Dave Page" <[EMAIL PROTECTED]> writes:
> >>> From: Tom Lane <[EMAIL PROTECTED]>
> >>> ... It's not entirely clear whether BIO_new_fp() would avoid the
> >>> problematic calls, but it doesn't look like it'd be hard to
Tom Lane wrote:
> "Dave Page" <[EMAIL PROTECTED]> writes:
>>> From: Tom Lane <[EMAIL PROTECTED]>
>>> ... It's not entirely clear whether BIO_new_fp() would avoid the
>>> problematic calls, but it doesn't look like it'd be hard to try.
>
>> The last version of the patch I posted uses BIO_new_file()
"Dave Page" <[EMAIL PROTECTED]> writes:
>> From: Tom Lane <[EMAIL PROTECTED]>
>> ... It's not entirely clear whether BIO_new_fp() would avoid the
>> problematic calls, but it doesn't look like it'd be hard to try.
> The last version of the patch I posted uses BIO_new_file() in all cases, and
> (f
> --- Original Message ---
> From: Tom Lane <[EMAIL PROTECTED]>
> To: Dave Page <[EMAIL PROTECTED]>
> Sent: 29/09/07, 01:28:09
> Subject: Re: [PATCHES] OpenSSL Applink
>
> I concur with Magnus that it'll be better if there's not two code pat
Dave Page <[EMAIL PROTECTED]> writes:
> Magnus Hagander wrote:
>> Is there any reason not to just do this on *all* platforms, and get rid
>> of all the #ifdefs?
> Yes, (see the comment in the code). We stat the private key on *nix to
> ensure it hasn't changed underneath us which can't be done usi
Dave Page wrote:
> Magnus Hagander wrote:
>> Hrrm. Obviously, I need to go sleep now. Sorry about that.
>>
>> But it'd be nice to get rid of all those #ifdef blocks..
>
> See the attached revision. This is untested as I don't have a linux box
> to hand, but I believe it's right.
Ignore that - I m
Magnus Hagander wrote:
> Hrrm. Obviously, I need to go sleep now. Sorry about that.
>
> But it'd be nice to get rid of all those #ifdef blocks..
See the attached revision. This is untested as I don't have a linux box
to hand, but I believe it's right.
/D
Index: src/interfaces/libpq/fe-secure.c
Dave Page wrote:
> Magnus Hagander wrote:
>> Dave Page wrote:
>>> Dave Page wrote:
Dave Page wrote:
> I did stumble across this text on a mailing list in response to someone
> with a similar problem in some JNI code. I know little of the OpenSSL
> API, but perhaps it rings bells wi
Magnus Hagander wrote:
> Dave Page wrote:
>> Dave Page wrote:
>>> Dave Page wrote:
I did stumble across this text on a mailing list in response to someone
with a similar problem in some JNI code. I know little of the OpenSSL
API, but perhaps it rings bells with you before I spend my
Dave Page wrote:
> Dave Page wrote:
>> Dave Page wrote:
>>> I did stumble across this text on a mailing list in response to someone
>>> with a similar problem in some JNI code. I know little of the OpenSSL
>>> API, but perhaps it rings bells with you before I spend my evening
>>> trying to figure i
Dave Page wrote:
> Dave Page wrote:
>> I did stumble across this text on a mailing list in response to someone
>> with a similar problem in some JNI code. I know little of the OpenSSL
>> API, but perhaps it rings bells with you before I spend my evening
>> trying to figure it out?
>
> OK, I think
Dave Page wrote:
> I did stumble across this text on a mailing list in response to someone
> with a similar problem in some JNI code. I know little of the OpenSSL
> API, but perhaps it rings bells with you before I spend my evening
> trying to figure it out?
OK, I think I've figured out a fix. Wor
Tom Lane wrote:
Dave Page <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Doesn't really matter. Even if we were willing to hack our own client
apps like that (which I'm not), we can *not* transfer such a requirement
onto every libpq-using application. It's just not acceptable.
*We're* not tran
Dave Page <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Doesn't really matter. Even if we were willing to hack our own client
>> apps like that (which I'm not), we can *not* transfer such a requirement
>> onto every libpq-using application. It's just not acceptable.
> *We're* not transfering
Dave Page wrote:
Is it possible to use GNUTLS on Windows?
No, I don't think so. I didn't think we accepted Martijn's(?) patch
for it anyway?
This mess might make that worth revisiting, if it can be used on
Windows. See http://josefsson.org/gnutls4win/
cheers
andrew
--
Marko Kreen wrote:
On 9/28/07, Tom Lane <[EMAIL PROTECTED]> wrote:
Dave Page <[EMAIL PROTECTED]> writes:
Andrew Dunstan wrote:
Then I think I'd rather disable use of client certs for the offending
openssl versions in libpq, or let the apps die and refer the customers
to the openssl people to l
On 9/28/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> Dave Page <[EMAIL PROTECTED]> writes:
> > Andrew Dunstan wrote:
> >> Then I think I'd rather disable use of client certs for the offending
> >> openssl versions in libpq, or let the apps die and refer the customers
> >> to the openssl people to lobb
Tom Lane wrote:
Dave Page <[EMAIL PROTECTED]> writes:
Andrew Dunstan wrote:
Then I think I'd rather disable use of client certs for the offending
openssl versions in libpq, or let the apps die and refer the customers
to the openssl people to lobby them for a sane solution.
If this were 8.0 I
Dave Page <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> Then I think I'd rather disable use of client certs for the offending
>> openssl versions in libpq, or let the apps die and refer the customers
>> to the openssl people to lobby them for a sane solution.
> If this were 8.0 I'd agre
Heikki Linnakangas wrote:
Dave Page wrote:
Andrew Dunstan wrote:
Dave Page wrote:
I believe we just didn't notice it until now because the older Mingw
builds use the MSVC 6.0 runtimes which just happened to be compatible
with the OpenSSL binary builds (we're now using 8.0), in addition to
whic
Dave Page wrote:
> Andrew Dunstan wrote:
>> Dave Page wrote:
>>> I believe we just didn't notice it until now because the older Mingw
>>> builds use the MSVC 6.0 runtimes which just happened to be compatible
>>> with the OpenSSL binary builds (we're now using 8.0), in addition to
>>> which there ar
Andrew Dunstan wrote:
Then I think I'd rather disable use of client certs for the offending
openssl versions in libpq, or let the apps die and refer the customers
to the openssl people to lobby them for a sane solution.
If this were 8.0 I'd agree, but thats not a nice solution for those
alrea
Dave Page wrote:
Andrew Dunstan wrote:
Dave Page wrote:
I believe we just didn't notice it until now because the older Mingw
builds use the MSVC 6.0 runtimes which just happened to be
compatible with the OpenSSL binary builds (we're now using 8.0), in
addition to which there are relativ
Andrew Dunstan wrote:
Dave Page wrote:
I believe we just didn't notice it until now because the older Mingw
builds use the MSVC 6.0 runtimes which just happened to be compatible
with the OpenSSL binary builds (we're now using 8.0), in addition to
which there are relatively few people using
Dave Page wrote:
I believe we just didn't notice it until now because the older Mingw
builds use the MSVC 6.0 runtimes which just happened to be compatible
with the OpenSSL binary builds (we're now using 8.0), in addition to
which there are relatively few people using client-side certs I'd
Tom Lane wrote:
Dave Page <[EMAIL PROTECTED]> writes:
The server doesn't seem to be affected, but the attached patch fixes the
problem for the client apps. Unfortunately it must be included in the
app itself, and not libpq.
This is pretty much in the category of "they've got to be kidding".
Tom Lane wrote:
Dave Page <[EMAIL PROTECTED]> writes:
The server doesn't seem to be affected, but the attached patch fixes the
problem for the client apps. Unfortunately it must be included in the
app itself, and not libpq.
This is pretty much in the category of "they've got to be ki
Dave Page <[EMAIL PROTECTED]> writes:
> The server doesn't seem to be affected, but the attached patch fixes the
> problem for the client apps. Unfortunately it must be included in the
> app itself, and not libpq.
This is pretty much in the category of "they've got to be kidding".
I recommend sitt
On Windows the OpenSSL guys have included code with 0.9.8 and above to
allow OpenSSL to work correctly regardless of the MSVC runtime libraries
that have been used with the host application. This has become noticable
with the MSVC++ build in which any client apps that connect using libpq
with a cli
39 matches
Mail list logo
