Re: Bug#990059: Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality
On Mon, Jul 05, 2021 at 08:14:45AM +0900, Mike Hommey wrote: > On Mon, Jul 05, 2021 at 07:57:30AM +0900, Mike Hommey wrote: > > 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. > > It also affects openjdk-17, openjdk-8 and pcp in sid, if they're ever > meant to transition to testing (which, from the look of it, is probably > not the case). Scrap that, openjdk* and pcp are not using the problematic symbol. Mike
Re: Bug#990059: Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality
On Mon, Jul 05, 2021 at 07:57:30AM +0900, Mike Hommey wrote: > 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. It also affects openjdk-17, openjdk-8 and pcp in sid, if they're ever meant to transition to testing (which, from the look of it, is probably not the case). Mike
Re: Bug#990059: Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality
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
Re: Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality
On 2021-06-20 21:43:45 +0200, Moritz Muehlenhoff wrote: > On Sat, Jun 19, 2021 at 09:33:37PM +0200, Sebastian Ramacher wrote: > > Hallo Carsten > > > > On 2021-06-19 09:00:13 +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. > > > > If that's fine with the security team -- thunderbird updates in stable > > releases have been performed via DSAs so far -- it's fine with me. > > Adding the security team to CC. > > No problem at all, this happened for firefox/thunderbird in the past before > already. ACK, unblocked the upload that reverts to the embedded nss. Cheers > > Cheers, > Moritz > -- Sebastian Ramacher signature.asc Description: PGP signature
Re: Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality
On Sat, Jun 19, 2021 at 09:33:37PM +0200, Sebastian Ramacher wrote: > Hallo Carsten > > On 2021-06-19 09:00:13 +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. > > If that's fine with the security team -- thunderbird updates in stable > releases have been performed via DSAs so far -- it's fine with me. > Adding the security team to CC. No problem at all, this happened for firefox/thunderbird in the past before already. Cheers, Moritz
Re: Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality
Hello Sebastian, Am 19.06.21 um 21:33 schrieb Sebastian Ramacher: ... >> 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. > > If that's fine with the security team -- thunderbird updates in stable > releases have been performed via DSAs so far -- it's fine with me. > Adding the security team to CC. thanks, I pushed 1:78.11.0-2 to unstable. This will fix the current issues for the users. -- Regards Carsten
Re: Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality
Hallo Carsten
On 2021-06-19 09:00:13 +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.
If that's fine with the security team -- thunderbird updates in stable
releases have been performed via DSAs so far -- it's fine with me.
Adding the security team to CC.
Cheers
>
> 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
>
--
Sebastian Ramacher
signature.asc
Description: PGP signature
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
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
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.
