Hi Kevin On 2021-06-18 10:48:05 -0600, Kevin Locke wrote: > 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. 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. 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. Cheers > > Cheers, > Kevin > > [SSL_GetChannelInfo]: https://hg.mozilla.org/releases/mozilla-esr78/file/FIREFOX_78_11_0esr_RELEASE/security/nss/lib/ssl/sslinfo.c#l13 > -- Sebastian Ramacher
Attachment:
signature.asc
Description: PGP signature