Bug 689807
| Summary: | examples & doc do not set inet family when creating Socket or SSLSocket, will cause failures with ipv6 | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | John Dennis <jdennis> |
| Component: | python-nss | Assignee: | John Dennis <jdennis> |
| Status: | CLOSED ERRATA | QA Contact: | Aleš Mareček <amarecek> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.1 | CC: | amarecek, dcantrell, dpal, fnadge, jdennis, syeghiay |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | python-nss-0.11-3.el6 | Doc Type: | Bug Fix |
| Doc Text: |
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.
|
Story Points: | --- |
| Clone Of: | 689059 | Environment: | |
| Last Closed: | 2011-05-19 13:35:21 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 689059 | ||
| Bug Blocks: | |||
|
Description
John Dennis
2011-03-22 13:58:12 UTC
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 |