Re: BUG #4869: No proper initialization of OpenSSL-Engine in libpq

Am Montag, 22. Juni 2009 17:46:22 schrieben Sie:
> 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?

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 ?

regards
Lars Kanis