test_ssl tests calling connect_ex don't handle unreachable servers properly:
"""
test_ssl
Resource 'svn.python.org' is not available
Resource 'svn.python.org' is not available
test test_ssl failed -- Traceback (most recent call last):
  File "/srv/buildbot/buildarea/2.7.bolen-ubuntu/build/Lib/test/test_ssl.py", line 246, in test_connect_ex
    self.assertEqual(0, s.connect_ex(("svn.python.org", 443)))
AssertionError: 0 != None
"""

support.transient doesn't help here since no exception is raised.
Note that I'm not sure that connect_ex returning None is normal in the first place...

There's a related failure on OpenBSD/NetBSD  buildbots:
"""
test_timeout_connect_ex (test.test_ssl.NetworkedTests) ... ok

======================================================================
ERROR: test_non_blocking_connect_ex (test.test_ssl.NetworkedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/3.x.snakebite-openbsd51-amd64-1/build/Lib/test/test_ssl.py", line 685, in test_non_blocking_connect_ex
    select.select([], [s], [], 5.0)
OSError: [Errno 22] Invalid argument
"""

I guess that connect() can't succeed because of an unreachable host/connection refused, and the subsequent select() fails with EINVAL. This is most likely a kernel bug, select should report the socket as ready for write (one could then use getsockopt() to find the actual error).

> support.transient doesn't help here since no exception is raised

An exception can still be raised in do_handshake(), which is called when the connection succeeds. But, yes, it's otherwise useless.

> Note that I'm not sure that connect_ex returning None is normal in the 
> first place

It is not. The 2.7 implementation currently calls socket.connect() and catches socket errors, while the 3.2 implementation directly calls socket.connect_ex(). This means the 2.7 implementation will unwillingly catch name resolution errors, and other issues:

>>> socket.socket().connect_ex(("svnn.python.org", 443))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/cpython/27/Lib/socket.py", line 224, in meth
    return getattr(self._sock,name)(*args)
socket.gaierror: [Errno -5] No address associated with hostname
>>> ssl.wrap_socket(socket.socket()).connect_ex(("svnn.python.org", 443))
-5

I will backport the 3.2 implementation of connect_ex() in order to fix this inconsistency. Unfortunately there is no easy way to test for it.

Is this still an issue?

Does the backport mentioned in msg178404 still need doing, can this be closed as "out of date" or "won't fix" or what?

It's probably out of date :)

Please reopen if you still see this issue.