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.
