Lars Kanis wrote:
> Am Montag, 22. Juni 2009 17:46:22 schrieben Sie:
>> 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?
>
> The 3 different versions of the engine-code seems to me like this:
>
> 1. unpatched libpq
> engines aren't initialized (so some don't work), engines aren't freed at the
> end of connection (memory leak), no changes to PGconn
>
> 2. the initial patch I posted
> engines are initialized (so can work), engines aren't freed (memory leak), no
> changes to PGconn only in engine code path
>
> 3. the current patch
> engines are initialized, engines are freed, but problematic changes to PGconn
>
>
> Maybe version 2 (my initial patch) could be an alternative ?
Well, based on the "we don't know which different versions of openssl
it'll break with", version 2 is no better than version 3 :(
--
Magnus Hagander
Self: http://www.hagander.net/
Work: http://www.redpill-linpro.com/