Hi, On Fri, May 29, 2020 at 11:29:24AM +0100, Simon McVittie wrote: > On Thu, 28 May 2020 at 22:41:19 +0200, Salvatore Bonaccorso wrote: > > The following vulnerability was published for glib-networking. > > > > CVE-2020-13645[0]: > > | In GNOME glib-networking through 2.64.2, the implementation of > > | GTlsClientConnection skips hostname verification of the server's TLS > > | certificate if the application fails to specify the expected server > > | identity. This is in contrast to its intended documented behavior, to > > | fail the certificate verification. Applications that fail to provide > > | the server identity, including Balsa before 2.5.11 and 2.6.x before > > | 2.6.1, accept a TLS certificate if the certificate is valid for any > > | host. > > Upstream used codesearch.debian.net to look for vulnerable applications, > and balsa is the only one they found. > > If I'm understanding the upstream issue reports correctly, the fixed > version of glib-networking "fails closed", which means that updating > glib-networking will cause serious regressions in balsa (it will fail to > validate any server certs, even those that are valid). > > I've reported a balsa bug and set it to block this one. I think the best > resolution is probably to update balsa in each supported suite first, > and only then follow up by fixing glib-networking. > > Do the security team intend to do DSAs for this? If yes, the DSA should > probably recommend updated balsa *and* glib-networking packages. If no, > we should probably get updated balsa packages into stable-proposed-updates > before updating glib-networking.
I tend here to have it fixed via a point release rather than a DSA, in conjunction with the needed balsa update together. Thanks for having checked as well other reverse dependencies and filling as well the respective balsa bug. Regards, Salvatore
