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