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

[Adam Young]

On 06/30/2011 10:04 AM, John Dennis wrote:
> 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
>
Tested.  It fixes the install on an IPv6 only system.  Pushed to master.