Re: Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality
Hi Carsten, On Sat, 2021-06-19 at 09:00 +0200, Carsten Schoenert wrote: > 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. Sure, that works for me. If the other stakeholders (security and release teams?) are ok with that plan, I'll close Bug #990059. I think Bug #990058 should remain open until fixed in either case. > I've done such a rebuild of 78.11.0 together with the internal NSS > library and so far I don't see any TLS/SSL related issue as before. > > The packages and the debian folder can be found here > > https://people.debian.org/~tijuca/thunderbird-bullseye/ I gave it a try and it works well on my system with either libnss3 2:3.61-1 or 2:3.67-1 installed. (It doesn't appear to use libnss3, as you said, but I can't uninstall it due to other rdepends on my system). Thanks again, Kevin
Re: Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality
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. > 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. Thanks, Kevin P.S. My apologies for not following your suggestion to reassign #989839 to libnss3. I thought we might need separate issues for better granularity over the different parts of the issue. I hope it doesn't end up causing more confusion or hassle.
Re: Thunderbird 1:78.11.0-1 in testing lacks full functionality
On 2021-06-17 22:32:46 +0200, Sebastian Ramacher wrote: > On 2021-06-17 19:54:51, Carsten Schoenert wrote: >> Unfortunately rather also quickly I got some bug reports about >> Thunderbird isn't correctly working in testing/bullseye, but has before >> in version 1:78.10.0-1. >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989839 >> >> [...] >> >> But how to proceed right now? >> >> I see two possible options. >> >> 1. Unblock nss 2:3.67-1 >>But I've no idea if Mike has his reasons for not requesting an >>unblock. But I also can't think of any. >> >> 2. Rebuild the thunderbird package and use the internal shipped nss >>source which is at 3.51.1. >>I expect this will get needed any way for bullseye once the next ESR >>circle is starting as and usually MZLA will use then the most recent >>available nss version within the shipped source. >> >> What for opinions the RT is seeing? > > Please correct me if I get anything wrong: thunderbird requires nss3 >= > 3.51.1 (which it includes). It was built against 3.67 and fails to run > with 3.66. Would it work correctly if built against nss3 3.66 (which would > also satisfy the version requirement)? > > If not, is nss3 in bullseye broken? Of yes, did 3.67 break its ABI? Or > is it simply a matter of an incorrectly produce dependency which is not > high enough? Forgive me for butting in to the conversation, but I think I can provide some useful information: I believe the issue is that the size of SSLChannelInfo increases between some NSS versions (NSS 3.54 added pskType, NSS 3.60 added echAccepted, NSS 3.66 added isFIPS). SSL_GetChannelInfo takes both a pointer to and size of SSLChannelInfo as arguments. If the size is greater than the size it expects, it returns SECFailure. This means SSL_GetChannelInfo fails when the caller was compiled with a more recent version of libnss3 than the version it is loaded with and the size of SSLChannelInfo changed between the versions. SSL_GetChannelInfo succeeds when the caller was compiled with any lower version than the version it is loaded with. This causes issues when thunderbird 1:78.11.0-1 (built with libnss3-dev 2:3.66-1) is run with libnss3 2:3.61-1 currently in testing. I don't think libnss3 2:3.61-1 is broken. I think thunderbird needs to be compiled against libnss3-dev <= 3.65 to run with 3.61, or it needs to be run with libnss3 >= 3.66. To avoid issues going forward, I would suggest that thunderbird needs a tighter versioned dependency on libnss3. It may make sense for thunderbird to depend on libnss3 >= the version of libnss3-dev it was compiled against. (Which is a bit conservative, since the size of SSLChannelInfo doesn't change in every version, but would require less work than tracking version compatibility.) Just an idea. I'd defer to Carsten's judgement on how best to handle it. Cheers, Kevin [SSL_GetChannelInfo]: https://hg.mozilla.org/releases/mozilla-esr78/file/FIREFOX_78_11_0esr_RELEASE/security/nss/lib/ssl/sslinfo.c#l13
