Re: Bug#990059: Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality

[Mike Hommey <mh@glandium.org>]

reopen 990059
affects 990059 firefox-esr firefox libcurl3-nss
thanks

On Sat, Jun 19, 2021 at 09:00:13AM +0200, Carsten Schoenert wrote:
> Hello Kevin, hello Sebastian,
> 
> thanks for working on this issue in between times, I wasn't able to do
> anything practically the last days.
> 
> Am 18.06.21 um 23:31 schrieb Kevin Locke:
> > Hi Sebastian,
> > 
> > On Fri, 2021-06-18 at 22:26 +0200, Sebastian Ramacher wrote:
> >> Thanks for this detailed analysis. That actually means that the symbol
> >> file for libnss3 2:3.67-1 is broken. It would need to bump the minimum
> >> version requirement for all symbols that works with SSLChannelInfo. From
> >> your description, at least the version for SSL_GetChannelInfo would need
> >> to be bumped. If thunderbird would then be built against a libnss3
> >> version with a fixed symbol files, it would pick up tight enought
> >> dependencies.
> >>
> >> So ideally the bug against thunderbird would be reassigned to libnss3
> >> 2:3.67-1 and its severits raised to serious. Once fixed, we can rebuild
> >> thunderbird to pick up the correct depedencies.
> > 
> > Good point.  Fixing the libnss3 symbol file sounds like the right fix to
> > me.  As far as I can tell SSL_GetChannelInfo is the only symbol which
> > takes SSLChannelInfo.  I've opened https://bugs.debian.org/990058 with
> > the proposed fix.
> 
> Fixing libnss3 is obviously the correct thing anyway. But this will take
> its time to get it landed into bullseye.
> 
> >> But since that version of libnss3 is not in bullseye, the rebuild would
> >> not be abile to migrate. Ideally libnss3 would be reverted to the
> >> version in bullseye to avoid this issue. Otherwise I can schedule
> >> binNMUs of thunderbird in tpu, but that means that we would need to do
> >> that for any thunderbird upload that we want in bullseye until the
> >> release. That is suboptimal - it's more work with less testing.
> > 
> > That may be tricky.  firefox 88.0.1-1 in unstable depends on
> > libnss3 (>= 2:3.63~).  If the maintainers are willing to upload an NSS
> > version between 2:3.63 and 2:3.65, I believe that would solve the issue
> > without breaking firefox.  (2:3.63-1 is the only suitable version
> > in debian/changelog.)  I've opened https://bugs.debian.org/990059 to
> > discuss.
> 
> To prevent quite a lot of work on all involved parties with not that
> much gain in the end I'd suggest to go back to my option B that was to
> (re)build Thunderbird with it's internal shipped NSS version.

Unfortunately, this affects more than Thunderbird. It also affects
Firefox ESR (although not on amd64 because for some reason it was built
against an older version of NSS, but it affects other architectures). It
also affects the latest upload of curl.

I'm going to upload a new version of 3.67 that will restore the binary
compat so that things built against the new version will work with the
older one. That should allow to binNMU the affected packages.

Mike