A patch for the ssl_example program was prepared by myself and then tested by Ales Marecek in QE as part of the RHEL 6.1 QE testing. Ales reports success. I would like to patch and rebuild. Denise Dumas has indicated this is an appropriate fix to introduce during this point in the cycle.

I can confirm that new version of ssl_example.py works properly.

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.

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
This field is the basis of the errata or release note for this bug. It can also be used for change logs.

The Technical Note template, known as CCFR, is as follows:

Cause
    What actions or circumstances cause this bug to present.
Consequence
    What happens when the bug presents.
Fix
    What was done to fix the bug.

Cause:

Socket constructor defaults to using IPv4.

Consequence:

If the Socket object is later associated with an IPv6 NetworkAddress object a mismatch will occur and an exception will be thrown.

Fix:

Always create the Socket object using the family property of the NetworkAddress object, do not allow Socket object's family to assume a default value.

Result:

Successful socket operation with IPv6.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0607.html