Re: PQinitSSL broken in some use casesf

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PQinitSSL broken in some use casesf
Date: 2009-03-28 19:17:10
Message-ID: 200903281917.n2SJHAE13917@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.
>
> I think a proper way to document this issue would be something like this:
>
> "
> If your application initializes libcrypto, but not libssl, you must
> not call PQinitSSL(1) because it will overwrite your libcrypto
> initialization. In order to safely use libpq in your application, you
> must include ssl headers and call the following functions:
>
> #include <openssl/ssl.h>
> #include <openssl/conf.h>
>
> OPENSSL_config(NULL);
> SSL_library_init();
> SSL_load_error_strings();
> PQinitSSL(0);
>
> In order to initialize libpq properly for SSL connections.
> "
>
> > 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-case so it is hard to suggest a new libpq function.
>
> This feature when discussed at the time was not enough _by itself_ to
> support a PQinit feature (I agree with this reasoning), but surely
> should be considered as valid supporting evidence that a library
> initialization feature is useful. IOW, the whole of the argument is
> equal to the sum of its parts. (yes, we have an agenda here: we were
> not happy that our events patch could not establish behavior at
> library initialization time).

Well, we are not the "Make Merlin Happy club". ;-)

Making usable software requires adjustments on everyone's part. I don't
think we have enough demand to hardcode those details in our
documentation.

Personally, I feel adding #defines for PQinitSSL is the right approach,
and I think that gives enough checks at compile time, but it doesn't
guard against cases where the application is built against one version
of libpq but is run against an older version, which I think can happen.

My personal opinion is that adding #defines to PQinitSSL() is the right
level of fix, and if we ever implement a libpq init mechanism we can
convert PGinitSSL to a macro. I am attaching a sample patch for
feedback.

However, as I mentioned above, this is not the "Make Bruce Happy club"
either so I need support from other developers that this is the right
fix.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Attachment Content-Type Size
/pgpatches/ssl text/x-diff 4.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2009-03-28 19:18:30 Re: pg_migrator progress
Previous Message Josh Berkus 2009-03-28 19:10:12 Re: Should SET ROLE inherit config params?