[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


Reply to: