Hi,
On Mon, 2021-10-25 at 15:09 -0400, Ben Cotton wrote:
I like this idea. It will be really useful when multiple distros adopt
it.
It isn't immediately clear to me which of the key's will be included.
The format describes 6 standard ones: type, os, osVersion, name,
version, osCpe and debugInfoUrl. But the example given later only shows
type, name, version and osCpe.
To me the debugInfoUrl is the most interesting because combined with
the already existing build-id note it allows automagic fetching of the
debuginfo and sources (and the debuginfod server could tell you the
type, name and version of the archive, so in theory you don't have to
include those fields, but they might still be useful if you cannot
access the debuginfod url).
The general spec doesn't make any field mandatory intentionally, as different
consumers/producers might have different needs. One of the advantages of using JSON as a
format is that it's self-describing, so you don't need to.
I guess from a distro-specific implementation point of view you'd want at least:
- type
- name
- version
- architecture
As that allows you to pint-point with reasonable accuracy I think? Throw in the OS name
(ID or CPE from os-release) to ensure there are no possible ambiguities. debuginfo server
sounds also something that would be useful for a generic-purpose distro like Fedora or
Debian, absolutely.
One ELF technicality I don't see described is the alignment and
padding
of the ELF NOTE. Normally on GNU systems ELF NOTEs are aligned on 4
bytes (for both 32/64 bit ELF files). But the recent .note.gnu.property
NOTEs are aligned on 4 bytes for 32bit systems, but 8 bytes on 64bit
systems (this is causing some interesting issues trying to combine
those NOTEs...). What alignment/padding will this new ELF note have?
Thanks,
Mark
4 bytes alignment is shown in the examples:
https://systemd.io/COREDUMP_PACKAGE_METADATA/
But yes, it should be specified I think, I'll add an explicit mention of it. It should
also be read-only, otherwise there are problems consuming it.