Thread: OOPS! Bad libpq patch last time..
The patch submitted in my previous message was malformed. I've created a new one which is correct. SORRY for the trouble!! -- Jonathan Marks Systems Administrator, Production Systems Group Computing and Communication Services Office University of Illinois at Urbana-Champaign
Attachment
Jon Marks wrote: > The patch submitted in my previous message was malformed. > I've created a new one which is correct. SORRY for the > trouble!! Did we come to a concusion on this? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 diff -urN postgresql-7.1.3/src/interfaces/libpq/fe-connect.c postgresql-7.1.3-opensslfix/src/interfaces/libpq/fe-connect.c --- postgresql-7.1.3/src/interfaces/libpq/fe-connect.c Sat Mar 31 17:14:37 2001 +++ postgresql-7.1.3-opensslfix/src/interfaces/libpq/fe-connect.c Fri Jan 4 15:38:30 2002 @@ -19,6 +19,7 @@ #include <fcntl.h> #include <errno.h> #include <ctype.h> +#include <limits.h> #include "libpq-fe.h" #include "libpq-int.h" @@ -984,6 +985,14 @@ { if (!SSL_context) { + char f_randfile[PATH_MAX]; + + /* Need to seed PRNG, too! */ + if (RAND_egd(RAND_file_name(f_randfile, sizeof(f_randfile))) < 0) { + /* Not an EGD, so read and write it. */ + if (RAND_load_file(f_randfile, -1)) + RAND_write_file(f_randfile); + } SSL_load_error_strings(); SSL_library_init(); SSL_context = SSL_CTX_new(SSLv23_method()); diff -urN postgresql-7.1.3/src/interfaces/libpq/libpq-fe.h postgresql-7.1.3-opensslfix/src/interfaces/libpq/libpq-fe.h --- postgresql-7.1.3/src/interfaces/libpq/libpq-fe.h Wed Mar 21 22:01:27 2001 +++ postgresql-7.1.3-opensslfix/src/interfaces/libpq/libpq-fe.h Thu Jan 3 14:08:18 2002 @@ -27,6 +27,7 @@ #include "postgres_ext.h" #ifdef USE_SSL #include <openssl/ssl.h> +#include <openssl/rand.h> #endif /* Application-visible enum types */
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Did we come to a concusion on this?
My opinion is "wait and see if OpenSSL fixes their problem".
regards, tom lane
I can certainly understand your motivation, and OpenSSL does seem to want this cleared up in a new release. I'm nothing of a cryptographer, so I'm just placing my trust in the simple mechanisms supplied with the OpenSSL distribution. Still, it's kind of a shame that PostgresQL's client library can't, at present, be used with OpenSSL support on platforms not specifically patched or augmented to provide /dev/?random. For example, because my application specifically requires encryption, I'll need to continue to apply my modification to my own builds. Yet it's an OpenSSL issue, not a Postgres one. Would you feel it might be worth providing a compile-time option? Perhaps it may be one that's sensitive to the OpenSSL version, since it should be fixed eventually. It's kind of a workaround-style approach, but it does deliver more utility to users who might not know how to solve the problem otherwise. On the other hand, I do understand the want and need to keep the code base free of cruft-- it's not worth addressing every situation at the expense of maintainability. I'm able to address this locally, so my wheels aren't stuck in it. Again, many, many thanks to everybody whose effort and intellect has produced this fabulous product! On Sun, Jan 20, 2002 at 01:00:50AM -0500, Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Did we come to a concusion on this? > > My opinion is "wait and see if OpenSSL fixes their problem". > > regards, tom lane -- Jonathan Marks Systems Administrator, Production Systems Group Computing and Communication Services Office University of Illinois at Urbana-Champaign