The Socket and SSLSocket objects take an optional family parameter, it defaults to PR_AF_INET (e.g. ipv4). If the NetworkAddress object subsequently used with the socket object specifies a ipv6 address then an error will occur because of the mismatch between the socket family and the address family. The examples installed in the documentation subpackage and the API documentation fail to force the family when a socket object is created. For ipv4 this is not a problem because the socket constructor defaults to AF_INET, but for ipv6 addresses the family must be explicitly set to PR_AF_INET6 (e.g. net_addr.family) Perhaps the optional family parameter to Socket and SSLSocket shouldn't be optional with a default of PR_AF_INET, but that is an api change. At a minimum the examples and documentation should be explicit with regards to the family.
Pasting the contents of an email discussing the issue and proposed patch so that the information is captured here. -------------------------------------------------------------------------- Socket objects must be created to match the intended address family (e.g PR_AF_*). NetworkAddress objects have an implicit address family (e.g. IPv4 addresses are PR_AF_INET and IPv6 addresses are PR_AF_INET6). Sockets are bound with a NetworkAddress object during connect, bind, etc. If the address family of a socket does not match the address family of a NetworkAddress object you will sometimes get low level errors and in some cases you won't get an error at all but just incorrect behavior (e.g. a IPv4 binding to an IPv6 "any" address actually binds to a IPv4 address yet it reports it's listening on IPv6). The constructor for Socket objects would default it's family parameter to IPv4 if it wasn't explicitly specified. Thus if you accept the defaults when creating a Socket but iterate over the addresses returned by AddrInfo and that address is IPv6 you'll end up with a address family mismatch between the Socket object and the address it connects or binds to. The fix is simple, when creating a Socket object always specify the family of the NetworkAddress object you intend to use the socket with. The example programs and the example code snippets in the API documentation failed to explicitly set the family parameter during Socket construction. Just to be clear, the problem is only in the examples and documentation, the library itself does not have a problem, although I plan on adding a check in the library to prevent a mismatch from being accepted (see below). The update for the package will include: * Fix each place in the example/test code which allows a Socket object to default to IPv4 to have an explicit family parameter. * Fix each code snippet in the API doc in a similar manner. * Update the Socket entry points which accept a NetworkAddress object to validate the address family in the NetworkAddress family matches the socket object, otherwise raise an exception. In other words do not allow users to make this mistake. If they do you'll get a very specific error explaining the coding mistake. * Mark the use of a default IPv4 family in Socket objects as being deprecated. A future version of the library will demand you explicitly specify the address family when creating a Socket object. Why? The assumption that IPv4 will be used is no longer a valid assumption.
python-nss-0.11-2.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/python-nss-0.11-2.fc15
python-nss-0.11-2.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.