Bug 689059 - examples & doc do not set inet family when creating Socket or SSLSocket, will cause failures with ipv6
Summary: examples & doc do not set inet family when creating Socket or SSLSocket, will...
Alias: None
Product: Fedora
Classification: Fedora
Component: python-nss
Version: 15
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: John Dennis
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 689807
TreeView+ depends on / blocked
Reported: 2011-03-19 00:36 UTC by John Dennis
Modified: 2013-01-10 06:32 UTC (History)
2 users (show)

Fixed In Version: python-nss-0.11-2.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 689807 (view as bug list)
Last Closed: 2011-06-29 22:01:15 UTC

Attachments (Terms of Use)

Description John Dennis 2011-03-19 00:36:36 UTC
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.

Comment 1 John Dennis 2011-03-22 17:40:40 UTC
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.

Comment 2 Fedora Update System 2011-03-22 21:53:13 UTC
python-nss-0.11-2.fc15 has been submitted as an update for Fedora 15.

Comment 3 Fedora Update System 2011-06-29 22:01:03 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.