On January 6, 2005 04:21 pm, Matthew Miller <mattdm(a)mattdm.org&gt; wrote: yum just tells you that there's no GPG key for the package. It does not tell you how to fix the problem. -- Mark Lane, CET -- mailto:mark@harddata.com Sales Manager -- Hard Data Ltd -- http://www.harddata.com T: 01-780-456-9771 -- F: 01-780-456-9772 11060 - 166 Avenue Edmonton, AB, Canada, T5X 1Y3 --> Ask me about our New Dual and 4 Way Blade Servers <--

Short version of the plan for this list: Menno Smits has been so kind as to write code that does this: if you have gpgcheck=1 set to on in your repo config it looks for a path to a gpg key in the global settings and/or the repo configuration. If it finds the key and you've not already imported the key into your rpmdb, it will confirm that you want to import it and do so. if you don't choose to import it then, well, that's your problem. -sv

Hi. Florin Andrei <florin(a)andrei.myip.org&gt; wrote: I'm sure there is a good reason why the keys are not imported by the installer by default, would someone be so kind to tell me why? -- University degrees are a bit like adultery: you may not want to get involved with that sort of thing, but you don't want to be thought incapable. -- Sir Peter Imbert

Hi. Jay Turner <jkt(a)redhat.com&gt; wrote: Well, I generally have to trust the media I install from anyway, so what is the point in treating a single file different from all the others?

On Fri, Jan 07, 2005 at 01:25:25PM +0100, Ralf Ertzinger 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. A good analogy would be your house/apartment/flat. In order to be secure, you more than likely make sure that the windows and exterior doors of the place are secure, and not bother to secure all of the interior doors as well. That's because if a thief can't get through the exterior protection, there's no reason to worry about him getting through the interior protection. Same thing with the software. If you know that the key that signed all of the packages is "good", and you know that all of the packages are signed with the "good" key, then you know that all of the software resulting from that install is also "good" (from a trusted standpoint.) - jkt -- --*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--* Jay Turner, QA Technical Lead jkt(a)redhat.com Red Hat, Inc. If I had only known, I would have been a locksmith. - Albert Einstein

Ralf Ertzinger wrote: 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. 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

Jay Turner wrote: If someone has enough access to insert their own public key into the pre-install image, they also have enough access to modify rpm to do their evil bidding, with our without keys. The install image *must be trusted* if anything can be trusted at all. Let me say that again, because it's critically important. If you can't trust the install image, all other bets about security are off. Your box has been r00ted-- reformat, reinstall; there are no other options. Furthermore, for the average user, it's actually *less* secure to have them import the key manually, because: * There's an added opportunity for a malicious user to add their own key in place of the "real" one between when the OS is installed and when the key is imported. The number of users who actually *do* check key fingerprints is so absurdly small that it might as well be zero. It may look more secure on paper, but in practice (where security really matters) it's worse. * Many users simply disable key checking to avoid the hassle of importing the keys manually. This isn't a "some user might" sort of hypothesis--I've witnessed it myself on multiple occasions. It *does* happen. If web browsers forced the user to import all the root CA certs right after install, web security would be a joke. There would be no real guarantee of trust. You simply can't rely on the end user to set up his local security infrastructure correctly. Sure, you could tell grandma to be careful and verify all the certificate fingerprints before importing them, but how likely is that going to be? The average end user doesn't care about security until it all hits the fan. Our job is to keep that from happening, despite their best efforts to thwart us. If security is your reason for requiring this extra step, then quit it. It isn't helping. If keys in the keyring upon system install can't be trusted, then nothing at all about the system can be trusted.