OpenSSL 1.1.1 for bionic

Dimitri John Ledkov xnox at
Mon Feb 25 16:55:28 UTC 2019

There are many moving parts involved to safely land the OpenSSL 1.1.1
update in Bionic.

SRU bug report

Landing OpenSSL and related updates (pythons, ruby, r-cran, etc) will
trigger many autopkgtests and may regress package buildability. Thus
before landing the update, I would like to land stand-alone SRUs that
fix and resolve FTBFS and autopkgtests regressions that will become
apparent once new OpenSSL is in proposed.

These are:

The changes and fixes in above are openssl-version agnostic. Ideally
I'd want the above at least in -proposed, if not -updates, before
accepting openssl 1.1.1 update.
Then there is a bunch of syncs:

openssl (bionic-proposed/main) [1.1.0g-2ubuntu4.3 => 1.1.1-1ubuntu2.1~18.04.0]

python2.7 (bionic-proposed/main) [2.7.15~rc1-1ubuntu0.1 =>
2.7.15-4ubuntu4~18.04] (core) (sync)
python3.6 (bionic-proposed/main) [3.6.7-1~18.04 => 3.6.8-1~18.04.1]
(core) (sync)
python3.7 (bionic-proposed/universe) [3.7.1-1~18.04 =>
3.7.2-1~18.04.1] (no packageset) (sync)
python-cryptography (bionic-proposed/main) [2.1.4-1ubuntu1.2 =>
2.1.4-1ubuntu1.3] (core) (sync)

ruby2.5 (bionic-proposed/main) [2.5.1-1ubuntu1.1 => 2.5.1-1ubuntu1.3]
(kubuntu, ubuntu-desktop, ubuntu-server) (sync)
ruby-openssl (bionic-proposed/universe) [2.0.5-1build3 =>
2.0.9-0ubuntu1] (no packageset) (sync)

libio-socket-ssl-perl (bionic-proposed/main) [2.056-1 =>
2.060-3~ubuntu18.04.0] (core) (sync)
libnet-ssleay-perl (bionic-proposed/main) [1.84-1build1 =>
1.84-1ubuntu0.1] (core) (sync)

r-cran-openssl (bionic-proposed/universe) [1.0.1-1ubuntu1 =>
1.0.1-1ubuntu1.1] (no packageset) (sync)

nova (bionic-proposed/main) [2:17.0.7-0ubuntu2 => 2:17.0.7-0ubuntu2.1]
(openstack, ubuntu-server) (sync)

These were built in security pocket, in a bileto ppa, thus are
suitable for publishing in either (or both) -security or -updates
These are built in correct order, thus e.g. python-cryptography was
built agains pythons that are built against openssl 1.1.1, and thus
all binaries are collectively installable on publication.
As you can notice 3.6 and 3.7 are point release bumps, that not only
introduce openssl 1.1.1 compatibility (fixes in test suite asumptions
re:tlsv1.3) but also add functionality to exploit/limit usage of
Note that python3.7 is neither default nor supported python version,
it's standalone/inert in bionic by default - technology preview used
by some upstream CIs to gain access to python3.7 interpreter without
any other system dependencies.
Similarly with the rest of the syncs, they introduce
testsuites/adt-tests/ftbfs fixes and compatibility for openssl 1.1.1.
We (doko) do want to SRU the python3.6/3.7 point releases regardless
of openssl SRU, but doing this in one go, saves on validation
resources / adt testing, as python triggers a long tail of tests. Also
it may be cumbersome to split hairs of the python3.6/3.7 point release
update into openssl and non-openssl update portions.

The diffs for these uploads are quite large, and I am not sure what's
the best way to present these SRUs to the SRU team for review. In
addition to above syncs I could upload source only uploads into the
queue, however, the binaries here need to be built in security pocket
only (such that we have ability to push these update into security
pocket, if and when needed). Please let me know if you want any
changes from me to conquer reviewing all of the above SRUs.



More information about the Ubuntu-release mailing list