Ralf Ertzinger wrote:
Hi.
Jay Turner <jkt(a)redhat.com> 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.
Maybe I am missing something here.
There are other definitions of "trust" however, some less rational than
others.
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