DEP8 failure: deprecation warning on stderr

[Andreas Hasenack]

stunnel currently fails dep8 tests because it emits this warning in stderr:

/tmp/autopkgtest.Zk8pzq/build.poD/src/debian/tests/python/struntime/__main__.py:437: DeprecationWarning: ssl.PROTOCOL_TLS is deprecated

Indeed, PROTOCOL_TLS was deprecated in python 3.10, and the code should use either PROTOCOL_TLS_CLIENT or PROTOCOL_TLS_SERVER, depending on what it is doing.

The correct substitution in this code is to use PROTOCOL_TLS_CLIENT, but that enabled hostname verification, which PROTOCOL_TLS didn't before:

    ssl.PROTOCOL_TLS_CLIENT

    Auto-negotiate the highest protocol version that both the client and server support, and configure the context client-side connections. The protocol enables CERT_REQUIRED and check_hostname by default.

This makes the test fail when it uses the ip (127.0.0.1) to connect to localhost instead of "localhost", because the test certificate has a CN of "localhost":

    Failed to connect to 127.0.0.1:6503: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: IP address mismatch, certificate is not valid for '127.0.0.1'. (_ssl.c:1129)

Alternatives:
- allow stderr in the test
- use PROTOCOL_TLS_CLIENT but also set check_hostname in the context to False, mimicking what we had before with just PROTOCOL_TLS
- add IP:127.0.0.1 to subjectAltName in the test certificate (untested)

[Andreas Hasenack (ahasenack)]

uploaded

[Launchpad Janitor (janitor)]

This bug was fixed in the package stunnel4 - 3:5.60+dfsg-1ubuntu1

---------------
stunnel4 (3:5.60+dfsg-1ubuntu1) jammy; urgency=medium

  * Fix DEP8 failure (LP: #1959615):
    - d/t/python/struntime/__main__.py: PROTOCOL_TLS is deprecated in
      python 3.9
    - d/t/certs/{README.txt,*.pem}: regenerate test certificate with a
      subjectAltName of IP:127.0.0.1, since PROTOCOL_TLS_CLIENT enables
      check_hosthame and one of the tests connects to 127.0.0.1
  * d/p/07-ssl_op_bit-is-reserved patch: don't use a symbol that's
    reserved in OpenSSL 3 (LP: #1959588)

 -- Andreas Hasenack <email address hidden> Mon, 31 Jan 2022 20:33:12 +0000