[SRU] OpenSSL 1.1.1 to 18.04 LTS

Bug #1797386 reported by Dimitri John Ledkov on 2018-10-11
354
This bug affects 73 people
Affects Status Importance Assigned to Milestone
libio-socket-ssl-perl (Ubuntu)
Bionic
Undecided
Unassigned
libnet-ssleay-perl (Ubuntu)
Bionic
Undecided
Unassigned
libwww-perl (Ubuntu)
Undecided
Unassigned
Bionic
Undecided
Unassigned
openssl (Ubuntu)
Undecided
Steve Langasek
Bionic
Undecided
Unassigned
python-cryptography (Ubuntu)
Bionic
Undecided
Unassigned
python-tornado (Ubuntu)
Bionic
Undecided
Unassigned
python2.7 (Ubuntu)
Bionic
Undecided
Unassigned
python3.6 (Ubuntu)
Bionic
Undecided
Unassigned
python3.7 (Ubuntu)
Bionic
Undecided
Unassigned
r-cran-openssl (Ubuntu)
Bionic
Undecided
Unassigned
ruby-openssl (Ubuntu)
Bionic
Undecided
Unassigned
ruby2.5 (Ubuntu)
Bionic
Undecided
Unassigned

Bug Description

[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

tags: added: bionic
summary: - SRU OpenSSL 1.1.1 to 18.04 LTS
+ [SRU] OpenSSL 1.1.1 to 18.04 LTS
description: updated
Launchpad Janitor (janitor) wrote :

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

Changed in openssl (Ubuntu):
status: New → Confirmed
Sven Neuhaus (sven0) wrote :

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) wrote :

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) wrote :

Any news on this? Thanks!

Dimitri John Ledkov (xnox) wrote :

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) wrote :

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!

description: updated
Dimitri John Ledkov (xnox) wrote :

@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...

description: updated
Changed in openssl (Ubuntu):
status: Confirmed → In Progress

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.

Changed in r-cran-openssl (Ubuntu Bionic):
status: New → Fix Committed
no longer affects: r-cran-openssl (Ubuntu)
no longer affects: libio-socket-ssl-perl (Ubuntu)
tags: added: verification-needed verification-needed-bionic
no longer affects: libnet-ssleay-perl (Ubuntu)
no longer affects: nova (Ubuntu)
no longer affects: python2.7 (Ubuntu)
no longer affects: python-cryptography (Ubuntu)
Steve Langasek (vorlon) wrote :

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.

no longer affects: python3.6 (Ubuntu)
no longer affects: python3.7 (Ubuntu)
Changed in ruby-openssl (Ubuntu Bionic):
status: New → Fix Committed
no longer affects: ruby-openssl (Ubuntu)
no longer affects: ruby2.5 (Ubuntu)
Dr. Uwe Meyer-Gruhl (meyergru) wrote :

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) wrote :

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

Changed in openssl (Ubuntu Bionic):
status: New → Incomplete

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) 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?

Thanks

Dimitri John Ledkov (xnox) wrote :

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.

description: updated
Changed in openssl (Ubuntu Bionic):
status: Incomplete → Confirmed
Changed in openssl (Ubuntu):
assignee: nobody → Steve Langasek (vorlon)
Seth Arnold (seth-arnold) wrote :

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) wrote :

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

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".

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.

Changed in openssl (Ubuntu Bionic):
status: Confirmed → Fix Committed
Steve Langasek (vorlon) on 2019-04-03
description: updated
description: updated
EOLE team (eole-team) wrote :

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) wrote :

@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) wrote :

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

no longer affects: salt (Ubuntu)
no longer affects: salt (Ubuntu Bionic)
description: updated
Steve Langasek (vorlon) wrote :

needs a test case for libnet-ssleay-perl.

no longer affects: libnet-ssleay-perl (Ubuntu)
Changed in libnet-ssleay-perl (Ubuntu Bionic):
status: New → Incomplete
Eric Desrochers (slashd) wrote :

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) wrote :

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.

Changed in python2.7 (Ubuntu Bionic):
status: New → Fix Committed
Steve Langasek (vorlon) wrote :

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.

Changed in python3.6 (Ubuntu Bionic):
status: New → Fix Committed
Steve Langasek (vorlon) wrote :

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.

Changed in python-cryptography (Ubuntu Bionic):
status: New → Fix Committed
Steve Langasek (vorlon) wrote :

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.

Changed in libio-socket-ssl-perl (Ubuntu Bionic):
status: New → Incomplete

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".

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.

Changed in python3.7 (Ubuntu Bionic):
status: New → Fix Committed
Changed in openssl (Ubuntu):
status: In Progress → Fix Released
Dimitri John Ledkov (xnox) wrote :

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) wrote :

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

Changed in nova (Ubuntu Bionic):
status: New → Confirmed
Changed in ruby2.5 (Ubuntu Bionic):
status: New → Confirmed
Download full text (7.0 KiB)

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, ...

Read more...

Launchpad Janitor (janitor) wrote :

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

Changed in python-tornado (Ubuntu):
status: New → Confirmed
Dimitri John Ledkov (xnox) wrote :
no longer affects: nova (Ubuntu Bionic)
Dimitri John Ledkov (xnox) wrote :

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

description: updated
Tim Wegener (tim.embertec) wrote :

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) wrote :

@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) wrote :

@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.

information type: Public → Public Security
information type: Public Security → Public
description: updated
Steve Langasek (vorlon) wrote :

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.

Changed in ruby2.5 (Ubuntu Bionic):
status: Confirmed → Fix Committed

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".

Changed in python-tornado (Ubuntu):
status: Confirmed → In Progress
Steve Langasek (vorlon) wrote :

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) wrote :

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

Changed in libwww-perl (Ubuntu):
status: New → Incomplete
description: updated
Changed in libnet-ssleay-perl (Ubuntu Bionic):
status: Incomplete → In Progress
Changed in libio-socket-ssl-perl (Ubuntu Bionic):
status: Incomplete → In Progress
Changed in libwww-perl (Ubuntu):
status: Incomplete → In Progress

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.

description: updated
Changed in libwww-perl (Ubuntu Bionic):
status: New → Fix Committed
Changed in libwww-perl (Ubuntu):
status: In Progress → Fix Released
Steve Langasek (vorlon) wrote :

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.

Changed in libio-socket-ssl-perl (Ubuntu Bionic):
status: In Progress → Fix Committed
Steve Langasek (vorlon) on 2019-05-30
description: updated
Łukasz Zemczak (sil2100) wrote :

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.

tags: added: verification-failed-bionic
removed: verification-needed-bionic
Łukasz Zemczak (sil2100) wrote :

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.

Changed in libnet-ssleay-perl (Ubuntu Bionic):
status: In Progress → Fix Committed
tags: added: verification-needed-bionic
removed: verification-failed-bionic
Łukasz Zemczak (sil2100) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

Ship it!

tags: added: verification-done verification-done-bionic
removed: verification-needed verification-needed-bionic

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) wrote :

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

Changed in r-cran-openssl (Ubuntu Bionic):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in ruby-openssl (Ubuntu Bionic):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :
Download full text (4.0 KiB)

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...

Read more...

Changed in openssl (Ubuntu Bionic):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in python2.7 (Ubuntu Bionic):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in python3.6 (Ubuntu Bionic):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in python-cryptography (Ubuntu Bionic):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in python3.7 (Ubuntu Bionic):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in ruby2.5 (Ubuntu Bionic):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in libwww-perl (Ubuntu Bionic):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in libio-socket-ssl-perl (Ubuntu Bionic):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in libnet-ssleay-perl (Ubuntu Bionic):
status: Fix Committed → Fix Released

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.

description: updated
Changed in python-tornado (Ubuntu Bionic):
status: New → Fix Committed
tags: added: verification-needed verification-needed-bionic
removed: verification-done verification-done-bionic
Steve Langasek (vorlon) on 2019-06-10
no longer affects: python-tornado (Ubuntu)
Dimitri John Ledkov (xnox) wrote :

built and passed all autopkgtests on all architectures.

tags: added: verification-done verification-done-bionic
removed: verification-needed verification-needed-bionic
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers