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

[Rob Crittenden]

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