On Sun, 2005-11-27 at 15:20 -0500, Michael Wiktowy wrote: > On Sun, 2005-11-27 at 10:05 -0500, seth vidal wrote: > > > Handling it like the key checking that ssh does (with a warning and an > > > option to continue) might be the way to go. > > > > yum does that now. It asks you if you want to import the key and you > > have to press y or n. > > Not quite what I was referring to. I am talking about long after you > have accepted a key initially and the key is added to your > ~/.ssh/known_hosts file. The check that I refer to is the one where the > host presents a key and you have a different one in the known_hosts file > for that host. ssh complains *very* loudly and gives a clear indication > why this is an issue (MITM attack). and what do most users do if asked how to deal with this problem? they just accept it and move along, not noticing at all that they consented to a possible man in the middle attack. So it defeats the purpose a bit. Don't get me wrong. I see where you're coming from. You want to make sure that the key or keys signing any given package is the same key that's on the package already installed. I get where you're coming from - I'm just not sure it makes sense at some point. Here's an idea for you - implement this as a yum-plugin. Post-download-package you can check the set of where things are coming from and compare gpg keys from there. see how much traction/interest you get from there. -sv -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
