Björn Persson <bj...@xn--rombobjrn-67a.se> writes: >> https://sourceware.org/bugzilla/show_bug.cgi?id=27758 > > The design you propose there won't improve anything for anyone. If the > hash is computed on the debuginfo server, then an attacker who can make > the server serve malicious debuginfo can also make it serve hashes that > match the malicious files.
Yes, this does not provide protection against a penetrated server. It does not claim to. > And as you noted yourself, an attacker who can manipulate cached files > client-side has already taken over the user account anyway. Yes and no, and so I must disagree with your "won't improve ... for anyone". The proposed client-side verification is roughly analogous to running "rpm -V" on a machine. Yes, if an attacker has control at that moment, it's not reliable. Nevertheless, to detect residue of a -previous attack- or accidental data corruption, it can be worthwhile. > [...] I see that debuginfod.fedoraproject.org is currently another > name for koji.fedoraproject.org. They are separate VMs, if that's what you mean. (You may be confused by use of a number of shared HTTP front-end proxies.) > Given that it serves debuginfo only for Fedora packages, and does not > forward requests to any other debuginfo servers, using this server > seems equivalent security-wise to downloading unsigned packages from > Koji. Not exactly. All the data is -from- signed packages. > To make the debuginfo protocol as secure as signed debuginfo packages, > the client should verify the files against a hash computed and signed > on the signing server. If the threat model includes a -local active attacker-, then this would not help either. An attacker could interfere with the local keystore and/or trust chains and/or signature verification software. > For those who are concerned about privacy, the proposal would make > that problem worse as it would cause the "phoning home" to happen > every time they debug something. That's if they wish to rely on live verification. Note that the privacy being leaked consists of the hex buildid of the program being debugged, and an elfutils#/fedora#/arch, and of course IP address. It's not nothing, but it's nothing more. It's roughly equivalent to the dnf-automatic.timer call-home in this respect. > By the way, the change page still doesn't say enough about how network > problems will affect the user experience. [...] I'm not sure why you say "still" when this question was not posed here before. I will add some text on this. - FChE _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
