Frank Ch. Eigler wrote:
Björn Persson <Bjorn(a)xn--rombobjrn-67a.se> writes:
> 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 fail to imagine how you believe attackers operate to make the
distinction between an attacker who has control and a previous attack
relevant.
It can detect accidental data corruption, yes. If you want to checksum
the cache to detect accidental data corruption, that's fine by me, but
that's better done locally, so that the checksums can be verified
without contacting any server.
> 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.
Okay, so it's equivalent to downloading packages that were once signed,
but had the signatures removed before the packages were offered for
downloading – which is in turn equivalent to downloading unsigned
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.
A local active attacker who can already read, write and execute
whatever they want has nothing more to gain from tampering with cached
debuginfo.
> 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.
Because I posed the question in my first message in this thread, on the
11th.
Björn Persson