Re: F35 Change: Debuginfod By Default (Self-Contained Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Apr 21, 2021 at 03:15:23PM -0400, Frank Ch. Eigler wrote:
> 
> Björn Persson <Bjorn@xxxxxxxxxxxxxxxxxxxx> 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
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux