On Wed, Apr 21, 2021 at 4:09 PM Frank Ch. Eigler <fche(a)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