Bug#990059: Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality

[Mike Hommey]

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

Bug#989839: Bug#990059: Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality

[Mike Hommey]

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

Bug#990059: Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality

[Mike Hommey]

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

Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality

[Sebastian Ramacher]

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

Bug#990059: Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality

[Moritz Muehlenhoff]

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

Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality

[Carsten Schoenert]

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

Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality

[Sebastian Ramacher]

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

Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality

[stephane szyller]

hello

Thunderbird does connect with gmail imap server with The packages and the debian 
folderhttps://people.debian.org/~tijuca/thunderbird-bullseye/  

thanks a lot
Stéphane

Bug#990059: Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality

[Kevin Locke]

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

Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality

[Carsten Schoenert]

Hello Mina,

Am 19.06.21 um 09:33 schrieb Mina Morcose Farage:
...
>> 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 tested your version i can confirm  it's working on testing

thanks for testing and confirming the working functionality!

-- 
Regards
Carsten

Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality

[Carsten Schoenert]

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

Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality

[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.

> 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.

Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality

[Sebastian Ramacher]

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


signature.asc
Description: PGP signature

Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality

[Kevin Locke]

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