Skip to content

TestStandardProfileHTTPSHub error after upgrade of OpenSSL to 1.1.0 #5460

Closed
Closed
TestStandardProfileHTTPSHub error after upgrade of OpenSSL to 1.1.0#5460
Assignees
astrofrog
Labels
sampvo

Description

@olebole
olebole
opened on Nov 4, 2016

With the latest release on Python (taken from 20161103 according to the Changelog), TestStandardProfileHTTPSHub.test_main gives an error on setup:

__________ ERROR at setup of TestStandardProfileHTTPSHub.test_main ____________

self = <astropy.vo.samp.tests.test_standard_profile.TestStandardProfileHTTPSHub object at 0x7f69515e9d90>
method = <bound method TestStandardProfileHTTPSHub.test_main of <astropy.vo.samp.tests.test_standard_profile.TestStandardProfileHTTPSHub object at 0x7f69515e9d90>>

    def setup_method(self, method):
        self.tmpdir = tempfile.mkdtemp()
        self.hub = SAMPHubServer(web_profile=False, mode='multiple', pool_size=1,
                                 **self.hub_init_kwargs)
        self.hub.start()
        self.client1 = SAMPIntegratedClient(**self.client_init_kwargs)
>       self.client1.connect(hub=self.hub, pool_size=1, **self.client_connect_kwargs)

/usr/lib/python2.7/dist-packages/astropy/vo/samp/tests/test_standard_profile.py:51: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/usr/lib/python2.7/dist-packages/astropy/vo/samp/integrated_client.py:184: in connect
    cert_reqs, ca_certs, ssl_version, pool_size)
/usr/lib/python2.7/dist-packages/astropy/vo/samp/hub_proxy.py:128: in connect
    self.ping()
/usr/lib/python2.7/dist-packages/astropy/vo/samp/hub_proxy.py:165: in ping
    return self._samp_hub.ping()
/usr/lib/python2.7/dist-packages/astropy/vo/samp/utils.py:65: in __call__
    response = function(*args, **kwrds)
/usr/lib/python2.7/xmlrpclib.py:1243: in __call__
    return self.__send(self.__name, args)
[...]
/usr/lib/python2.7/httplib.py:844: in send
    self.connect()
/usr/lib/python2.7/dist-packages/astropy/vo/samp/ssl_utils.py:62: in connect
    sslconn = ssl.wrap_socket(sock, **kwargs)
/usr/lib/python2.7/ssl.py:943: in wrap_socket
    ciphers=ciphers)
/usr/lib/python2.7/ssl.py:611: in __init__
    self.do_handshake()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = <ssl.SSLSocket object at 0x7f69503f8d70>, block = False

    def do_handshake(self, block=False):
        """Perform a TLS/SSL handshake."""
        self._check_connected()
        timeout = self.gettimeout()
        try:
            if timeout == 0.0 and block:
                self.settimeout(None)
>           self._sslobj.do_handshake()
E           error: [Errno 104] Connection reset by peer

/usr/lib/python2.7/ssl.py:840: error

where the captures stdout also just shows a

INFO: Hub set for using SSL. [astropy.vo.samp.hub]
INFO: Hub started [astropy.vo.samp.hub]
________ ERROR at setup of TestStandardProfileHTTPSHubClient.test_main _________

self = <astropy.vo.samp.tests.test_standard_profile.TestStandardProfileHTTPSHubClient object at 0x7f6950413490>
method = <bound method TestStandardProfileHTTPSHubClient.test_main of <astropy.vo.samp....t_standard_profile.TestStandardProfileHTTPSHubClient object at 0x7f6950413490>>

    def setup_method(self, method):
        self.tmpdir = tempfile.mkdtemp()
        self.hub = SAMPHubServer(web_profile=False, mode='multiple', pool_size=1,
                                 **self.hub_init_kwargs)
        self.hub.start()
    
        self.client1 = SAMPIntegratedClient(**self.client_init_kwargs)
>       self.client1.connect(hub=self.hub, pool_size=1, **self.client_connect_kwargs)

/usr/lib/python2.7/dist-packages/astropy/vo/samp/tests/test_standard_profile.py:51: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/usr/lib/python2.7/dist-packages/astropy/vo/samp/integrated_client.py:184: in connect
    cert_reqs, ca_certs, ssl_version, pool_size)
/usr/lib/python2.7/dist-packages/astropy/vo/samp/hub_proxy.py:128: in connect
    self.ping()
/usr/lib/python2.7/dist-packages/astropy/vo/samp/hub_proxy.py:165: in ping
    return self._samp_hub.ping()
/usr/lib/python2.7/dist-packages/astropy/vo/samp/utils.py:65: in __call__
    response = function(*args, **kwrds)
/usr/lib/python2.7/xmlrpclib.py:1243: in __call__
    return self.__send(self.__name, args)
[...]
/usr/lib/python2.7/httplib.py:844: in send
    self.connect()
/usr/lib/python2.7/dist-packages/astropy/vo/samp/ssl_utils.py:62: in connect
    sslconn = ssl.wrap_socket(sock, **kwargs)
/usr/lib/python2.7/ssl.py:943: in wrap_socket
    ciphers=ciphers)
/usr/lib/python2.7/ssl.py:611: in __init__
    self.do_handshake()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = <ssl.SSLSocket object at 0x7f6950491b18>, block = False

    def do_handshake(self, block=False):
        """Perform a TLS/SSL handshake."""
        self._check_connected()
        timeout = self.gettimeout()
        try:
            if timeout == 0.0 and block:
                self.settimeout(None)
>           self._sslobj.do_handshake()
E           error: [Errno 104] Connection reset by peer

/usr/lib/python2.7/ssl.py:840: error

On Python-3.5, the behaviour is the same.

Main change in Python was the use of OpenSSL 1.0. The Python-2.7 changelog shows a few more SSL related entries:

  • Issue #27691: Fix ssl module's parsing of GEN_RID subject alternative name fields in X.509 certs.
  • Issue #27850: Remove 3DES from ssl module's default cipher list to counter measure sweet32 attack (CVE-2016-2183).
  • Issue #27766: Add ChaCha20 Poly1305 to ssl module's default ciper list. (Required OpenSSL 1.1.0 or LibreSSL).
  • Issue #26470: Port ssl and hashlib module to OpenSSL 1.1.0. Closes: #835793.

Full test log here

Activity

  1. pllim
    added
    vo
    samp
    on Nov 4, 2016

  2. eteq commented on Dec 13, 2016

    @eteq
    eteq
    on Dec 13, 2016
    Member

    @pllim - any ideas here? The thing I really don't understand is why this is only vo, when it seems fairly generic...

  3. olebole commented on Dec 13, 2016

    @olebole
    olebole
    on Dec 13, 2016
    MemberAuthor

    @eteq I run only non-remote tests; maybe this is the only one which starts its own server instead of connecting to remote?

  4. pllim commented on Dec 13, 2016

    @pllim
    pllim
    on Dec 13, 2016
    Member

    Sorry, samp is @astrofrog, not me.

  5. eteq
    added this to the v1.3.0 milestone on Dec 16, 2016
  6. astrofrog
    self-assigned this
    on Dec 16, 2016

  7. astrofrog commented on Dec 23, 2016

    @astrofrog
    astrofrog
    on Dec 23, 2016
    Member

    I won't have any time in the near future to work on this, but just in case anyone wants to take a look at this, there's now a bounty on this 😄 (as an experiment)

    BountySource

  8. eteq
    modified the milestones: v1.3.0, v1.3.1 on Jan 4, 2017

  9. mhvk commented on Jan 6, 2017

    @mhvk
    mhvk
    on Jan 6, 2017
    Contributor

    Not sure I can help here, but it definitely is annoying as on my (Debian) machine I now always have this test failing. Could it be as simple as the test using a weak form of encryption that no longer is supported?

  10. bsipocz
    removed this from the v1.3.1 milestone on Mar 4, 2017

  11. mhvk commented on Apr 21, 2017

    @mhvk
    mhvk
    on Apr 21, 2017
    Contributor

    @astrofrog - any chance you can have a look at this? It is very annoying to have the test suite broken on recent python versions.

    I guess more generally there is a problem for vo.samp that it seems to have a high bus factor...

  12. mhvk commented on May 17, 2017

    @mhvk
    mhvk
    on May 17, 2017
    Contributor

    Pending an actual solution, I made a PR (#6091) that disables the relevant vo.samp tests for openssl > 1.1; it is too unpleasant to have tests always fail with an up-to-date python installation. I wonder if we should even support having a VO server in astropy core; it seems more logical in an affiliated package.

  13. pllim commented on May 17, 2017

    @pllim
    pllim
    on May 17, 2017
    Member

    I already moved Cone Search over to Astroquery, SAMP is the only thing remaining in astropy.vo.

  14. mhvk commented on May 17, 2017

    @mhvk
    mhvk
    on May 17, 2017
    Contributor

    Hmm, given that, my suggestion actually may make sense....

  15. pllim commented on Jun 12, 2017

    @pllim
    pllim
    on Jun 12, 2017
    Member

    @mhvk , or at least move it to under astropy.io, like astropy.io.vosamp (we already have astropy.io.votable)? And then, we can get rid of astropy.vo altogether... Too controversial?

  16. astrofrog commented on Jun 12, 2017

    @astrofrog
    astrofrog
    on Jun 12, 2017
    Member

    I would be fine with splitting this back out into an affiliated package if people would prefer that. Maybe it would be good to first get a show of hands on the list of who is using it?

  17. mhvk commented on Jun 12, 2017

    @mhvk
    mhvk
    on Jun 12, 2017
    Contributor

    To me, it makes sense to have this as an affiliated package, as it seems running one's own VO server is a bit overly specialized for the core. But I agree we should ping the mailing list.

  18. bsipocz commented on Jun 12, 2017

    @bsipocz
    bsipocz
    on Jun 12, 2017
    Member

    If split is going to happen, can we make a deprecation in time for 2.0, so that actual removal can happen in 3.0?

  19. pllim commented on Jun 12, 2017

    @pllim
    pllim
    on Jun 12, 2017
    Member

    can we make a deprecation in time for 2.0

    Is it alright to deprecate something that has no real replacement yet? I doubt the split is going to happen by Friday. How about a "pending deprecation" warning instead?

  20. bsipocz commented on Jun 12, 2017

    @bsipocz
    bsipocz
    on Jun 12, 2017
    Member

    Well, technically the replacement need to be in place when the release is out, in ~3 weeks time, not by Friday :)

  21. pllim commented on Jun 12, 2017

    @pllim
    pllim
    on Jun 12, 2017
    Member

    Well, this discussion is getting very out of topic here, let's discuss more at #6187.

  22. astrofrog
    closed this as completedin #6201on Jun 15, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

sampvo

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions