Re: Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality
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.
Looking at "Help - Troubleshooting Information" I can see now that
Thunderbird is expecting NSS 3.51.1 (instead of 3.63) which gets
provided by exact this version (internally).
There will be only one more real ESR version 78.12.0 before the ESR
version will get bumped to 91.x. So in my eyes it's acceptable that we
start right now to use the internal shipped NSS version. We will need to
do this any way together with the new ESR version is getting prepared
for bullseye-security.
(To be honest, there will also be 78.{13-15}.0 before we probably be
ready for 91.3.0. In the past we've been very conservative with
uploading fresh and new ESR version to stable-security due limited
resources for testing before.)
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 used a chroot of unstable to built the packages but all required
versions can get fulfilled in testing (libnss3 isn't a dependency now as
the internal version is used and dpkg-shlipdeps isn't adding any
dependency to this).
Thus we could simply use the usual way to update Thunderbird via
unstable in testing.
--
Regards
Carsten
Reply to: