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 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
