Bug 89764

How does the key get grabbed?  How does the interact with people who modify
their installation media to add site-local packages? 

> How does the key get grabbed?

Red Hat key, with which most likely a bulk of rpm packages will be signed
is on installation CDs in a file called RPM-GPG-KEY.  It does not seem
to be overly difficult for an installer to fetch it from there.

If installation happens over a network from loop mounted CD images then
the file is still present.  In case it cannot be found then keys are not
imported - obviously enough - but still one can look around a bit.

> How does the interact with people who modify their installation media
> to add site-local packages?

You mean that local packages were added but RPM-GPG-KEY was skipped or
does not contain GPG keys anymore?  The same as in the case of a network
installation.  If not present then keys are not installed.

If a question is that about extra packages which are not signed or a key
is missing then you need to leave the matter to resolve to whomever
is responsible for local modifications.   I do not see a need for any
interaction whatsoever.  It should not even be one in case of kickstart
installs.  If keys can be imported then great; otherwise we are in the
situation like now - they are left alone.
 

That doesn't really add a whole lot of trust, which is the entire reason the
keys exist in the first place.

Which is why this problem keeps coming up and I keep saying I'll do it as soon
as I can come up with a way to do it that doesn't completely reduce the level of
trust implied in signing packages to nil.

So how anaconda importing keys from a CD differs from me importing
keys from the same CD?  That is also a reason why I was talking about
some form of digest which anaconda can use to confirm that keys are
as expected.

If you mean that somebody re-hacked the whole distribution media and
an installer then you will get signature failures on rpm files presumably
coming from legitimate sources.  How does this differ from what we
have right know.  I can, of course, have few different keys corresponding
to different signatures.  These should not pretend that they are for
the same packaging entity, of course.

If the above is not good enough then rpm complaining about signatures,
like in bug #78948, seems to be at least misguided.

I can see two differences, Michal:
a) some people may not want to add the Red Hat key
b) when you do so, you can check the fingerprint (which is mentioned
   in all volumes of Red Hat Linux documentation)

BTW, doesn't up2date offer installing the key in firstboot?
My RHL9 box is not on the net, so I can't check, but I thought so...

> a) some people may not want to add the Red Hat key

Good point although it is hard to imagine for me valid reasons.
OTOH anaconda could offer to add such keys - if they can be found,
they check and are not already imported.  There is a number of things
(say MD5 passwords) about which a user is asked.  If such offer would
be declined then at least this would take out some mystery edge from
later "NOKEY" warnings.

At a minimum a note could be printed in some moment explaining what
all of this is about, and what should be done - including a verification
of what was already installed, without really doing anything else.

Kickstart can either skip that (presumably people using kickstart
are more likely to know what is happening) or have a config
option to govern.

> BTW, doesn't up2date offer installing the key in firstboot?

Well, very far from everybody is using up2date for various reasons
and why objections of doing that in an installer do not apply to
the firstboot?  Nothing ensures that you have already a full network
connectivity at that time.

Yes, I know that all security is a headache. :-)