yum plugin suggestion or yum change?

Jeff Spaleta jspaleta at gmail.com
Mon Dec 5 23:16:09 UTC 2005


On 12/5/05, Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
> Jeff Spaleta wrote:
> MS reasons for holding back some stuff are not applicable to Fedora.
> Fedora userbase is not segmented between legitimate users (which can get
> full updates by going through a portal) and freeloaders (which MS would
> dearly love to leave in the dust, but can not for PR reasons).

I make no claim as to why MS does anything... you brought up MS not
me. But I thank you for the lesson in conspiracy theory.

> If you really worry about missed critical updates make partial updating
> a repo parameter, separate critical updates from other stuff and set
> partial=false for the critical update channel.

Isn't missed security updates... the underlying concern for everyone
in this discussion?

This per-repo trick would only work if security updates are actually
housed in a seperate repo than non-security updates. That doesn't
really work at all with the current repo structure.

> I contend you'll get the same results by simply counting how many times
> a package fails updating and warning when it gets over some threshold,
> but if having one repo where yum balks at the first problem makes you
> happier, you can do it this way too.

No, not really. I'm not really excited about tools taking a week to
notify users of update failures.  This whole discussion has been
prompted about getting updates asap. Waiting a week to notify a user
about a broken critically important security fix.. seeks counter to
everyone's desire.  It is my contention that reliable auto-updates
must make a distinction about security/non-security failures and
clearly notify the user asap about security update failures so the
user can assess what actions to take.  I'm not in favor of encouraging
any automated update installation that does not attempt to account for
the known security rating when informing the user as to update
failures.

What I want is the best practise for security updates that can be
implemented for the project. If non-interactive partial updates are to
be encouraged I want there to be a clear way for the client tools to
tell users if any security updates failed. I don't want the security
update failure buried indistinquishably in a log of 300 other
non-security failures.

By my count there have been 354 different update annoucement emails
for FC 4 updates since July 7th (when the new update annoucement stuff
went live).  69 of those have been tagged as security... 20% or so. 
How many reported problems with updating in that time have been from
security updates as compared to problems with non-security updates?

If someone were to do an everything  install of Core on any given day
and partial autoupdating was encouraged. Which security updates would
be held back? Which non-security updates would be held back? Today at
the very least, the kernel would be held back due to the GFS packages.

I feel that users who rely on auto-updating for security would get a
false sense of security by auto-updating without there being a
notifcation mechanism to clearly notify the user of unapplied security
updates asap. I believe that a false sense of security can be more
dangerous than actual insecurity because a false sense of security
will embolden some people to take risks they otherwise would not if
they knew their were vulnerable.  Feel free to disagree.

-jef




More information about the devel mailing list