[Freeipa-devel] [PATCH] 811 Set the client auth callback after creating the SSL connection.

[John Dennis]

On 06/29/2011 04:58 PM, Rob Crittenden wrote:
> John Dennis wrote:
>> On 06/29/2011 03:08 PM, Rob Crittenden wrote:
>>> If we set the callback before calling connect() then if the connection
>>> tries a network family type and fails, it will try other family types.
>>> If this happens then the callback set on the first socket will be lost
>>> when a new socket is created. There is no way to query for the callback
>>> in an existing socket.
>>
>> I'm tempted to NAK this. In part because I don't really understand why
>> it works, but more because nsslib.py doesn't seem to be handling
>> addresses, sockets and connections correctly. At first glance it appears
>> to only create a new socket when switching families. I also don't
>> understand the logic behind the family code.
>
> It works like this:
>
> - We create an NSSConnection() with automatically gives us an SSL socket
> - We can add the callback here but if the connection fails a new socket
> will be created. There is no way I can see to find the callback call. I
> don't think this is even part of the C API so this isn't a deficiency in
> python-nss.
> - The connect() call just makes a network connection. NSS doesn't do
> anything until the first bit of data gets written to the socket so we
> can set the callback after the connection is completed.
>
> The default family is UNSPEC which is treated as IPv4.
>
>> But most importantly it seems to shutdown NSS every time you make a
>> connection. What happens when you want more than one simultaneous
>> connection?
>
> NSS is still very limited regarding having multiple NSS databases open
> at once. This code is meant to allow one to switch databases. Runnning
> within Apache (and our framework) the shutdown will fail because things
> in the database are in use, so this is a bit of a no-op. It is really
> just needed in the installer where things are done serially, so again no
> problem.
>
>>
>> Maybe we need to open a ticket to review nsslib.py.
>>
>
> A review of nsslib would't hurt, it has had a lot tacked on since
> inception, but we'd still have to deal with multiple databases, family
> failover, etc. I'd rather do that as a next step.
>
> rob

O.K. agree with all above.

ACK

-- 
John Dennis <jdennis at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/