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

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 th=
e=20
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=20
changes to PGconn only in engine code path

3. the current patch
engines are initialized, engines are freed, but problematic changes to PGco=
nn


Maybe version 2 (my initial patch) could be an alternative ?

regards
Lars Kanis