Frank Ch. Eigler wrote: > Björn Persson writes: > > > · How is it verified that files received from debuginfo servers have not > > been tampered with? > > Following up further to this, we're planning to add optional client-side > hash-verification of cached content, to provide some protection against > tampering: > > 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. And as you noted yourself, an attacker who can manipulate cached files client-side has already taken over the user account anyway. Quote from Sourceware Bugzilla: > As transport over HTTPS protects the content, we can safely assume > that immediately during/after the download, the content will be fine. > However, what of cached files? Of course – from your point of view. From my point of view, I can safely assume that nobody has tampered with my cache. However, what of files on the debuginfo server? I see that debuginfod.fedoraproject.org is currently another name for koji.fedoraproject.org. 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. As far as I understand, packages are built and signed on separate servers with a smaller attack surface than the web front-end to minimize the risk that an attacker could tamper with them. 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. Perhaps a hash of the debuginfo could be stored in a signed RPM package, either the main package or a separate debughash package? 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. By the way, the change page still doesn't say enough about how network problems will affect the user experience. Making a previously offline activity network-dependent also makes it sensitive to network problems. For example, if great packet loss causes TCP timeouts or long delays, will that make GDB hang for minutes at a time, or is it handled asynchronously? Will GDB hang once per process, once per login session, or every time it encounters a new source filename? Björn Persson
Attachment:
pgpxgacm4r7Pz.pgp
Description: OpenPGP digital signatur
_______________________________________________ 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
