melange ignores libraries that are not executable when generating dependencies

[smoser]

I have not dug much, but in wolfi-dev/os#40650, we saw that melange was not generating a dependency on so:libsqlite3.so.0 for tcl. I verified via my awesome printf debugging skills that it is being skipped because it is not executable (here).

I also verified that continuing on even if the file is not executable will add the depend = so:libsqlite3.so.0 dependency.

The permissions check blames to 6ac562b, which is the first code added to do soname dependencies. (package: implement SONAME dependency scanning), so there isn't a lot of explanation for it.

[smoser]

I'll also note that ubuntu also does ship /usr/lib/tcltk/sqlite3/libtclsqlite3.so without execute (0644).
In fact ubuntu ships almost all shared libraries without execute:

$ find /usr/ -name "lib*.so*"  | xargs ls -l | grep -v "^l" | wc -l
2004

That is not perfect, but there are ~2000 files on my desktop ubuntu installation in /usr that match lib*.so*. Of those files, those listed below are the only ones that are executable (r.x). aws-cli and slack account for all but 3 of those 16, and those packages are installed from somewhere other than ubuntu. the other 3 are from coreutils, libc and gcc, I'm assuming that the maintainers of these 3 packages intentionally installed the files with execute against the general rule.

~$ find /usr/ -name "lib*.so*"  | xargs ls -l | grep -v "^l" | awk '$1 ~ /r.x/ { print $0 }'
-rwxr-xr-x 1 root root  2125328 Aug  8 10:47 /usr/lib/x86_64-linux-gnu/libc.so.6
-rwxr-xr-x 1 root root     14632 Apr  5  2024 /usr/libexec/coreutils/libstdbuf.so
-rwxr-xr-x 1 root root     68296 Sep  4 10:44 /usr/libexec/gcc/x86_64-linux-gnu/13/liblto_plugin.so
-rwxr-xr-x 1 root root    249784 Dec  5 18:24 /usr/lib/slack/libEGL.so
-rwxr-xr-x 1 root root   2616712 Dec  5 18:24 /usr/lib/slack/libffmpeg.so
-rwxr-xr-x 1 root root   6828736 Dec  5 18:24 /usr/lib/slack/libGLESv2.so
-rwxr-xr-x 1 root root   4765280 Dec  5 18:24 /usr/lib/slack/libvk_swiftshader.so
-rwxr-xr-x 1 root root    584000 Dec  5 18:24 /usr/lib/slack/libvulkan.so.1
-rwxr-xr-x 1 root root     68192 Jan  7 10:08 /usr/local/aws-cli/v2/2.22.29/dist/libbz2.so.1
-rwxr-xr-x 1 root root     32328 Jan  7 10:08 /usr/local/aws-cli/v2/2.22.29/dist/libffi.so.6
-rwxr-xr-x 1 root root     88720 Jan  7 10:08 /usr/local/aws-cli/v2/2.22.29/dist/libgcc_s.so.1
-rwxr-xr-x 1 root root    157440 Jan  7 10:08 /usr/local/aws-cli/v2/2.22.29/dist/liblzma.so.5
-rwxr-xr-x 1 root root  38139280 Jan  7 10:08 /usr/local/aws-cli/v2/2.22.29/dist/libpython3.12.so.1.0
-rwxr-xr-x 1 root root   1427096 Jan  7 10:08 /usr/local/aws-cli/v2/2.22.29/dist/libsqlite3.so.0
-rwxr-xr-x 1 root root     20064 Jan  7 10:08 /usr/local/aws-cli/v2/2.22.29/dist/libuuid.so.1
-rwxr-xr-x 1 root root     90160 Jan  7 10:08 /usr/local/aws-cli/v2/2.22.29/dist/libz.so.1

What I'm getting at is that I don't know
a. why we generally install libraries with execute bit set
b. why we do not consider libraries without the execute bit for dependency resolution.

[luhring]

This sounded eerily familiar, so I dug up a few times "whether a lib is executable" is mentioned in case it helps add context to this discussion...

1. Shared Object not being discovered by split/dev #321 (comment)
2. SCA Bug with libcap #920 (comment)

[jonjohnsonjr]

Yeah we should probably drop this check for libraries. I'm interested in what the diff looks like of a global melange scan of everything.