How to further handle Openssl 1.1.1 in Bionic?

[Christian Ehrhardt]

Hi,
in recent weeks since [1][2] there were quite some bugs related to
rebuilds or feature requests.
Those kind of issues seemed to be partially expected quoting the bugs SRU text:

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

Along the SRU some packages were initially identified needing patches
to either fully support (if doable in an SRU scope) or clamp-down to
TLSv1.2 and got such changes.

But since then there is a set of bugs [3] coming up for either
a) "could you also enable TLSv1.3 in package ..."
b) "Openssl 1.1.1 broke package ..."

And while some of those seem to be "just work" e.g. a rebuild or small
patch to enable/disable TLSv1.3 others run into interesting issues as
openssl has changed more than jsut adding TLSv1.3.

A good example is a bug that was expected to just be a rebuild [4]. We
have realized there can be subtle effects causing regressions. In the
particular example it seems that a rebuild not only enabled TLSv1.3,
but also bumped the minimum dh key size to 2k [5] which in turn breaks
some older clients and therefore is a no-no from an SRU perspective.
The bug [4] currently is assigned to ubuntu-security team for guidance
on this - do we want/need this and accept the regression it causes or
do we want/need to "clamp-down" the dh key size as well?

But this is a generic question - not only in the context of haproxy for [4].
If formerly only "clamping down for TLSv1.2" was considered, do we
need to revisit all packages for DH key size as well? ...

Even if we don't do anything today, a security update tomorrow might
force us to rebuild and trigger this kind of issues for 'potentially'
all dependencies of openssl.
We already have seen quite some of them being actual regressions in
our LTS which is concerning for the potential estimated number of
unreported cases.

And this is what this mail is about, as more than just bug-triagers
and the security-team might have a say and an opinion about it that
should be heard. Questions are:
- Are other packages known to likely could be affected by that?
- How was that planned from the POV of the openssl upload?
  What are we expected to do in the case of [4] or any similar issue
that we find later on?
- Do we need to analyze all packages rebuilt since openssl 1.1.1 for
such effects?
...

If you are involved or have context expertise please help to clarify
the questions above for the current issue [4] but also in general.
If not I'd still ask everyone to speak up if you know or have seen
related issues.
Triagers can use the tag "bionic-openssl-1.1" to help tracking those bugs.

[1]: https://launchpad.net/ubuntu/+source/openssl/1.1.1-1ubuntu2.1~18.04.1
[2]: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1797386
[3]: https://bugs.launchpad.net/bugs/+bugs?field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.tag=bionic-openssl-1.1&orderby=status&start=0
[4]: https://bugs.launchpad.net/ubuntu/bionic/+source/haproxy/+bug/1841936
[5]: https://people.canonical.com/~ubuntu-security/cve/2015/CVE-2015-4000.html

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd