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.
