On Wed, Apr 21, 2021 at 03:15:23PM -0400, Frank Ch. Eigler wrote:
Björn Persson <Bjorn(a)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.
We have btrfs now… It's not exactly the same, but it provides protection
against the most likely corruption scenario — disk errors.
> [...] 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.
It is equivalent in the following sense: if the server is compromised,
it can serve any data it wants, and the client has no chance of
knowing.
Zbyszek