[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not



On Mon, Jan 24, 2022 at 10:20:48AM +0800, Paul Wise wrote:
> On Sun, 2022-01-23 at 17:43 -0500, Theodore Y. Ts'o wrote:
> 
> > That only works if there are no other packages depending on those
> > shared libraries which are coming from other source packages.
> 
> I don't think that is true, I believe you can put multiple things in
> the depends section of an shlibs file and dpkg-shlibdeps will propagate
> that to reverse dependencies just fine. From the manual pages it looks
> like the same applies to the symbols files. I found on my system that
> there are *already* packages that do something similar (see below).

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.

       	       		      	      	 	  - Ted

P.S.  Let's assume that the reason why SONAME needs to be bumped every
single time is not because upstream is lazy, and just bumps the SONAME
"just in case", but because they did a terrible job designing the
library ABI, and there are complex structures that need to all the
time because they are exposed in the public headers, yet the
structures depend on internal implementation details, so they are
constantly fluid.  This is not a hypothetical situation; the openssl
libraries are very much in the case, and when we were trying to get
them to agree to create a stable ABI for the Linux Standard Base,
usptream basically said, "no can do".

So complex ABI analysis isn't going to help you; you basically have to
rebuild all of the dependent packages whenever the SONAME gets bumped.


Reply to: