On Wed, Apr 21, 2021 at 4:09 PM Frank Ch. Eigler fche@redhat.com wrote:
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.
I think there *are* solutions that reduce the attack surface so that the public facing server no longer needs to be trusted.
Service 1: indexes signed debuginfo files in Fedora, verifying RPM signatures, puts the object IDs and hashes into a Merkle tree [Root node of Merkle tree is signed] Service 2: serves out those debuginfo files to clients, along with root signature and the nodes from the root to the file of interest
But I don't want to see this proposal blocked on implementing something that technically complex - I think it offers big benefits to Fedora users as is. Certainly there are other programs that are typically run without sandboxing by developers and connect to network services - even entirely untrusted network services - and we typically consider that acceptable.
Owen