You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I came across this project thanks to @AevaOnline who talked about this at MSFT, it looks super interesting. I noticed there's a bit of overlap in one implementation detail with a project we've now deployed on Fedora 36 and Mariner 2.0.
As far as I understand, the idea behind git-bom is to be able to look at a binary on a system and have a unique and reliable answer to the question "what went into the making of this binary". In the project I worked on, the idea was looking at a binary (or a core file) and have a unique and reliable answer to the question "where did this binary come from and who made it". It sounds very similar to me!
What we came up with was the "Package Metadata" specification. It established an (extensible!) format to let binary builders embed various metadata in an ELF file, with care into ensuring the metadata would be automatically included in a core dump, so that core files would be identifiable too.
Long story short, we have a reserved ELF note (ID and owner are now recognized by glibc, binutils, elfutils, etc), and payload format as a json string. We have a few recommended key/value pairs, but it is very much designed to be up to the builder what to include.
So the question is, would it make sense to add the bom id as a key/value pair via this existing note, to take advantage of the established spec and the fact that it's already in use in the wild?
The reason I ask is not because of the implementation cost - stamping an ELF is very easy (well, lots of gotchas, but still easy). The really, really, really difficult part is convincing projects to adopt it, and use it universally. Fedora 36 and Mariner 2.0 are already using the Package Metadata spec, the vast majority of binaries shipped by these distros will include this new ELF note. We will try to get it included in more distributions going forward.
Hello,
I came across this project thanks to @AevaOnline who talked about this at MSFT, it looks super interesting. I noticed there's a bit of overlap in one implementation detail with a project we've now deployed on Fedora 36 and Mariner 2.0.
As far as I understand, the idea behind git-bom is to be able to look at a binary on a system and have a unique and reliable answer to the question "what went into the making of this binary". In the project I worked on, the idea was looking at a binary (or a core file) and have a unique and reliable answer to the question "where did this binary come from and who made it". It sounds very similar to me!
What we came up with was the "Package Metadata" specification. It established an (extensible!) format to let binary builders embed various metadata in an ELF file, with care into ensuring the metadata would be automatically included in a core dump, so that core files would be identifiable too.
Long story short, we have a reserved ELF note (ID and owner are now recognized by glibc, binutils, elfutils, etc), and payload format as a json string. We have a few recommended key/value pairs, but it is very much designed to be up to the builder what to include.
So the question is, would it make sense to add the bom id as a key/value pair via this existing note, to take advantage of the established spec and the fact that it's already in use in the wild?
The reason I ask is not because of the implementation cost - stamping an ELF is very easy (well, lots of gotchas, but still easy). The really, really, really difficult part is convincing projects to adopt it, and use it universally. Fedora 36 and Mariner 2.0 are already using the Package Metadata spec, the vast majority of binaries shipped by these distros will include this new ELF note. We will try to get it included in more distributions going forward.
Details:
https://systemd.io/COREDUMP_PACKAGE_METADATA/
https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects
https://lwn.net/Articles/874642/
The text was updated successfully, but these errors were encountered: