OpenSSL Applink

Dave Page <dpage@postgresql.org> 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 sitting on the prior version until upstream fixes their
mistake.

regards, tom lane

Tom Lane wrote:

Dave Page <dpage@postgresql.org> 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 sitting on the prior version until upstream fixes their
mistake.

That was my reaction.

cheers

andrew

Tom Lane wrote:

Dave Page <dpage@postgresql.org> 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".

Agreed. Unless I've completely missed the point this does seem *really*
dumb.

I recommend sitting on the prior version until upstream fixes their
mistake.

Unfortunately from what I've seen it doesn't look like thats on their
agenda... and this has been around in release versions now since July 2005.

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 wager.

/D

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 wager.

So SSL works without this wart if you don't have a client cert?

cheers

andrew

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 client-side certs I'd wager.

So SSL works without this wart if you don't have a client cert?

Yep.

/D

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 relatively few people using client-side
certs I'd wager.

So SSL works without this wart if you don't have a client cert?

Yep.

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.

cheers

andrew

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
already using client certs (such as the pgAdmin user who brought this to
my attention).

:-(

/D

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 relatively few people using client-side certs I'd wager.

So SSL works without this wart if you don't have a client cert?

Yep.

According to the OpenSSL FAQ, the purpose of the applink is to allow
mixing release and debug versions or multi-threaded and
non-multithreaded versions of libraries:

http://www.openssl.org/support/faq.html#PROG2

How come we only bump into the crash with client certs?

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

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
which there are relatively few people using client-side certs I'd wager.

So SSL works without this wart if you don't have a client cert?

Yep.

According to the OpenSSL FAQ, the purpose of the applink is to allow
mixing release and debug versions or multi-threaded and
non-multithreaded versions of libraries:

http://www.openssl.org/support/faq.html#PROG2

Yeah - which in itself is a pita because with their 'workaround' we now
need to ensure we use a debug libpq with a debug pgadmin whereas
previously mixing 'n' matching wasn't an issue.

How come we only bump into the crash with client certs?

I assume it uses fopen() or one of the other functions it does a
GetProcAddress() on in that situation.

/D

Dave Page <dpage@postgresql.org> 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 agree, but thats not a nice solution for those
already using client certs (such as the pgAdmin user who brought this to
my attention).

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.

regards, tom lane

Tom Lane wrote:

Dave Page <dpage@postgresql.org> 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 agree, but thats not a nice solution for those
already using client certs (such as the pgAdmin user who brought this to
my attention).

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 any requirement. I've fixed pgAdmin for example
without any need to touch any Postgres code. If you don't want to
include the fix (which I can quite understand) it'll just mean that the
PG utilities won't work with client certs.

/D

On 9/28/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Dave Page <dpage@postgresql.org> 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 agree, but thats not a nice solution for those
already using client certs (such as the pgAdmin user who brought this to
my attention).

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.

Is it possible to use GNUTLS on Windows?

--
marko

Marko Kreen wrote:

On 9/28/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Dave Page <dpage@postgresql.org> 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 agree, but thats not a nice solution for those
already using client certs (such as the pgAdmin user who brought this to
my attention).

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.

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?

Regards, Dave

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

Dave Page <dpage@postgresql.org> 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 any requirement. I've fixed pgAdmin for example
without any need to touch any Postgres code.

Well, yeah, we are, as evidenced by the fact that you had to do
something to pgAdmin. Every other application that uses libpq would
also be facing source code changes to make it work.

Is there really no way to solve this within libpq?

regards, tom lane

Tom Lane wrote:

Dave Page <dpage@postgresql.org> 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 any requirement. I've fixed pgAdmin for example
without any need to touch any Postgres code.

Well, yeah, we are, as evidenced by the fact that you had to do
something to pgAdmin. Every other application that uses libpq would
also be facing source code changes to make it work.

Yes, but it's not us requiring it (except in as much as we provide some
level of SSL support) but the OpenSSL crew.

Is there really no way to solve this within libpq?

Including the applink code in libpq was the first think I tried but it
doesn't work (apparently because there is no way to ensure that any
random module containing it isn't unloaded before it's needed which
sorta makes sense).

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?

-----
But for new and evolving code [I suppose JNI would be rather
new and evolving] applink should not be preferable option, as there is a
way around it, namely avoid passing FILE* to BIO, but instead let BIO
open files for you, i.e. avoid BIO_new_fp and stick to BIO_new_filename.
Note that applink is engaged purely on demand and it doesn't have to be
present in application if application doesn't pass FILE* to BIO.
-----

/D

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. Working up a patch now...

/D

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 I've figured out a fix. Working up a patch now...

Patch attached.

It appears to work fine except that if the client certificate is
missing, instead of:

could not open certificate file "C:\Documents and
Settings\Dave\Application Data/postgresql/postgresql.crt": No such file
or directory

I get:

Error connecting to the server: SSL SYSCALL error: Operation would block
(0x00002733/10035)

for reasons that are not clear to me. Any ideas?

Regards, Dave

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 it out?

OK, I think I've figured out a fix. Working up a patch now...

Patch attached.

(sorry, been offline for the day)

Is there any reason not to just do this on *all* platforms, and get rid
of all the #ifdefs?

The new code actually seems cleaner to me than what we did before,
really... Since it lets OpenSSL do all the work for it.

It appears to work fine except that if the client certificate is
missing, instead of:

could not open certificate file "C:\Documents and
Settings\Dave\Application Data/postgresql/postgresql.crt": No such file
or directory

I get:

Error connecting to the server: SSL SYSCALL error: Operation would block
(0x00002733/10035)

for reasons that are not clear to me. Any ideas?

I wonder if it might be related to our socket/signal emulation stuff.
I'd be interested to see what happens with the same code on Unix, but
sorry, don't have time to test myself - will be offline again tomorrow :-(

//Magnus