[Rpm-ecosystem] why do elf dependency generators cover libraries in paths outside of the library load paths?

[Dmitry V. Levin]

On Fri, Dec 03, 2021 at 07:53:42PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> We had an incident today [1] that opae-devel has auto-generated provides
> like libcrypto.so.1.1()(64bit), generated for the bundled copy of openssl
> (/usr/lib/python3.10/site-packages/pacsign/hsm_managers/openssl/library/libcrypto.so).
> It was pulled into the buildroot instead of the expected openssl1.1 package.
> Those deps are generated by /usr/lib/rpm/elfdeps, which is configured in
> /usr/lib/rpm/fileattrs/elf.attr to act on anything that matches the
> file magic of '^(setuid,? )?(setgid,? )?(sticky )?ELF (32|64)-bit.*$'.
> 
> My question: shouldn't we limit the elfdeps generator to files which
> are in paths that can be loaded automatically by the linker? (This
> could be implemented as e.g. the paths that are default like
> /usr/lib64, /usr/local/lib64, …, depending on the architecture, and if
> the package installs anything in /etc/ld.so/, also the paths listed there.)

Back in 2006, I implemented the following semantics in ALT Sisyphus:
when Provides and Requires are generated for ELF shared libraries outside
of standard places searched by the dynamic linker, their directory prefix
is added, e.g.

$ rpmquery --provides -p firefox-94.0.2-alt1.x86_64.rpm |grep -F libmozsandbox.so
/usr/lib64/firefox/libmozsandbox.so()(64bit) = set:hd93tnnyHiEk678Zuue9vzWzvyhOXoj2

Hope this helps.


-- 
ldv