[Bug debuginfod/30978] debuginfod-client security: optionally(?) verify downloaded binaries

2023-10-18 Thread rfhn.fhbrrjnzeneqpf at noclue dot notk.org
https://sourceware.org/bugzilla/show_bug.cgi?id=30978 --- Comment #5 from Dominique Martinet --- debian has kept .gnu_debuglink (like fedora), so if we extend that to store a more reliable hash I believe that process should be fairly straightforward as they already must have an objcopy --add-gnu-

[Bug debuginfod/30978] debuginfod-client security: optionally(?) verify downloaded binaries

2023-10-18 Thread fche at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=30978 --- Comment #4 from Frank Ch. Eigler --- Note that the main problem with this sort of scheme is not the checksum (whether CRC or a hash). That part can help provide some assurance against accidental corruption. (Plus you'd need external chec

[PATCH] debuginfod PR29472: metadata queries

2023-10-18 Thread Frank Ch. Eigler
Hi - This patch, mostly the work of Ryan Goldberg, has undergone some decent testing alongside its systemtap consumer (which is already merged). If there's interest, I could install it speculatively on one of the fedora debuginfod servers, the one that's already running its prerequisite RPM-IMA p

[Bug libdw/30980] offline.c:53: dwfl_offline_section_address: Assertion `mod->e_type == ET_REL' failed.

2023-10-18 Thread mark at klomp dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=30980 --- Comment #4 from Mark Wielaard --- O, apparently systemd isn't updated on freedesktop.org anymore. So my git repo is stale. The copy on github (sigh) does have those files and the parse_core function. The dwfl setup is done with:

[Bug libdw/30980] offline.c:53: dwfl_offline_section_address: Assertion `mod->e_type == ET_REL' failed.

2023-10-18 Thread mark at klomp dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=30980 --- Comment #3 from Mark Wielaard --- Would you happen to know where systemd-stable/src/coredump/coredump.c and systemd-stable/src/shared/elf-util.c come from? I am trying to figure out how the dwfl has been setup that parse_core uses, but I c

[Bug libdw/30980] offline.c:53: dwfl_offline_section_address: Assertion `mod->e_type == ET_REL' failed.

2023-10-18 Thread mark at klomp dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=30980 --- Comment #2 from Mark Wielaard --- This however is really odd and might explain why we get onto an ET_REL path: $ eu-readelf -x .gnu_debuglink ~/Downloads/libjavascriptcoregtk-4.1.so.0.4.10.zst Hex dump of section [28] '.gnu_debuglink', 8

[Bug libdw/30980] offline.c:53: dwfl_offline_section_address: Assertion `mod->e_type == ET_REL' failed.

2023-10-18 Thread mark at klomp dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=30980 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #1

[Bug libdw/30980] New: offline.c:53: dwfl_offline_section_address: Assertion `mod->e_type == ET_REL' failed.

2023-10-18 Thread cebtenzzre at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=30980 Bug ID: 30980 Summary: offline.c:53: dwfl_offline_section_address: Assertion `mod->e_type == ET_REL' failed. Product: elfutils Version: unspecified Status: UNCONFIRMED