From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Lars Kanis <kanis(at)comcard(dot)de>, Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #4869: No proper initialization of OpenSSL-Engine in libpq |
Date: | 2009-06-22 15:46:22 |
Message-ID: | 18926.1245685582@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Lars Kanis <kanis(at)comcard(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-06-22 16:05:12 | Re: BUG #4869: No proper initialization of OpenSSL-Engine in libpq |
Previous Message | Lars Kanis | 2009-06-22 15:03:54 | Re: BUG #4869: No proper initialization of OpenSSL-Engine in libpq |