Hi Ted, On 24-01-2022 19:44, Theodore Y. Ts'o wrote:
No, dpkg-shlibsdeps doesn't save you. Again, consider the hypothetical package libshaky, which over the period of 9 months, has soname changes which generate (over time) packages libshaky3, libshaky4, libshaky6, libshaky7, and libshaky8. The latest version of libshaky sources will create the binary packages libshaky8, libshaky-bin, and libshaky-dev. Other various external packages such as say, shaky-cli uses libshaky4, shaky-gtk uses libshaky6, shaky-qt might use libshaky7, etc. Now suppose that there is a critical security bug fixed in the latest version of libshaky sources. So the security fix is might be fixed in libshaky8, but the same security bug that allows remote code execution as well as privileged escalation might apply to libshaky[3467] as well, but since the fix was only in the latest version of libshaky, you might as well have been using static libraries in libshaky. Except that is apparently not allowed by policy. Oops.
I think this is the second time you write something like this, but for dynamically linked libraries, the rebuild happens (by the Release Team, (please use transition trackers for that) because we automatically track transitions [1]). Unless people don't follow the convention that your binary matches the SONAME. But nowadays we find those more and more due to autopkgtest (reverse dependencies that fail because they can't find the appropriate library). It becomes increasingly more difficult to hide the fact that your package is not named appropriately.
Paul [1] https://release.debian.org/transitions/
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature