status of up2date and rhn-applet
Michael Wiktowy
mwiktowy at gmx.net
Sun Nov 27 21:07:45 UTC 2005
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.
/Mike
More information about the fedora-devel-list
mailing list