Secrecy and user trust

[jdow]

From: "Anders Karlsson" <anders at trudheim.co.uk>
Sent: Friday, 2008, September 05 00:50


>* jdow <jdow at earthlink.net> [20080905 08:56]:
>> Suppose I have NO RedHat installed. I have no working computer near
>> me. I want to install Fedora 9. How do I establish the ability to
>> subject the packages to tests for being properly signed, that the
>> key used in the test is correct, and that I am reading and updating
>> from a legitimate mirror?
> 
> In this event you are likely installing from physical media, which
> will have the public key on it already. If you do not trust that media
> - why are you installing from it?

Where did I get the media? How do I establish the chain of trust?
Perhaps I downloaded with an old copy of Red Hat 4.0 I had laying
around. If trust can be established from zero then it can happen
again.

> Once you have installed the system - the updates you are pulling down
> will be verified with the key that was on the media - unless you
> actively go and switch off the gpg checking.

If I am actually going to the right mirrors and not a setup of fast
flux servers full of malware that will be true.

> The part about how to distribute the new public key - that is the
> thing that the infrastructure team is debating how to best do now.
> 
> Nitpicking - it is spelled "Red Hat".

And I'd be likely installing Fedora these days.

>> If this can be done once in an initial install situation it can be done
>> again in an update situation using the same mechanism.
>>
>> {^_^} 
> 
> As others have already pointed out - it's a question of trust. At some
> point or other - you have to decide what you trust. If you do not
> trust something, do not use it (and then live with the consequences of
> that choice).

Exactly. This is the point. If I can proceed from zero and establish
trust once I can do it again. So I am unclear over what the problem
in that regard can be such that it would stall the process of getting
rolling again.

I can see other items causing a hitch in the gitalong. But I cannot
see any means other than trusting my DNS server and the routers
between download.fedora.redhat.com and me. If I could trust them once
I can trust them again. So the focus of this thread is wrong. It
should be more along the lines of "How can a company that uses RPM
and signed packages arrange to have the packages multiply signed so
that both an old obsolete key works and a new key works?"

THAT is probably not a simple problem. I also suspect it is not something
considered in designing rpm itself or the distribution system.

> If you decide not to trust passports, you will simply find it a bit
> hard to travel from country to country. If you don't trust the Fedora
> key, you'll find it a bit hard to use Fedora.
> 
> My view of the Fedora public key is that it is a means to verify the
> integrity of the packages coming from the Fedora repo's. That the
> package is originating from Fedora, and not from untrusted 3rd
> party and that the packages have not been tampered with in
> mid-flight. If you don't trust the method by which packages are
> downloaded, verified and installed by yum - maybe you'd trust going to
> the Fedora download site and grabbing the packages, one by one, and
> installing them by hand?
> 
> This is a potential solution actually. If you don't trust https:// to
> the download section of Fedora - you don't trust Fedora full stop. So
> providing a page with the new key, and instruction for what to change
> and how, on your system to point at the new repo's should satisfy even
> the most paranoid people on this list. As the packages are signed with
> the new key, and if you remove the old key - you should be OK. Right?

Personally I trust the connection between me and Red Hat or me and
Fedora - effectively the same thing. Tampering would have to be quite
comprehensive to keep me fooled for long enough to make it worth the
cracker's efforts. DNS is the easiest hole in the picture. And that
means the main root name servers would have to be changed. (I am being
a bad girl at the moment and am using them directly. I switched pending
hearing that DSLExtreme had completed their update. I've had other things
more pressing to do than change it back.) The second level hole is the
man in the middle attacking me specifically. "They ARE out to get me. But
it is nothing personal." It's not me specifically they are targeting. It's
people who present themselves as targets of opportunity. The attack in
this case would have to be so comprehensive that it beggars the imagination
for it to hold up past the first attempted update cycle.

If trust can be established once, it can be establised again the same way
as many times as needed. So the discussion needs to move to what may be
the REAL problem. Can an rpm be signed with multiple keys in any
meaningful way so that people pre-update can still grab the key updates
and compare files prior to a specific date against the old key while new
files compare against the new key.

If THAT can be done it seems like both this discussion and the delay
are somewhat spurious, right?

{^_-}