On Mi, 03.11.21 15:00, David Sastre (d.sastre.medina@xxxxxxxxx) wrote: > - There are a few existing formats for software identification and SBOMs: > - SPDX[2], used in the example spec in the proposal > - SWID tags[3][4] > - OWASP CycloneDX[5] > - CPE[6], used in the example JSON above > - PURL[1] > - probably more :D I was aware of some of these, in particular CPE. One of our goals here is to encode data in the most obvious way though, i.e. stay as close to what the native package manager of the distro does and how it names things, as we can, to make things easy and mapped directy and not needlessly pile specs on top of specs. i.e. the goal is not "decoration" if you so will but directly usable fields whose data you can pass immediately to the package management tools and they do useful stuff. I think some of the listed specs are fine (and I think it might even make sense to make dnf understand them natively, in select cases), but I am not convinced we should mandate them here, since our spec is intentionally simple and liberal in the field it contains: it should be up to the distro to figure out precisely the fields they want to populate, we just describe a small set of recommended fields and their values, in the most obvious way. (There's also the problem of chicken and egg: I think only two of the specs you listed gained supported outside of their respective niches, i.e. the SPDX stuff for licensing and the CPE stuff for marking OS versions. I doubt that this ELF spec is the right place to push them more widely, this ELF spec is too nichey for that in itself. Of course the fact that those specs are not widely used isn't improved by not using it here either, but I don't think this is the job of our ELF spec, if you follow what I mean.) So, the way I see it, the fact we use JSON makes it easy to add additional fields later. We'd welcome a PR to our spec that declares additional, optional fields for the more relevant specs you listed above. i.e. we are happy to extend the table at the end of: https://systemd.io/COREDUMP_PACKAGE_METADATA/ with more stuff. File a patch adding that here: https://github.com/systemd/systemd/pulls Once you got these field is into the upstream spec, the next step would be to convince the distros to actually populate the fields though, but I think that should happen independently of our current fedora ELF feature. And it should probably not only entail that these fields are included in the coredumpable metadata, but probably also that the distro package management tools can parse/generate them natively. In fact that's probably the priority, the coredumpable part should be secondary to that. > [3]: http://standards.iso.org/iso/19770/-2/2015-current/schema.xsd broken link. > [4]: > https://csrc.nist.gov/schema/swid/2015-extensions/swid-2015-extensions-1.0.xsd broken link. Lennart -- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
