Re: status of up2date and rhn-applet

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux