On Wed, Oct 27, 2021 at 09:41:05PM +0200, Miroslav Suchý wrote:
Dne 27. 10. 21 v 21:35 Luca Boccassi napsal(a):
>>??? The build-id can be
>>always retrieved from the dnf repository.
>>
>>Miroslav
>Which dnf repository? What if it's not dnf but apt? Or zypper? What if it's
none? How do you know?
In repository in general (can be deb, zypper, local directory). Even the
offline systems have some repository where they get the packages from.
I tried to answer that in the Change text.
tl;dr: yes, it's possible, but often hard in practice.
Quoting
https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects...
When the need to introspect a binary arises, we have some very good
mechanisms to show the provenance: when a file is installed through
the package manager we can directly list the providing package, but
even without this we can use build-ids embedded in the binary to
uniquely identify the originating build. But those mechanisms work
best when we're in the realm of a single distribution. In
particular, build-ids can be easily tied to a source rpm, but only
when the source rpm is part of the distribution and the build-id was
registered in the appropriate database which maps build-ids to real
package names. When we move outside of the realm of a single
distribution, it can be hard to figure out where a given binary
originates from. If we know that a binary is from a given
distribution, we may be able to use some distro-specific mechanism
to figure out this information. But those mechanisms will be
different for different distributions and will often require network
access.
The directly motivating use case is display of core dumps. Right now
we have build-ids, but those are just opaque hexadecimal numbers
that are not meaningful to users. We would like to immediately list
versions of packages involved in the crash (including both the
program and any libraries it links to). It is not enough to query
the rpm database to do the equivalent of rpm -qf …: very often
programs crash after some packages have been upgraded and the
binaries loaded into memory are not the binaries that are currently
present on disk, or when through some mishap, the binaries on disk
do not match the installed rpms. A mechanism that works without rpm
database lookup or network access allows this information to be
showed immediately in coredumpctl listings and journal entries about
the crash. This includes crashes that happen in the initrd and
sandboxed containers.
A second motivating use case is when users distribute their own
binaries and would like to collect crash information. Build-ids are a
solution that is technically possible, but easy to get wrong in
practice: users would need to immediately record the build-id after
the build and store the mapping to program names, versions, and build
number in some database. It's much easier to be able to record
something during the build in the build product itself.
A third motivating use case is the general mixing of Fedora binaries
with programs and libraries from different distributions, both with
our binaries being used as the base for foreign binaries, and the
other way around. Whilst most distributions provide some mechanism
to figure out the source build information, those mechanisms vary by
distribution and may not be easy to access from a "foreign" system.
Such mixing is expected with containers, flatpaks, snaps, Python
binary wheels, anaconda packages, and quite often when somebody
compiles a binary and puts it up on the web for other people to
download.
Zbyszek