Re: Secrecy and user trust

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

 



* jdow <jdow@xxxxxxxxxxxxx> [20080905 20:52]:
> From: "Anders Karlsson" <anders@xxxxxxxxxxxxxx>
> Sent: Friday, 2008, September 05 00:50
>
>
>> * jdow <jdow@xxxxxxxxxxxxx> [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.

You had no OS installed - so where did you get the media from?
The only thing that matters at this point is whether you do, or not,
trust the media you are installing from? If you do - then you will
have a good key on the media that will validate updates later.

>> 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.

Mu.

The Fedora installation media installs repo configs that point to the
Fedora projects servers. Your comment indicates that you believe your
ISP and the DNS servers you use are compromised. At this point - all
bets are off.

>> 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.

This is what the infrastructure team have been working on, and reading
the fedora-devel list should give answers to the plans that they have.

It would appear that you can only sign a package with a single key at
a time. I just tested it.

[snip]

> 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.

It appears the answer is no. Only one signature at a time. This is one
of the problems the infrastructure team have been wrestling with.

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

It would appear the discussion is not entirely spurious. ;-)

/Anders

-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux