Lars Kanis wrote: > Am Montag, 22. Juni 2009 17:46:22 schrieben Sie: >> Lars Kanis <ka...@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/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
