[SRU] OpenSSL 1.1.1 to 18.04 LTS

[Dimitri John Ledkov]

[Impact]

 * OpenSSL 1.1.1 is an LTS release upstream, which will continue to receive security support for much longer than 1.1.0 series will.

 * OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to be rapidly adopted due to increased set of supported hashes & algoes, as well as improved handshake [re-]negotiation.

 * OpenSSL 1.1.1 comes with improved hw-acceleration capabilities.

 * OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some software is sensitive to the negotiation handshake and may either need patches/improvements or clamp-down to maximum v1.2.

[Test Case]

 * Rebuild all reverse dependencies

 * Execute autopkg tests for all of them

 * Clamp down to TLS v1.2 software that does not support TLS v1.3 (e.g. mongodb)

 * Backport TLS v1.3 support patches, where applicable

[Test cases for the python updates]

python3.7 is a preview in bionic as a non-supported/non-default
version of python3. Passing it's own autopkgtests is sufficient
validation for python3.7. It includes a point release update, with
OpenSSL 1.1.1 compat and features.

python3.6 not only has OpenSSL 1.1.1 compat and features patches, but
also includes a point release update to 3.6.8. It has been part of the
full-archive rebuild and regression analysis. Autopkgtests were
triggered for python3.6 and python3-defaults with regressions already
fixed in the individual packages as appropriate.

python2.7 has the update from .15~rc1 to .15 final, with OpenSSL 1.1.1
compat only. It has been part of the full-archive rebuild and
regression analysis. Autopkgtests were triggered for python2.7 and
python-defaults with regressions already fixed in the individual
packages as appropriate.

The archive rebuilds done, were commulative with OpenJDK 11, OpenSSL 1.1.1 and python point releases as seen in:
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-bionic.html
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-test-bionic.html

And analyzed in
https://docs.google.com/spreadsheets/d/1tMIwlwoHH_1h5sbvUbNac6-HIPKi3e0Xr8ebchIOU1A/edit#gid=147857652

[ Test case libwww-perl (and deps) regression ]

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914034

1. apt install liblwp-protocol-https-perl
2. enable -proposed
3. apt install libio-socket-ssl-perl libnet-ssleay-perl
4. perl -MLWP::UserAgent -e 'LWP::UserAgent->new->post("https://facebook.com", { data => "foo" }) or die'

[Regression Potential]

 * Connectivity interop is the biggest issues which will be unavoidable with introducing TLS v1.3. However, tests on cosmic demonstrate that curl/nginx/google-chrome/mozilla-firefox connect and negotiate TLS v1.3 without issues.

 * Mitigation of discovered connectivity issues will be possible by clamping down to TLS v1.2 in either server-side or client-side software or by backporting relevant support fixes

 * Notable changes are listed here https://wiki.openssl.org/index.php/TLS1.3

 * Most common connectivity issues so far:
   - client verifies SNI in TLSv1.3 mode, yet client doesn't set hostname. Solution is client change to set hostname, or to clamp down the client to TLSv1.2.

   - session negotiation is different in TLSv1.3, existing client code may fail to create/negotiate/resume session. Clients need to learn how to use session callback.

   - non-application data records. TLSv1.3 sends more of these, when compared with previous versions, and some applications may not handle this correctly. Resulting in application data not being available, when previously expected. Mitigation around these involve disabling/enabling SSL_MODE_AUTO_RETRY or setting max protocol version to TLSv1.2. For example see discussion identified in the perl stack https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914034
Similar hangs are possible with prior versions of TLS as well, it is however easier to trigger this with TLSv1.3.

 * Deprecated npn extenstion does not exist in TLSv1.3 implementation.

 * This update bundles python 3.6 and 3.7 point releases

 * libnet-ssleay-perl introduces two API changes which carry some risk of regression to consuming applications. The risk is considered small.
  - Servers implemented in perl may now raise SIGPIPE in the event of a premature client disconnection. This may be a behavior change in openssl itself but has only been noticed in the libnet-ssleay-perl tests. This may represent a DoS attack against any third-party TLS-using servers implemented in perl if they do not already handle SIGPIPE gracefully.
  - The behavior of SSLeay::read() and SSLeay::write() has been changed to NOT retry on short reads/short writes, leading to the perl API more closely matching the C API. There are new ssl_read_all() / ssl_write_all() calls for applications which want the previous behavior.

[Test case, python-tornado]
This is a test-only fix to fix build-time tests and autopkgtests that have regressed as a result of the openssl update. The test case is that the package builds and passes its autopkgtests again.

[Other Info]

 * Previous FFe for OpenSSL in 18.10 is at
   https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1793092

 * TLS v1.3 support in NSS is expected to make it to 18.04 via security updates

 * TLS v1.3 support in GnuTLS is expected to be available in 19.04

 * Test OpenSSL is being prepared in
   https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3473

[Autopkgtest Regressions]

dovecot/armhf - flakey

libnet-ssleay-perl - awaiting sru accept into proposed of
libnet-ssleay-perl and libio-socket-ssl-perl due to fixes and
versioned breaks.

linux* - rebuild testcases passes (for some edge flavours the build
fails in non-ssl portions of the build), ubuntu-regression-suite
testcase fails for a few variants but should have been skipped (in
progress to be fixed in
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823056)

openvswitch/i386 - extremely flakey, errors out or fails mostly

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Sven Neuhaus (sven0)]

I'm very much in favor of this.

Does this imply an update to Apache 2.4.37, too? (see https://github.com/apache/httpd/blob/2.4.x/CHANGES)

[Giraffe (dodger-forum)]

I would love to be able to Use OpenSSL 1.1.1 (TLS 1.3) with Apache2 on 18.04 LTS.

[Marc Peña (pachulo)]

Any news on this? Thanks!

[Dimitri John Ledkov (xnox)]

Here is a quick update on this SRU.

Bringing in Apache support is currently not in scope. However, this can be investigated separately and possibly would most likely look like a targetted backport of mod_ssl, rather than a full upgrade of all of the apache2. But again only after OpenSSL 1.1.1 SRU is completed.

It is investigated to bring OpenSSH compiled against libcrypto 1.1.1 support. But again only after OpenSSL 1.1.1 SRU is complete.

The current goal is to SRU OpenSSL 1.1.1 without causing any regressions to the dependent packages, which is quite a large task. In practice that does mean enabling TLS1.3 support in a few packages that are affected by the new handshake.

As stated, this SRU is being staged https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3473 possibly with a better stage page of the currently expected runtime regressions as shown at this page https://bileto.ubuntu.com/excuses/3473/bionic.html

As you can see there, this upgrade cannot land until after relevant python/perl/ruby/R changes are also brought in. Python stack is mostly ready now, the others will be quite easier to test and land.

If you can, I do urge you to test https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3473 PPA on bionic with your workloads to spot breakage, incompatibility, and/or any unexpected connectivity issues (client<->server protocol negotiation failures).

My personal goal is to land this in time / well ahead of the next bionic point release (currently penciled in for 7th February). But this is not a guarantee or a firm commitment that one can bank on.

I hope this update helps.

[Matt Ruffalo (mruffalo)]

Thank you very much, Dimitri -- I am interested in this also.

I tested that PPA on a test web server running nginx, uwsgi, uwsgi-plugin-python3, Django 1.11(.16), and a Python 3.6 'pyvenv' virtual environment using 'psycopg2' to connect to a PostgreSQL 10 server via the pre-built Python wheel for 'psycopg2_binary' version 2.7.5.

I could immediately connect to nginx over TLS 1.3 without any problems, and the Qualys SSL Labs scan also reported that all was well with TLS 1.3.

However, the web app under uwsgi crashed (segfaulted) on any request, with a stack trace at https://pastebin.com/DLGiuKfR

I was relatively surprised that the 'psycopg2_binary' Python wheel seemed to bundle its own version of libssl-8bb9b3dd.so.1.0.2o -- and it looks like there's some incompatibility with this build of Python and OpenSSL 1.1.1. I removed this Python package and installed 'psycopg2' instead, and saw the same behavior.

I was able to fix this by reinstalling psycopg2 from source with 'pip install --no-binary=":all:" psycopg2', and now everything works well with the web app.

I'm not sure how much of a problem this is at this stage, or who has the responsibility to address it (Ubuntu developers or whoever built the psycopg2 wheel), but I figured I may as well mention this anyway.

It's great that everything was fine with nginx without any effort on my part; thanks!

[Dimitri John Ledkov (xnox)]

@mruffalo

This is about distribution provided packages only, installed system-wide. Not about binaries side installed from wheels from third-party providers. Can you test using
   $ sudo apt install python3-psycopg2

Without any wheels installed from pypi...

[Virsacer (virsacer)]

Please see also: https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1803689

[Steve Langasek (vorlon)]

Hello Dimitri, or anyone else affected,

Accepted r-cran-openssl into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/r-cran-openssl/1.0.1-1ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Steve Langasek (vorlon)]

Hello Dimitri, or anyone else affected,

Accepted ruby-openssl into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ruby-openssl/2.0.9-0ubuntu1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Dr. Uwe Meyer-Gruhl (meyergru)]

Hi,

good idea in theory, but I want to add my 2cents: Please coordinate this update with ALL affected packages, like apache2 and nginx.

My reason is:

I just tried the PPA and found that nginx works with TLS 1.3 after that right out of the box.

HOWEVER, there is a problem: openssl 1.1.1 has changed the way the cipher suites are configured - the ones for TLS 1.3 are configured separately, see here:

https://github.com/openssl/openssl/commit/f865b08143b453962ad4afccd69e698d13c60f77

Nginx on the other hand has chosen to not support that new configuration at all, see:

https://trac.nginx.org/nginx/ticket/1529

That means that the predefined order of TLS 1.3 is:

TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256

and cannot be changed - it took me hours to find that out since the Nginx 1.15 documentation does not tell you that the TLS 1.3 ciphers cannot be changed by ssl_ciphers, but are silently ignored.

The default set and order of ciphersuites may suit your needs or not - matter-of-fact it makes my SSLLabs score worse because of the AES128 cipher used. I have tried to apply othe defaults in /etc/ssl/openssl.conf but they do not seem to work for nginx. Neither could I just disable TLS 1.3 in order to restore the old behaviour other than to restore OpenSSL 1.1.0 by using "ppa-purge ppa:ci-train-ppa-service/3473".

King regards,

Uwe

[Steve Langasek (vorlon)]

Acceptance of openssl currently blocked on coverage of the (distro patch) OPENSSL_TLS_SECURITY_LEVEL change as part of the SRU template.

[Dimitri John Ledkov (xnox)]

On Mon, 11 Mar 2019 at 21:20, Steve Langasek
<email address hidden> wrote:
>
> Acceptance of openssl currently blocked on coverage of the (distro
> patch) OPENSSL_TLS_SECURITY_LEVEL change as part of the SRU template.
>

In Debian (but never ubuntu) they have bumped the default security
level from 1, to 2.

In Ubuntu, we have further decreased security level from 1 to 0, for
connectivity compatibility with openssl 1.0.2. This change was done in
cosmic, and is part of this SRU backport.

The reason for the decreased security level is to aid with
connectivity compatibily with older Ubuntu LTS releases based on
openssl 1.0.2. Such that bionic clients can connect to older servers,
even if the server uses small keys / md5 / etc.

I do not believe it is possible to set higher default security level
"for servers only". Thus we rely on server/daemon apps to have
stronger configuration, large keys, better certs, etc.

There are 1.1.0/1.1.1 APIs available to dynamically set higher
security levels, which highly active servers are using to increase
security levels in servers/daemons.

These changes are documented in the cosmic+ changelog with the
following entries:
- Revert "Enable system default config to enforce TLS1.2 as a
  minimum" & "Increase default security level from 1 to 2".
- Further decrease security level from 1 to 0, for compatibility with
  openssl 1.0.2.

Migration path to stonger defaults is to be done in 2020. This is
inline with major web-browsers too. All of them still support weaker
defaults. And all of them however have committed to drop support for
those in 2020. My expectation is to follow suit, and set default
security level to 2, and require TLS1.2 shortly after 19.10 release.

For the webbrowsers announcements please see these references:
https://blogs.windows.com/msedgedev/2018/10/15/modernizing-tls-edge-ie11/
https://webkit.org/blog/8462/deprecation-of-legacy-tls-1-0-and-1-1-versions/
https://security.googleblog.com/2018/10/modernizing-transport-security.html
https://blog.mozilla.org/security/2018/10/15/removing-old-versions-of-tls/

--
Regards,

Dimitri.

[Seth Arnold (seth-arnold)]

On Tue, Mar 12, 2019 at 04:05:45PM -0000, Dimitri John Ledkov wrote:
> defaults. And all of them however have committed to drop support for
> those in 2020. My expectation is to follow suit, and set default
> security level to 2, and require TLS1.2 shortly after 19.10 release.

Can you expand upon this point a bit?

Do you mean we will require tls 1.2 across all our supported releases
at the same time?

Or do you mean we will require tls 1.2 for 19.10 and newer? Will this be
done as part of rolling out 19.10 or will we push an update to 19.10 that
will change behaviour?

Or something else?

Thanks

[Dimitri John Ledkov (xnox)]

On Tue, 12 Mar 2019 at 19:35, Seth Arnold <email address hidden> wrote:
>
> On Tue, Mar 12, 2019 at 04:05:45PM -0000, Dimitri John Ledkov wrote:
> > defaults. And all of them however have committed to drop support for
> > those in 2020. My expectation is to follow suit, and set default
> > security level to 2, and require TLS1.2 shortly after 19.10 release.
>
> Can you expand upon this point a bit?
>
> Do you mean we will require tls 1.2 across all our supported releases
> at the same time?
>
> Or do you mean we will require tls 1.2 for 19.10 and newer? Will this be
> done as part of rolling out 19.10 or will we push an update to 19.10 that
> will change behaviour?
>
> Or something else?
>

I mean that, after 19.10 ships, and 20.04 development cycle opens, I
will upload openssl which sets compiled in TLS security default to
value 2, and sets minimum TLS 1.2 into 20.04 series.
Clients and servers, will be able to continue to configure lower
values via e.g. the SSL_CTX_set_security_level [1] and so on, to
establish less than TLS 1.2 / weaker keys / etc.
That's what my plan is for 20.04. I do not plan to backport this
change to prior releases. Mostly because apps would need to learn how
to use set_security_level etc, which stable software in bionic does
not currently do en mass.

W.r.t. web-browsers, I do expect them to release those changes to
their stable browser on all platforms. It it would mean that
eventually we'd backport stable Firefox with that change into bionic.
And google chrome from google on bionic will also drop tls1.0 and
tls1.1. So a limited exposure to dropping TLS1.0/1.1 in the clients
will be observed in 2020 on Ubuntu 18.04 LTS.

[1] https://www.openssl.org/docs/man1.1.0/man3/SSL_CTX_set_security_level.html

--
Regards,

Dimitri.

[Seth Arnold (seth-arnold)]

I'm slightly concerned about raising the TLS minimums in our next LTS release without some exposure to it in the 19.10 release. But this plan sounds better than waiting until 20.10 to raise the minimums -- and 19.10 may be too soon to take the step.

But we don't have to decide on 19.10 defaults just yet.

Thanks for the explanation on why the change wouldn't make sense to backport to previous releases. Modifying enough applications to allow downgrades where necessary would carry significant risk of regressions for users.

Thanks

[Seth Arnold (seth-arnold)]

Steve Langasek has pointed out that I missed the point of the bug.

I'm not comfortable with OPENSSL_TLS_SECURITY_LEVEL=0 in bionic. (Or, indeed, in cosmic either.)

We shipped 18.04 LTS with OPENSSL_TLS_SECURITY_LEVEL=1, correct? I don't recall seeing more than a handful of complaints about security parameter mismatches over the last year. If anything, users are asking for tighter defaults, not looser defaults.

I don't believe we should be downgrading the default security level as a side effect of this transition.

Thanks

[Steve Langasek (vorlon)]

An upload of openssl to bionic-proposed has been rejected from the upload queue for the following reason: "Should not introduce a delta to downgrade to OPENSSL_TLS_SECURITY_LEVEL=0 as part of this SRU".

[Steve Langasek (vorlon)]

Hello Dimitri, or anyone else affected,

Accepted openssl into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/openssl/1.1.1-1ubuntu2.1~18.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[EOLE team (eole-team)]

The libssl1.1 version 1.1.1-1ubuntu2.1~18.04.1 breaks salt package version 2017.7.4+dfsg1-1:

root@server:~# salt-key -L
Error: unknown error (_ssl.c:2788)

root@server:~# salt --versions-report
Traceback (most recent call last):
  File "/usr/bin/salt", line 10, in <module>
    salt_main()
  File "/usr/lib/python3/dist-packages/salt/scripts.py", line 476, in salt_main
    client.run()
  File "/usr/lib/python3/dist-packages/salt/cli/salt.py", line 33, in run
    import salt.client
  File "/usr/lib/python3/dist-packages/salt/client/__init__.py", line 31, in <module>
    import salt.cache
  File "/usr/lib/python3/dist-packages/salt/cache/__init__.py", line 18, in <module>
    import salt.loader
  File "/usr/lib/python3/dist-packages/salt/loader.py", line 26, in <module>
    import salt.utils.event
  File "/usr/lib/python3/dist-packages/salt/utils/event.py", line 70, in <module>
    import tornado.iostream
  File "/usr/lib/python3/dist-packages/tornado/iostream.py", line 40, in <module>
    from tornado.netutil import ssl_wrap_socket, ssl_match_hostname, SSLCertificateError, _client_ssl_defaults, _server_ssl_defaults
  File "/usr/lib/python3/dist-packages/tornado/netutil.py", line 57, in <module>
    ssl.Purpose.SERVER_AUTH)
  File "/usr/lib/python3.6/ssl.py", line 502, in create_default_context
    context = SSLContext(PROTOCOL_TLS)
  File "/usr/lib/python3.6/ssl.py", line 391, in __new__
    self = _SSLContext.__new__(cls, protocol)
ssl.SSLError: unknown error (_ssl.c:2788)

Seems to be python3.6 which is impacted.

Regards.

[Dimitri John Ledkov (xnox)]

@eole-team

hm, that shouldn't happen. python3.6, rebuilt against openssl1.1.1, has not been accepted yet into bionic-proposed. And even, when I upgrade to python3.6 from the staging ppa, salt still fails.

To get the pending python3.6, you can use the below PPA:
$ sudo add-apt-repository ppa:ci-train-ppa-service/3662
$ sudo apt full-upgrade

I'm now opening a new bug report about salt at https://bugs.launchpad.net/ubuntu/+source/salt/+bug/1823332
As I believe it is reproducible in cosmic too.
Further salt discussion / fixing should move to that bug report.

[EOLE team (eole-team)]

Thank @xnox, I just made the test and I have the same issue with rebuilt python3.6.

[Steve Langasek (vorlon)]

needs a test case for libnet-ssleay-perl.

[Eric Desrochers (slashd)]

This is affecting radosgw's civetweb (embedded webserver) when SSL is in used for Bionic which doesn't yet support OpenSSL 1.1 in civetweb v1.8 -> LP: #1822872 .

The support of OpenSSL 1.1 start only with civetweb v1.10 and later.

- Eric

[Steve Langasek (vorlon)]

Hello Dimitri, or anyone else affected,

Accepted python2.7 into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/python2.7/2.7.15-4ubuntu4~18.04 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Steve Langasek (vorlon)]

Hello Dimitri, or anyone else affected,

Accepted python3.6 into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/python3.6/3.6.8-1~18.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Steve Langasek (vorlon)]

Hello Dimitri, or anyone else affected,

Accepted python-cryptography into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/python-cryptography/2.1.4-1ubuntu1.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Steve Langasek (vorlon)]

The libio-socket-ssl-perl debdiff includes the following changes to upstream tests:

(t/ecdhe.t)

+ my $protocol = $to_server->get_sslversion;
+ if ($protocol eq 'TLSv1_3') {
+ # <https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/>
+ ok("# SKIP TLSv1.3 doesn't advertize key exchange in a chipher name");
+ } else {

(t/npn.t)

+ SSL_version => 'SSLv23:!TLSv1_3', # NPN does not exist in TLSv1.3
+ # https://github.com/openssl/openssl/issues/3665

(t/session_ticket.t)

+ # FIXME - add session ticket support for TLS 1.3 too
+ SSL_version => 'SSLv23:!TLSv1_3',

[...]

+# FIXME: TLSv1.3 requires to use SSL_CTX_sess_set_new_cb() by clients instead
+# of SSL_get1_session(). Missing from Net::SSLeay.

Please discuss / account for the impact of these interface changes on the reverse-dependencies of libio-socket-ssl-perl as part of this SRU. AFAIK there have not been any specific rebuild etc. tests with the new version of libio-socket-ssl-perl as part of this transition. There will be autopkgtest results, which may or may not be comprehensive. If you expect these autopkgtests to be sufficient guard against regression in Ubuntu, please document why in the SRU bug. Also please quantify/characterize the risk of regression to third-party software deployed on bionic using libio-socket-ssl-perl in the face of these interface changes, and if you believe that risk of regression is acceptable, explain why.

Finally, please explain why this SRU introduces a hard-coded build-dependency (and runtime dependency) on libssl1.1 instead of this being resolved through shlibdeps or -dev package dependencies.

[Steve Langasek (vorlon)]

An upload of ruby2.5 to bionic-proposed has been rejected from the upload queue for the following reason: "Sorry, needs rebased on ruby2.5 2.5.1-1ubuntu1.2 in the security pocket".

[Steve Langasek (vorlon)]

Hello Dimitri, or anyone else affected,

Accepted python3.7 into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/python3.7/3.7.3-2~18.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Dimitri John Ledkov (xnox)]

libnet-ssleay-perl 1.86 is currently at beta9 and that version implements more comprehensive support for tls 1.3, including for example exposing APIs needed to implement post-handshake-authentication (changing client/server certs, post establishing a session, without establishing a new session/connection)

In libio-socket-ssl-perl support for tls 1.3 / openssl 1.1.1 is implemented with caveats - session resume is not available, and post-handshake-authentication is not available either. Meaning, one should establish a new session, instead of able to use faster code paths and use post-handshake-authentication or key update APIs.

The extra guards are due to changes in the runtime expectations / autopkgtests, since when the stack is built against 1.1.1, rather than just 1.1.0, tls1.3 becomes available. It is true that strictly the run time dep of 1.1.0 is sufficient.

npn is the old and withdrawn extension. It is superseeded by ALPN, published in 2014. npn is ill-defined, is neither widely used nor deployed anymore. The npn extension is obsolete, and will not be implemented with tls1.3. http/2 and ALPN is the future. Existing users on tls v1.2 can however continue to use it, as support for this extension is not removed with older tls.

Wrt. ecdhe test, the change is correct. TLS 1.3 specifies a small list of ECDHE and DHE supported groups, which are client-side authoritatitve instead of server side. Although server is allowed to send/advertise these, client must not act upon such information until after a completed handshake. Thus there is no point in testing whether or not the server advertises ECDHE curves, since with TLS 1.3 it is pointless. https://tools.ietf.org/html/rfc8446#section-4.2.7

In terms of regression risk, most of it is mitigated for the application - all existing APIs continue to work, but may result in different behavior when operating on an TLS1.3 connection. For example, calls to SSL_get1_session() continue to work, but upon resume instead of resuming a session, a new session is established because TLS1.3. See for example https://wiki.openssl.org/index.php/TLS1.3#Sessions for discussion around what the existing APIs did, and what the net effect is on a TLS1.3 connection. On the server side, one may observe a higher number of tls sessions from clients that attempt to reuse sessions "tls1.2-style" whilst operating on tls1.3 connections.

In terms of testing, autopkgtests are ok, but only test 1-2 level of dependencies, and do not end up triggering things that depend on for example libwww-perl which is what in fact would be interesting to see the results for. I am looking at reverse dependencies, but I don't see good client/server perl apps to test tls1.3 connectivity with in the archive.

Please note that these -perl packages were part of the full archive rebuild, along with the new openssl 1.1.1 and the new pythons.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Gianfranco Costamagna (costamagnagianfranco)]

python-tornado FTBFS with this proposed-pocket.

see e.g. the good build
https://launchpadlibrarian.net/421462446/buildlog_ubuntu-bionic-ppc64el.python-tornado_4.5.3-1build1_BUILDING.txt.gz
(release only pocket)
and the bad one:
https://launchpadlibrarian.net/421443840/buildlog_ubuntu-bionic-amd64.python-tornado_4.5.3-1build1_BUILDING.txt.gz
(proposed pocket)

test_inline_read_error (tornado.test.iostream_test.TestIOStreamSSL) ... FAIL
test_read_until_close_after_close (tornado.test.iostream_test.TestIOStreamSSL) ... FAIL
test_streaming_read_until_close_after_close (tornado.test.iostream_test.TestIOStreamSSL) ... FAIL
test_write_zero_bytes (tornado.test.iostream_test.TestIOStreamSSL) ... FAIL
test_inline_read_error (tornado.test.iostream_test.TestIOStreamSSLContext) ... FAIL
test_read_until_close_after_close (tornado.test.iostream_test.TestIOStreamSSLContext) ... FAIL
test_streaming_read_until_close_after_close (tornado.test.iostream_test.TestIOStreamSSLContext) ... FAIL
test_write_zero_bytes (tornado.test.iostream_test.TestIOStreamSSLContext) ... FAIL

======================================================================
FAIL: test_inline_read_error (tornado.test.iostream_test.TestIOStreamSSL)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/<<PKGBUILDDIR>>/tornado/testing.py", line 136, in __call__
    result = self.orig_method(*args, **kwargs)
  File "/<<PKGBUILDDIR>>/tornado/test/iostream_test.py", line 556, in test_inline_read_error
    server.read_bytes(1, lambda data: None)
AssertionError: error not raised

======================================================================
FAIL: test_read_until_close_after_close (tornado.test.iostream_test.TestIOStreamSSL)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/<<PKGBUILDDIR>>/tornado/testing.py", line 136, in __call__
    result = self.orig_method(*args, **kwargs)
  File "/<<PKGBUILDDIR>>/tornado/test/iostream_test.py", line 451, in test_read_until_close_after_close
    data = self.wait()
  File "/<<PKGBUILDDIR>>/tornado/testing.py", line 336, in wait
    self.__rethrow()
  File "/<<PKGBUILDDIR>>/tornado/testing.py", line 272, in __rethrow
    raise_exc_info(failure)
  File "/<<PKGBUILDDIR>>/tornado/testing.py", line 320, in timeout_func
    timeout)
AssertionError: Async operation timed out after 5 seconds

======================================================================
FAIL: test_streaming_read_until_close_after_close (tornado.test.iostream_test.TestIOStreamSSL)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/<<PKGBUILDDIR>>/tornado/testing.py", line 136, in __call__
    result = self.orig_method(*args, **kwargs)
  File "/<<PKGBUILDDIR>>/tornado/test/iostream_test.py", line 481, in test_streaming_read_until_close_after_close
    data = self.wait()
  File "/<<PKGBUILDDIR>>/tornado/testing.py", line 336, in wait
    self.__rethrow()
  File "/<<PKGBUILDDIR>>/tornado/testing.py", line 272, in __rethrow
    raise_exc_info(failure)
  File "/<<PKGBUILDDIR>>/tornado/testing.py", line 320, ...

[Gianfranco Costamagna (costamagnagianfranco)]

a wild guess is that we need some upstream commits cherry-picked
e.g.
https://github.com/tornadoweb/tornado/commit/00675409071b41650a5cd6894cafd921d16085ae
https://github.com/tornadoweb/tornado/commit/58067883c40b2894b5bdf26dd79c30b6e49207d7
https://github.com/tornadoweb/tornado/commit/81dd461da39e7dd9dcd060a958437795bafeb533
and probably more...
Not sure how distruptive are those changes...

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Dimitri John Ledkov (xnox)]

Nova is tracked in https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1771506

[Dimitri John Ledkov (xnox)]

In regression potential, in the connectivity section, added more info about "non-application data records" issues that may cause main-loop hangs.

[Tim Wegener (tim.embertec)]

Relative to openssl 1.1.0g-2ubuntu4.3, openssl 1.1.1 (via 1.1.0i) has a regression in the "openssl ca -spkac" interface that will break applications that depend on the output of that command:

https://github.com/openssl/openssl/issues/8055

The fix is in master, but has not been backported to 1.1.1:

https://github.com/openssl/openssl/commit/69f6b3ceaba493e70e1296880ea6c93e40714f0f

Would it be possible to include that fix in Ubuntu 18.04 openssl 1.1.1, so as to avoid this regression?

[Dimitri John Ledkov (xnox)]

@tim
As that is a regression already in cosmic, disco and eoan, it's best to track fixing that up and track via a separate SRU bug #. Please see https://bugs.launchpad.net/openssl/+bug/1828215 and subscribe to that bug and use that one to track releasing updates for the issue you report.

Which applications are affected by this? Are any of them shipped in Ubuntu?

[Tim Wegener (tim.embertec)]

@Dimitri
The https://bugs.launchpad.net/openssl/+bug/1828215 issue affects a custom application.
I don't know whether any packages shipped in Ubuntu are directly impacted.

[Steve Langasek (vorlon)]

Hello Dimitri, or anyone else affected,

Accepted ruby2.5 into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ruby2.5/2.5.1-1ubuntu1.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Steve Langasek (vorlon)]

An upload of libio-socket-ssl-perl to bionic-proposed has been rejected from the upload queue for the following reason: "reupload required as this version is known to introduce regressions".

[Steve Langasek (vorlon)]

Note that the regression which is introduced is cross-package; a latent bug in libwww-perl is exposed by the update of libio-socket-ssl-perl.

This means libio-socket-ssl-perl needs a reupload to declare a breaks: on the older versions of libwww-perl, so that users don't install the libio-socket-ssl-perl update without also updating libwww-perl.

[Steve Langasek (vorlon)]

And there needs to be an explicit test case for libwww-perl given the specific regression potential known here

[Steve Langasek (vorlon)]

Hello Dimitri, or anyone else affected,

Accepted libwww-perl into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libwww-perl/6.31-1ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Steve Langasek (vorlon)]

Hello Dimitri, or anyone else affected,

Accepted libio-socket-ssl-perl into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libio-socket-ssl-perl/2.060-3~ubuntu18.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Łukasz Zemczak (sil2100)]

The libio-socket-ssl-perl SRU seems to have broken dependencies, causing build failures for other SRUs (ibus-libpinyin) and image builds.

libio-socket-ssl-perl : Depends: libnet-ssleay-perl (>= 1.84-1ubuntu0.1) but it is not going to be installed

I'm actually considering removing the SRU from the -proposed pocket because of that.

[Łukasz Zemczak (sil2100)]

Ok, I see it's simply missing another SRU that's already in the queue. Looking at it since it's needed to unblock everything.

[Łukasz Zemczak (sil2100)]

Hello Dimitri, or anyone else affected,

Accepted libnet-ssleay-perl into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libnet-ssleay-perl/1.84-1ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Łukasz Zemczak (sil2100)]

Ok, so not having full context as some of the discussion was happening on IRC (and no mention of it was left on the bug here + the package was not rejected from the queue), I have possibly prematurely accepted the libnet-ssleay-perl SRU. After getting logs from Rik I see there's still no consensus on whether the read()/write() behavioral change is wanted/acceptable or not. When reviewing the package I got the impression that it was an approved change (per regression potential).

To my defense: with bionic-proposed being in a broken state causing build failures for both packages and images, the only two sane options were either accepting the package as-is or removing the two previous SRUs from -proposed.

Since I was obviously missing context and did barge in uninvited: Steve, if you think that the SRU is not really acceptable as is, please request a follow up upload with further changes. Thanks.

[Dimitri John Ledkov (xnox)]

RE: perl openssl read/write|_all changes

OpenSSL 1.1.1 has enabled AUTO_RETRY by default and all non-application data records are retried by default. Thus this is effectively a no-change for higher level users as retries have moved further down the stack to libssl itself.

Upstream executes testmatrix across a wide array of openssl implementations, and perl releases, thus there is a degree of confidence in shipping upstream preferred change of api.

As a contingency, reverting the api changes and limiting context to cap at tls1.2 will be our path forward if we need to revert this upload.

[Dimitri John Ledkov (xnox)]

autopkgtest regressions:

libgeo-coder-googlev3-perl request to badtest + sru to unbreak autopkgtests
https://bugs.launchpad.net/ubuntu/+source/libgeo-coder-googlev3-perl/+bug/1831443

[Dimitri John Ledkov (xnox)]

autopkgtest regressions:

some kernel flavours are failing to build from source due to running out of memory whilst compiling mellanox drivers. Requesting to add all kernel flavours to big_packages configuration in

https://bugs.launchpad.net/auto-package-testing/+bug/1831446

[Dimitri John Ledkov (xnox)]

Ship it!

[Łukasz Zemczak (sil2100)]

The verification of the Stable Release Update for r-cran-openssl has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package r-cran-openssl - 1.0.1-1ubuntu1.1

---------------
r-cran-openssl (1.0.1-1ubuntu1.1) bionic; urgency=medium

  * Cherrypick testsuite update for OpenSSL 1.1.1 LP: #1797386

 -- Dimitri John Ledkov <email address hidden> Tue, 11 Dec 2018 16:55:46 +1100

[Launchpad Janitor (janitor)]

This bug was fixed in the package ruby-openssl - 2.0.9-0ubuntu1

---------------
ruby-openssl (2.0.9-0ubuntu1) bionic; urgency=medium

  * New upstream micro bugfix point release.
  * Fixes compatibility with OpenSSL 1.1.1. LP: #1797386
  * Fixes CVE-2018-16395
  * Drop Debian-specific no-tls-v1.1 patch.

 -- Dimitri John Ledkov <email address hidden> Mon, 17 Dec 2018 15:37:47 +1100

[Launchpad Janitor (janitor)]

This bug was fixed in the package openssl - 1.1.1-1ubuntu2.1~18.04.1

---------------
openssl (1.1.1-1ubuntu2.1~18.04.1) bionic; urgency=medium

  * Backport OpenSSL 1.1.1 to 18.04 LTS. LP: #1797386
  * Adjust Breaks on versions published in bionic-release.

openssl (1.1.1-1ubuntu2.1) cosmic-security; urgency=medium

  * SECURITY UPDATE: timing side channel attack in DSA
    - debian/patches/CVE-2018-0734-1.patch: fix mod inverse in
      crypto/dsa/dsa_ossl.c.
    - debian/patches/CVE-2018-0734-2.patch: fix timing vulnerability in
      crypto/dsa/dsa_ossl.c.
    - debian/patches/CVE-2018-0734-3.patch: add a constant time flag in
      crypto/dsa/dsa_ossl.c.
    - CVE-2018-0734
  * SECURITY UPDATE: timing side channel attack in ECDSA
    - debian/patches/CVE-2018-0735.patch: fix timing vulberability in
      crypto/ec/ec_mult.c.
    - CVE-2018-0735

openssl (1.1.1-1ubuntu2) cosmic; urgency=medium

  * Fixup typpos in the autopkgtest binary name.

openssl (1.1.1-1ubuntu1) cosmic; urgency=medium

  * Merge from Debian unstable, remaining changes:
    - Replace duplicate files in the doc directory with symlinks.
    - debian/libssl1.1.postinst:
      + Display a system restart required notification on libssl1.1
        upgrade on servers.
      + Use a different priority for libssl1.1/restart-services depending
        on whether a desktop, or server dist-upgrade is being performed.
    - Revert "Enable system default config to enforce TLS1.2 as a
      minimum" & "Increase default security level from 1 to 2".
    - Further decrease security level from 1 to 0, for compatibility with
      openssl 1.0.2.

openssl (1.1.1-1) unstable; urgency=medium

  * New upstream version.
   - Update symbol file for 1.1.1
   - CVE-2018-0732 (actually since pre8).
  * Add Breaks on python-httplib2 (Addresses: #907015)
  * Add hardening=+all.
  * Update to policy 4.2.1
    - Less verbose testsuite with terse
    - Use RRR=no

openssl (1.1.1~~pre9-1) unstable; urgency=medium

  * New upstream version.
    - Support the final TLS 1.3 version (RFC 8446)
  * Upload to unstable

openssl (1.1.1~~pre8-1) experimental; urgency=medium

  * New upstream version.

openssl (1.1.1~~pre7-1) experimental; urgency=medium

  * Drop afalgeng on kfreebsd-* which go enabled because they inherit from
    the linux target.
  * Fix debian-rules-sets-dpkg-architecture-variable.
  * Update to policy 4.1.4
    - only Suggest: libssl-doc instead Recommends (only documentation and
      example code is shipped).
    - drop Priority: important.
    - use signing-key.asc and a https links for downloads
  * Use compat 11.
    - this moves the examples to /usr/share/doc/libssl-{doc->dev}/demos but it
      seems to make sense.
  * Add a 25-test_verify.t for autopkgtest which runs against intalled
    openssl binary.
  * Fix CVE-2018-0737 (Closes: #895844).

openssl (1.1.1~~pre6-2) experimental; urgency=medium

  * Update libssl1.1.symbols

openssl (1.1.1~~pre6-1) experimental; urgency=medium

  * New upstream version
  * Increase default security level from 1 to 2. This moves from the 80 bit
    security level to the 112 bit securit level and will require 2048 bit RSA
    and DHE keys.

openss...

[Launchpad Janitor (janitor)]

This bug was fixed in the package python2.7 - 2.7.15-4ubuntu4~18.04

---------------
python2.7 (2.7.15-4ubuntu4~18.04) bionic; urgency=medium

  * Rebuild against OpenSSL 1.1.1. LP: #1797386
  * Update to 2.7.15 final.

 -- Dimitri John Ledkov <email address hidden> Tue, 27 Nov 2018 23:36:35 +0000

[Launchpad Janitor (janitor)]

This bug was fixed in the package python3.6 - 3.6.8-1~18.04.1

---------------
python3.6 (3.6.8-1~18.04.1) bionic; urgency=medium

  * Rebuild with OpenSSL 1.1.1. LP: #1797386

python3.6 (3.6.8-1) unstable; urgency=medium

  * Python 3.6.8 release.
  * Revert the link optimization changes which appeared after the
    release candidate.

python3.6 (3.6.8~rc1-1) unstable; urgency=medium

  * Python 3.6.8 release candidate 1.
  * Update symbols files.

 -- Dimitri John Ledkov <email address hidden> Mon, 14 Jan 2019 12:02:34 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package python-cryptography - 2.1.4-1ubuntu1.3

---------------
python-cryptography (2.1.4-1ubuntu1.3) bionic; urgency=medium

  * Rebuild against OpenSSL 1.1.1, cherrypick upstream testsuite fix for
    1.1.1. LP: #1797386

 -- Dimitri John Ledkov <email address hidden> Mon, 17 Dec 2018 11:16:35 +1100

[Launchpad Janitor (janitor)]

This bug was fixed in the package python3.7 - 3.7.3-2~18.04.1

---------------
python3.7 (3.7.3-2~18.04.1) bionic; urgency=medium

  * Rebuild with OpenSSL 1.1.1. LP: #1797386

 -- Dimitri John Ledkov <email address hidden> Wed, 03 Apr 2019 20:16:38 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package ruby2.5 - 2.5.1-1ubuntu1.4

---------------
ruby2.5 (2.5.1-1ubuntu1.4) bionic; urgency=medium

  * Cherrypick ruby-openssl upstream commits to fix compat with OpenSSL
    1.1.1 LP: #1797386

 -- Dimitri John Ledkov <email address hidden> Tue, 23 Apr 2019 23:50:41 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package libwww-perl - 6.31-1ubuntu0.1

---------------
libwww-perl (6.31-1ubuntu0.1) bionic; urgency=medium

  [ gregor herrmann ]
  * Drop drop-non-blocking-socket.patch.
    The patch is not only not needed anymore, it also causes troubles with
    OpenSSL 1.1.1 (via IO::Socket::SSL).
    Thanks to Guilhem Moulin (on the Debian side) and Steffen Ullrich
    (IO::Socket::SSL upstream) for analysing the problem and tracking down the
    real culprit.
    (Closes: #914034) LP: #1797386

 -- Dimitri John Ledkov <email address hidden> Tue, 21 May 2019 09:55:53 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package libio-socket-ssl-perl - 2.060-3~ubuntu18.04.1

---------------
libio-socket-ssl-perl (2.060-3~ubuntu18.04.1) bionic; urgency=medium

  * Backport 2.060 to 18.04 LTS with TLSv1.3 support. LP: #1797386
    Includes:
    - upstream TLSv1.3 support
    - testsuite fixes to ignore SIGPIPE
    - depedencies adjusted to match SRUed version numbers
    - reverted superflorious changes to metadata/debhelper compat
  * Add breaks on hanging libwww-perl with TLSv1.3

 -- Dimitri John Ledkov <email address hidden> Tue, 11 Dec 2018 11:52:12 +1100

[Launchpad Janitor (janitor)]

This bug was fixed in the package libnet-ssleay-perl - 1.84-1ubuntu0.1

---------------
libnet-ssleay-perl (1.84-1ubuntu0.1) bionic; urgency=medium

  * Cherrypick patches prepared by Damyan Ivanov from 1.85-2 for OpenSSL
    1.1.1 support (LP: #1797386):
    + add five patches from fedora
    + patch openssl version check about SSL_CTX_set_num_tickets existence
    + add SSL[_CTX]_(set|get)_security_level routines
    + tests: set security level to 1 when loading certificates with small keys
    + patch set_cert_and_key to not return error when none of the underlying
      routines does

 -- Dimitri John Ledkov <email address hidden> Tue, 04 Dec 2018 14:05:51 +0000

[Steve Langasek (vorlon)]

Hello Dimitri, or anyone else affected,

Accepted python-tornado into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/python-tornado/4.5.3-1ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Dimitri John Ledkov (xnox)]

built and passed all autopkgtests on all architectures.

[Sascha Silbe (sascha-ubuntu-launchpad)]

This update breaks salt-ssh 2016.11.2 (started from a different computer that's running Debian Stretch) on Ubuntu 18.04 (running on the machine being managed). Having Salt break from one day to the next for managing an LTS (!) release is a rather major PITA.

Curiously enough, salt-ssh 2016.11.2 continues to work just fine on minions running Ubuntu 19.04 which ships openssl 1.1.1b-1ubuntu2.1. So whatever this SRU does apparently is different from how it works on Ubuntu 19.04.

This is the error message (from salt-ssh):

=== Begin ===
        Traceback (most recent call last):
          File "/var/tmp/.root_bdab0e_salt/salt-call", line 15, in <module>
            salt_call()
          File "/var/tmp/.root_bdab0e_salt/py2/salt/scripts.py", line 374, in salt_call
            import salt.cli.call
          File "/var/tmp/.root_bdab0e_salt/py2/salt/cli/call.py", line 9, in <module>
            import salt.cli.caller
          File "/var/tmp/.root_bdab0e_salt/py2/salt/cli/caller.py", line 18, in <module>
            import salt.loader
          File "/var/tmp/.root_bdab0e_salt/py2/salt/loader.py", line 29, in <module>
            import salt.utils.event
          File "/var/tmp/.root_bdab0e_salt/py2/salt/utils/event.py", line 72, in <module>
            import salt.payload
          File "/var/tmp/.root_bdab0e_salt/py2/salt/payload.py", line 17, in <module>
            import salt.crypt
          File "/var/tmp/.root_bdab0e_salt/py2/salt/crypt.py", line 43, in <module>
            import salt.utils.rsax931
          File "/var/tmp/.root_bdab0e_salt/py2/salt/utils/rsax931.py", line 83, in <module>
            libcrypto = _init_libcrypto()
          File "/var/tmp/.root_bdab0e_salt/py2/salt/utils/rsax931.py", line 74, in _init_libcrypto
            raise OSError("Failed to initialize OpenSSL library (OPENSSL_init_crypto failed)")
        OSError: Failed to initialize OpenSSL library (OPENSSL_init_crypto failed)
=== End ===

I was able to narrow it down to ssl.create_default_context() (invoked by tornado.netutil which salt-ssh imports indirectly via tornado.iostream) causing OPENSSL_init_crypto() to return 0 (error) on Ubuntu 18.04, but 1 (success) on Ubuntu 19.04.

=== Begin Ubuntu 18.04 ===
root@bob:~# PYTHONPATH=/var/tmp/.root_bdab0e_salt/py2 python
Python 2.7.15+ (default, Nov 27 2018, 23:36:35)
[GCC 7.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ssl
>>> _client_ssl_defaults = ssl.create_default_context(ssl.Purpose.SERVER_AUTH)
[ctypes setup for libcrypto]
>>> libcrypto.OPENSSL_init_crypto(OPENSSL_INIT_NO_LOAD_CONFIG |
... OPENSSL_INIT_ADD_ALL_CIPHERS |
... OPENSSL_INIT_ADD_ALL_DIGESTS, None)
0
>>>
=== End Ubuntu 18.04 ===

=== Begin Ubuntu 19.04 ===
root@bob:~# PYTHONPATH=/var/tmp/.root_bdab0e_salt/py2 python
Python 2.7.15+ (default, Nov 27 2018, 23:36:35)
[GCC 7.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ssl
>>> _client_ssl_defaults = ssl.create_default_context(ssl.Purpose.SERVER_AUTH)
[ctypes setup for libcrypto]
>>> libcrypto.OPENSSL_init_crypto(OPENSSL...

[Dimitri John Ledkov (xnox)]

On Wed, 19 Jun 2019, 16:30 Sascha Silbe,
<email address hidden> wrote:
>
> This update breaks salt-ssh 2016.11.2 (started from a different computer
> that's running Debian Stretch) on Ubuntu 18.04 (running on the machine
> being managed). Having Salt break from one day to the next for managing
> an LTS (!) release is a rather major PITA.

salt 2016 is an old obsolete version. Ubuntu 18.04 ships salt 2017.
this regression was already identified, and an update to address
compatibility with older software is being staged in bionic-proposed.

See for more details
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1832659

>
> Curiously enough, salt-ssh 2016.11.2 continues to work just fine on
> minions running Ubuntu 19.04 which ships openssl 1.1.1b-1ubuntu2.1. So
> whatever this SRU does apparently is different from how it works on
> Ubuntu 19.04.
>

Have you tried openssl 1.1.1-1ubuntu2.1~18.04.3 from bionic proposed?

If that one helps, please leave a comment on
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1832659 to help
us release the update sooner.

[Dimitri John Ledkov (xnox)]

Looking at autopkgtest regressions for python-tornado http://autopkgtest.ubuntu.com/packages/b/bdfproxy/bionic/ppc64el has never passed on bionic.

Can sru team please commit badtest hint for bdfproxy and release python-tarnado?

[Launchpad Janitor (janitor)]

This bug was fixed in the package python-tornado - 4.5.3-1ubuntu0.1

---------------
python-tornado (4.5.3-1ubuntu0.1) bionic; urgency=medium

  * Cherrypick patches from python-tornado4 4.5.3-2 package, to
    enable OpenSSL 1.1.1 support LP: #1797386:
    - New_test_crt.patch regenerate stronger test certificates
    - skip-failing-tests.patch skip some ssl tests failing with OpenSSL 1.1.1

 -- Dimitri John Ledkov <email address hidden> Wed, 29 May 2019 10:18:12 +0100

[Sascha Silbe (sascha-ubuntu-launchpad)]

Dimitri John Ledkov (xnox) wrote on 2019-06-19:
> Have you tried openssl 1.1.1-1ubuntu2.1~18.04.3 from bionic proposed?

I can confirm that 1.1.1-1ubuntu2.1~18.04.3 (already released a couple of days ago) fixes the issue. Thanks a lot!