On Sun, 2005-11-27 at 16:07 -0500, Michael Wiktowy wrote: > On Sun, 2005-11-27 at 15:29 -0500, seth vidal wrote: > > 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. > > Well ... that is where the wizening of the users comes in :] > > This ties in with the concept of Union layers that Arjan van de Ven > presented in the "Re: suggestion: move all java packages to extras" > thread. Do we want layers that are higher up/more specialized have the > ability to: > 1) Override lower layer packages automatically > 2) Ask to over ride them > 3) Never override them > > Right now it is option #1. > > > 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. > > I am suggesting the move to option #2 would be better. > > > 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. > > OK ... I expected a "put some code where you mouth is" response and that > is fair. I am not much of a coder but this will give me some reason to > learn python so I will give it a try. I would appreciate some guidance > to documentation/sites/example code where I could research the yum > plugin structure. For now I will start reading though the yum-devel > list. > /usr/share/doc/yum-2.4.0/PLUGINS look in the yum-utils package for example plugins. and: http://wiki.linux.duke.edu/YumPlugins -sv -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
