Description of problem: On a freshly installed system a user trying to add or update any rpm will be greeted with a somewhat mysterious warning "... V3 DSA signature: NOKEY, ...". This was already reported as #78948 and closed with NOTABUG. This is correct but not very helpful for somebody running into that for the first time. Anaconda could and should import the well known Red Hat key as a part of the whole installation process - at least when doing installs from CDs. Even when installing over networks if such key is available it could be imported. Checking a digest for a well known key does not seem to be too onerous task. I guess that even during updates an offer to import keys if they are not already present should be doable.
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. :-)