yum plugin suggestion or yum change?

Thomas M Steenholdt tmus at tmus.dk
Mon Dec 5 21:24:28 UTC 2005


Jeff Spaleta wrote:
> On 12/5/05, Thomas M Steenholdt <tmus at tmus.dk> wrote:
>> I guess that an important point is that one failing security update does
>> not make up for the rest of the equally important security updates not
>> getting installed.
> 
> who says they other updates are security... or that the other updates
> are equally important?  The tools has absolutely no information by
> which to make any relative judgement at all.
> 

Why does it matter. There is absolutely NO reason to stop well-behaving 
packages from being updated just because of one bad one (not fully 
synced mirror or whatever). Regardless which package may or may not be a 
high severity security update. It doesn't matter. If a high severity 
security patch fails with dependency problems, it's not going to install 
either way, but we should not interpret that as "Hmm, dependencies for 
this important update cannot be resolved. Lets ignore ALL security 
updates until that has been fixed". It's just not the best way security 
wise. I'd rather have 1 known security hole that I've been warned cannot 
be installed, than 35 (where the 34 are actually totally updatable if I 
do them my hand).

> 
>> If we have 10 security updates and one of these are failing. Wouldn't we
>> be better off installing the 9 that don't have any problems.
>> certainly the way I see it. The error should be equally noisy, but
>> whatever can be updated without problems, really should be.
> 
> This leads directly to a false sense of security.
> 9 updates out of 10, does not mean you are 90% secure.

You're right - But is does mean that your cracker will have to work a 
little harder to find the right exploit.
No reason to make things too easy for him!

> 
> Are you telling me that you are going to spend an equal amount of time
> following up on the errors from partial updates than you do from an
> update that fails to happen at all?

Yup!

I'll get the same warning message in my log, but I'll only have to worry 
about the update that actually has a problem. Not all the other 
potentially critical updates (again - severity is really not important 
here - if an update will install, there's NO reason for NOT applying 
that update).

> 
>> I can't think of any reason not to want this. We're not talking about
>> working around any important stability measure. We're talking about
>> letting good updates through. If one update is misbehaving, it's
>> excluded during this run. that's it.
> 
> And the next run, and the next run, and the next run.....
> You are building a system which encourages people to ignore the
> problem, instead of investigating and resolving the problem.  Let me
> put on my mind-reading helmet that looks into the future... all the
> way to the year 2000{tm}.

This is no different than the current state. Currently, people that do 
not monitor their logs, will ignore ALL updates.
The rest of us, powerusers, sysadmins, developers will report just like 
we do now. No change here - Only safer systems.

> 
> "Why should I bother reporting the partial failure, I'm sure other
> people are using the exact same mix of packages from the exact same
> mix of repos that I have and have reported the issue... no need for me
> to spend time figuring this out"
> 
> "I'm getting 90% of the updates I should be quite safe...I'm sure if
> it was an important security issue they'd fix it asap no need for me
> to report it...."

If you think this is ANY different from what's going on now, you need to 
wake up! This IS what a lot of people are doing already - Again, they 
are missing ALL updates instead of just the ones with unresolved 
dependencies.

> 
> -jef"we have absolutely no valid mechanism on the client side to
> determine if an update is a security update or not...asking tools to
> make a judgement and and to be more noisy for some failed updates is
> asking for just more noise"spaleta
> 

We don't need this! (for this particular issue, anyway)

/Thomas




More information about the fedora-devel-list mailing list