kiss-community/kiss

Dependency detector "breaks" if 2 packages provide the same lib in different paths

git-bruh opened this issue ยท 9 comments

If there are 2 packages that provide the same library in different directories (like /usr/lib, /usr/lib32), KISS's dependency detector adds the wrong package to depends.

Eg:
glibc: /usr/lib/libresolv.so
lib32-glibc: /usr/lib32/libresolv.so

Now if you have something that links to -lresolv, KISS will add lib32-glibc to depends instead of glibc because of the pattern used in grep:

+ pkg_owner -l '/libresolv.so.2$' /var/db/kiss/installed/...
+ pkg_owner='/var/db/kiss/installed/glibc/manifest
/var/db/kiss/installed/lib32-glibc/manifest'
+ pkg_owner='/var/db/kiss/installed/glibc/manifest
/var/db/kiss/installed/lib32-glibc'
+ pkg_owner=lib32-glibc
+ set -f
+ '[' lib32-glibc ]
+ printf '%s\n' lib32-glibc

This kind of issue could be prevented if KISS grep-ed for a pattern like lib/libresolv.so.2 but that won't be possible when readelf is the dep detector, since it only shows Shared library: [lib.so] instead of the path.

I can't think of a solution for this and neither do i expect kiss to accomodate for such situations since the "official" KISS is non-multilib and there's not many other situations where such an issue would arise. Just creating this issue to see what other's think of as possible solutions to this (So that kiss can be patched by anyone running in such an environment).

This can be fixed by using both readelf and ldd. I will write up a patch and send it to the mailing list.

The most obvious usecase here is multilib, which of course KISS doesn't target. There are nonmultilib uses cases though, yes? Like if you decided to install a flurry of trash to /proc I imagine we would have a similar problem...

I personally consider this a bugfix. Even though multilib is the case for here, we shouldn't rely on non-fullpath dependency resolve.

pkg_owns is in itself a problematic and insecure function too, which was put in to make up for the non-fullpath expansion of readelf. I will write a patch to fix that up if you merge my fix for this one.

I agree that it's a bug.

I'll do some testing, and it'll probably get pushed next I hear from you ๐Ÿ‘๐Ÿป

Thanks @cemkeylan, the patch seems to be working fine. But doesn't it defeat the point of $KISS_ELF if ldd is gonna be called anyways ?

The point of using readelf is accurate dependency resolution. When you call ldd it will output dependencies, but also their dependencies. readelf only shows direct dependencies, and calling ldd to get fullpath of them doesn't change the premise, and doesn't defeat the purpose.

readelf was mostly implemented to have kiss be a bit smarter about the dependencies it says packages have to prevent strange breakages - that readelf doesn't output the entire path is problematic, and in our case for no technically good reason.

I have sent the benchmark to the mailing list.