Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl> 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