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

Re: Essential updates?



On Tue, Dec 21, 2004 at 04:55:32AM +0100, August wrote:
> On Mon, 2004-12-20 at 17:17 -0500, Matthew Miller wrote:
> > On Mon, Dec 20, 2004 at 11:12:37PM +0100, August wrote:
> > > After having installed Fedora Core 3 the exclamation mark shows that
> > > there are a number of updates available. Is there a way to find out
> > > which of these updates are essential (security/core functionality)? I'm
> > > new to Linux and Fedora so I know nothing about most of the included
> > > packages.
> > 
> > It's tricky. You can browse the Fedora Announce archives at
> > <http://www.redhat.com/archives/fedora-announce-list/> to get some idea.
...
> Didn't find much info in fedora-announce-list, but thanks anyway. I know
> that e.g. Windows Update separates essential security updates from other
> updates. A similar feature in yum or Up2date would be extremely useful.

Since one mans bug is another mans feature this could be harder 
than you think.

Windows source is 'closed' we have to trust that essential updates are
essential.  Microsoft has been "marketing" the value of their updates
and we have no way to research the need, fix or quality.  In the past
some bug fixes appeared to be little more than stack overflow
protection by recompiling and relinking so a script kiddie tool fails
(for about a week).  The hint for these is that there is another update
in a sort time period to correct some 'regression' or some other "issue".

Do watch the fedora-announce-list and also use 'up2date' or 'yum' to
notice new packages as they become available.  Functionality will not
commonly change without a big number version change.   Read some stuff
on RCS and SCCS to understand version numbering.

Critical security bugs will commonly have some reference to a common
security identifier in the announcement.   Like this one for gpdf...

   "Update to gpdf 2.8.0, which fixes the CAN-2004-0888 security issue."

You can also subscribe to the Cert announcement list
(http://www.cert.org/).  Their announcements can tell you how
'critical' the issue is.  N.B. (Note Well) that the folks at RH will
often back port a bug fix from upstream to insulate ya from feature and
function changes.  Thus a Cert announcement 'fixed in N.n.something'
may be back ported by RH package folks to a previous version (N-1).

See also "Common Vulnerabilities and Exposures (CVE®)" site
at  http://cve.mitre.org/

Exceptions to the RH back port strategy exist.  They appear to reflect
the complexity of changes related to the issue and divergence from the
upstream tree.  There is also a lot of overlap in FC2 and FC3
application packages. So the differences in FC2 and FC3 are more
bounded than we saw moving from RH9 to FC1 or from FC1 to FC2.

You can also look at the bugzilla bugs.  Those that have some details
locked from public view will be CRITICAL security issues ;-0.  The
'invisible' stuff is commonly the details of an exploit that should
not be shared.  This is a big clue that you want the fix.

There is always source.  By inspecting the source in concert with the
bugzilla reports you can learn lots and not need to see the exploit
details to understand the value of the fix.   Often there is no need
to be a programmer ... look for comments.

My current strategy is to use yum/up2date to download ALL the new rpm
files that apply to my system. Then I use rpm tools to look at the
change log.  Example:

   rpm -q --changelog -p ./xpdf-3.00-3.6.i386.rpm | less

After some research I can decide to update or not. 
So far I have not seen a single update that I did not want to load.
I have held off a week on some...

SUMMARY:
If you use a package keep it current.


-- 
	T o m  M i t c h e l l 
	spam unwanted email.
	SPAM, good eats, and a trademark of  Hormel Foods.


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