Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> writes: > OTOH, the debuginfo files distributed through the debuginfod server > are not signed and there is no direct way to verify that they match > the (signed) contents of the debuginfo package. A direct way would be for someone to koji-download the given rpm, and hand-extract/compare the files. (It's obviously not economical.) > Thus, the debuginfod server becomes a juicy target. Yes. The Changes FAQ section discusses this topic. Unfortunately, in the absence of per-file signatures generated by the build system, and securely distributed out-of-band, I can't think of any way to provide client-side verifiability of a debuginfod type service. That's independent of any particular level of server code robustness. Interestingly, if debuginfod were considered *trusted*, then it could be used as the *basis* for such a capability, because the client-side hash verification feature being prototyped. It would serve trusted hashes to RPM-based artifacts on demand. - FChE _______________________________________________ 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
