Bug 742914

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

M2Crypto.SSL.Connection mirrors Python's socket.socket, so it probably makes sense that it works with a specific address family, similarly to Python's socket.socket.

The handling of different address families would therefore belong into the caller, in this case M2Crypto.httpslib.HTTPSConnection.  This class is used by urlgrabber, so this change also fixes the test case in bug 739625 comment 4.

I have sent a patch upstream: https://bugzilla.osafoundation.org/show_bug.cgi?id=13044 .  Would this, instead of changing SSL.Connection as requested in this bug, work for you?

Most probably yes. I will have to test it, but we use urlgrabber. So if that patch fix this problem I really do not care if the fix is in urlgrabber of python or in m2crypto.

I will test the proposed patch and will let you know in few days.

(In reply to comment #4)
> Most probably yes. I will have to test it, but we use urlgrabber. So if that
> patch fix this problem I really do not care if the fix is in urlgrabber of
> python or in m2crypto.
> 
> I will test the proposed patch and will let you know in few days.

Thanks; note that urlgrabber (unless specifically configured otherwise) only uses M2Crypto in RHEL5, not in RHEL6.

(In reply to comment #4)
> Most probably yes. I will have to test it, but we use urlgrabber. So if that
> patch fix this problem I really do not care if the fix is in urlgrabber of
> python or in m2crypto.
> 
> I will test the proposed patch and will let you know in few days.

Hi Mirek, could you please confirm that the fix proposed in comment #3 resolves the issue for you also in RHEL 6? According to comments #0, #4 and #5 there is a risk this would resolve the issue only for RHEL 5, but does not work for RHEL 6.
Thanks!

Per bug #761596 comment 5, this patch fixes the issue for RHEL5 - so even if something different were necessary for RHEL6, we will need this patch in RHEL6 so that we don't introduce a RHEL5->RHEL6 regression.


Miroslav/Milan, can you confirm that no other changes will be necessary for RHEL6, please?

I can confirm, that the patch as shown in

    https://bugzilla.osafoundation.org/attachment.cgi?id=5743

is indeed a valid fix for the problem and reproducer described in

    https://bugzilla.osafoundation.org/show_bug.cgi?id=13044#c0

Nonetheless, this patch does not fix the problem described in the initial
comment of this bug report, i.e. the following reproducing script:

from M2Crypto.SSL.Connection import Connection
from M2Crypto import SSL
ctx = SSL.Context('sslv23')
a = Connection(ctx)
a.connect(('machine.in.ipv6.only.network.com', 443))


From Connection.__init__:
...
    self.socket = socket.socket(family, socket.SOCK_STREAM)
    self.socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)

(In reply to comment #8)
> Nonetheless, this patch does not fix the problem described in the initial
> comment of this bug report, i.e. the following reproducing script:
> 
> from M2Crypto.SSL.Connection import Connection
> from M2Crypto import SSL
> ctx = SSL.Context('sslv23')
> a = Connection(ctx)
> a.connect(('machine.in.ipv6.only.network.com', 443))

That is true, but is that relevant for Satellite?  See comment 3 for justification.

With
 export URLGRABBER_DEBUG=1,debug.txt
the spacealk-reposync just hang up, providing no useful output. Weird to me.

Created attachment 569445 [details]
urlgrabber test case - with changing the host name to point at an ipv4-only or ipv6-only address

I have:

* Grepped both spacewalk master and satellite master branch:
  - M2Crypto is used in client/tools/rhn-virtualization/virtualization/localvdsm.py , but this is not related to sync and I've been told by Jan to basically ignore it
  - M2Crypto is imported in client/rhel/yum-rhn-plugin/rhnplugin.py , but only to configure behavior / catch an exception, no direct use (but urlgrabber is used)
  - There is not a single direct instantiation of M2Crypto.SSL.Connection (as mentioned as a test case in comment#0 item 2) anywhere
  - The only use of urlgrabber is in the above-mentioned rhnplugin.py
* Tried to emulate yum's use of urlgrabber, as suggested in comment #14 (and bug #739625 comment #4) - see attachment, against both IPv4 and IPv6.  Both worked fine in RHEL6, and strace showed the M2Crypto is not used at all.

In summary, I can't see that M2Crypto is used in RHN Satellite running on RHEL6 at all, except for localvdsm.py.  The use of M2Crypto in localvdsm.py _does_ trigger a bug that would be fixed by the patch in comment#3.

So, to proceed, I think we need either

* A use case of RHN Satellite that is broken by M2Crypto, with a specific test case (to be able to fix it at all)

or

* An argument that localvdsm.py is important, along with a confirmation that there are no other M2Crypto-related problems with RHN Satellite on RHEL6.  (so that QE would accept the patch in comment#3)

msuchy, mzazrivec?

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0975.html