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
