Ralf Ertzinger wrote:
Hi.
Jay Turner <jkt@xxxxxxxxxx> wrote:
There's a hierarchy there. Step 1 is validating that the signing key
you have indeed came from the source you think it did (in this case Red
Hat.) Once you establish that it's a known entity, then all of the
packages on the Red Hat media (be it RHEL or Fedora) are signed with
that key, so at that point you know that all of the packages originated
from Red Hat as well (or the Fedora project in the case of Fedora.) So
you don't "have to trust the media [you] install from anyway" as the
that content can be verified just as the key itself can.
OK, I think there is a slight misunderstanding. I did not mean to say that I will swallow everything that says "Fedora Core 3 DVD" (or whatever) on it and treat it as genuine. I can download it from anywhere, and check the published checksums (which are signed) against my image. Leaving discussions about hashing algorithms aside, I have thus established that my media is good. So is the key, which is included on the media.
So we have two cases:
1) People who check that the media is genuine (signed checksums), and thus trust the media, and trust the keys on it, so the keys can be imported by the installer.
2) People who do not check the media (or have it checked by their admin or another knowledgeable person), and can so be persuaded to install almost anything. If the media is compromised, all bets are off, anyway. If the media is genuine nonetheless, they get the keys they need to trust the automatic updates (which is a good thing, in my book).
Yep, the above points are two rational analyses of "trust" wrto signed packages.
There are other definitions of "trust" however, some less rational than others.
Maybe I am missing something here.
In general, public keys cannot be automagically imported without violating
some user's definition of "trust", and hence the --import procedure is manual, or asks
"Ok to import(Y/n)?", in order for the end-user to confirm that the mechanism of
signed packages is consistent with the end-user's definition of "trust".
No matter what, "existence" of public key in key ring, needs to be separated from
"trust" of the public key itself in order to attempt automagic public key import.
The trust bits already exist within RFC2440 packets, what remains to be done is
to add a mechanism to change the bits, and then teach rpm to pay attention to the bits.
73 de Jeff