On Do, 28.10.21 15:10, Neal Gompa (ngomp...@gmail.com) wrote: > It is not enough. It's not enough in *any* distribution, because > people can (re)build and deploy the same NEVRA. You *need* a > build-id to guarantee uniqueness of the binary. If the NVR is the > same but the build has been modified, the build-id changes.
Yes, some hackers rebuild stuff locally, I think it's not something to be concerned about too much though. It's not the common case, and the people doing that are probably technically proficient enough to not report bugs for crashes they collect that way or at least will quickly recognize if things go wrong that tway. Build-Ids are not going to go away. You can use them in combination if you like. For automated bug reporting/server side processing it's probably a good idea to automatically verify build ids too and then filter out stuff where nevra and build ids don't match up. > > Finally, as Mark said, with this scheme you can actually enable what you > > propose for the cases where it's possible, because as part of the metadata > > file you can include the debuginfod URL. Please think bigger picture than > > single distro: maybe the entity that created the binary uses the federated > > service so the build-id is enough, but maybe it does not. > > > > Fedora can be a trailblazer as always and be one of the first adopters > > (although CBL-Mariner beat you folks for first place :-) ) but our desired > > goal is very much to have this enabled cross-distro, so that a Fedora > > container on a Debian host or whatnot still works out of the box. > > Even if we did this, it will be a long, long, long time before there > will be interop between Fedora and Debian. Yes, Debian is slow with things, but that's certainly not a reason to give up already before starting the process. Note that the spec is useful also if Debian doesn't ever come around to adopt the spec — even when we get coredump reports from debian compiled binaries! How so? simply because soon enough the absence of the annotation already tells us something too: that the crashing binary is certainly not from a recent fedora version, even if we can't determine where it actually *is* from. But that is already enough to quickly respond to the crash report and let the report know that this is almost certainly not a Fedora issue. Lennart -- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
