Re: BUG #4869: No proper initialization of OpenSSL-Engine in libpq - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #4869: No proper initialization of OpenSSL-Engine in libpq
Date
Msg-id 18926.1245685582@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #4869: No proper initialization of OpenSSL-Engine in libpq  (Lars Kanis <kanis@comcard.de>)
Responses Re: BUG #4869: No proper initialization of OpenSSL-Engine in libpq  (Magnus Hagander <magnus@hagander.net>)
Re: BUG #4869: No proper initialization of OpenSSL-Engine in libpq  (Lars Kanis <kanis@comcard.de>)
List pgsql-bugs
Lars Kanis <kanis@comcard.de> writes:
> Am Montag, 22. Juni 2009 16:38:32 schrieben Sie:
>> Tom Lane wrote:
>>> IIUC this is a pre-existing bug/limitation in an extremely seldom-used
>>> feature that we don't have any very good way to test.  So I'm not really
>>> excited about trying to fix it in RC at all.  The chances of breaking
>>> something seem much higher than the usefulness of the fix would warrant.

>> I think we'll see this feature used a lot more now, since we support
>> client certificate authentication. I bet that's the reason why Lars is
>> using it now, but wasn't using it before. Correct, Lars?

> That's right. Because clientside crypto engines and proper certificate
> authentication is supported now, I would like to use a strong smartcard-based
> login in our high security environment.

OK, but I'm still worried about making a change of this sort (ie,
modifying our interface to code that we don't control) so late in the
release cycle.  It seems like there is large potential for failure in
contexts other than the one or two you are going to be able to test
right now.  Is there anything that can be done to reduce the risk?

            regards, tom lane

pgsql-bugs by date:

Previous
From: Lars Kanis
Date:
Subject: Re: BUG #4869: No proper initialization of OpenSSL-Engine in libpq
Next
From: Tom Lane
Date:
Subject: Re: BUG #4869: No proper initialization of OpenSSL-Engine in libpq