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
Attachment:
signature.asc
Description: PGP signature