Re: [Rpm-ecosystem] why do elf dependency generators cover libraries in paths outside of the library load paths?
On Fri, Dec 03, 2021 at 07:53:42PM +, 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 ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
[Rpm-ecosystem] why do elf dependency generators cover libraries in paths outside of the library load paths?
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.) I always understood those Provides/Requires to be used for library dependency resolution, and it doesn't seem to make sense to generate them for plugins and other "private" objects outside of the linker load paths. I think it's much much more common to have .so libraries outside of the linker paths for which we don't want the automatic provides (python modules, java extensions, various loadable plugins), than to have shared libraries in some custom directory. This should eliminate most of the stupid issues where a "private" dependency leaks and breaks other packages. [1] bugzilla.redhat.com/2028852 Zbyszek ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] why do elf dependency generators cover libraries in paths outside of the library load paths?
On Fri, Dec 3, 2021 at 3:10 PM Miro Hrončok wrote: > > On 03. 12. 21 20:53, 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.) > > > > I always understood those Provides/Requires to be used for library > > dependency resolution, and it doesn't seem to make sense to generate > > them for plugins and other "private" objects outside of the linker > > load paths. > > > > I think it's much much more common to have .so libraries outside of > > the linker paths for which we don't want the automatic provides > > (python modules, java extensions, various loadable plugins), than to > > have shared libraries in some custom directory. This should eliminate > > most of the stupid issues where a "private" dependency leaks and > > breaks other packages. > > > > [1] bugzilla.redhat.com/2028852 > > As one of the Fedora's Python maintainers, I fully support the idea of only > generating provides from "normal" library directories. > > We still have Python packages that accidentally provide stuff like: > > lib.cpython-310-x86_64-linux-gnu.so()(64bit) > libcalignedsegment.cpython-310-x86_64-linux-gnu.so()(64bit) > libcalignmentfile.cpython-310-x86_64-linux-gnu.so()(64bit) > libcbcf.cpython-310-x86_64-linux-gnu.so()(64bit) > libcbcftools.cpython-310-x86_64-linux-gnu.so()(64bit) > libcbgzf.cpython-310-x86_64-linux-gnu.so()(64bit) > libcfaidx.cpython-310-x86_64-linux-gnu.so()(64bit) > libchtslib.cpython-310-x86_64-linux-gnu.so()(64bit) > libcsamfile.cpython-310-x86_64-linux-gnu.so()(64bit) > libcsamtools.cpython-310-x86_64-linux-gnu.so()(64bit) > libctabix.cpython-310-x86_64-linux-gnu.so()(64bit) > libctabixproxies.cpython-310-x86_64-linux-gnu.so()(64bit) > libcutils.cpython-310-x86_64-linux-gnu.so()(64bit) > libcvcf.cpython-310-x86_64-linux-gnu.so()(64bit) > libexiv2python.cpython-310-x86_64-linux-gnu.so()(64bit) > libguestfsmod.cpython-310-x86_64-linux-gnu.so()(64bit) > libhivexmod.cpython-310-x86_64-linux-gnu.so()(64bit) > libiscsi.cpython-310-x86_64-linux-gnu.so()(64bit) > liblo.cpython-310-x86_64-linux-gnu.so()(64bit) > libpyuhd.cpython-310-x86_64-linux-gnu.so()(64bit) > libtorrent.cpython-310-x86_64-linux-gnu.so()(64bit) > > (This is actually from Fedora Rawhide, as of today.) > The issue is self-Requires. Because the RPM dependency generator doesn't cancel out self-Requires, filtering out Provides leads to broken Requires in a lot of cases. -- 真実はいつも一つ！/ Always, there's only one truth! ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
