On Fri, 14 Mar 2003, Michael Schwendt wrote: >> The 1.1.3 RPM will not be updated to say it is 1.1.4 because it >> is not 1.1.4. Red Hat RPM packages, in addition to containing >> the version of the software that is indicated, contain various >> bug fixes, security fixes, enhancements and other patches that >> are a part of the OS engineering process. > >Unfortunately, this versioning scheme and lack of knowledge of Red >Hat's back-porting efforts are the source of a common misconception >among fussy admins as well as home users.
What is your suggestion for how to rectify that? >Although I'm familiar with the methods, I would not mind if *every* >security advisory from Red Hat pointed out when an erratum contains >a back-ported fix and therefore remains at a lower version number >than suggested by the software vendor. As far as I know, they do. >Because vendors' security advisories find their way onto the News >web sites. And people read such security news more carefully than >Red Hat's advisories. IMO it is not uncommon, that when they read >they are recommended to upgrade to the latest version of software >XYZ, they get the tarball. Or someone with lack of insight examines >the company's web server with e.g. "wget --server" and complains >that an "old" version of Apache, which contains vulnerabilities, >is running. It's the source of unfortunate misunderstandings. Even >adding a timestamp to a version might help. Upstream projects will generally _always_ recommend people upgrade to their latest code. It is the easiest for them that way as they don't have to support some old software forever then. That doesn't mean that that is the best solution. The only other thing I can think of would be for Red Hat to break from upstream versions of all software, bump the version number to 50.0.0 and prepend "redhat-" to the software name. ie: redhat-zlib-50.0.0secure.i386.rpm Would that suffice? ;o) I personally don't see the problem. I do however get a bit of a chuckle when people come in IRC trying to get help upgrading some software to version 1.8 because they need to get this major security fix they read about and Red Hat only ships 1.7. Do people really think we would ship version foo-1.7 and not fix a major security hole that is announced? Well, some people evidently do, but thank God most people realize we do release security updates for issues, and do so in a way that doesn't put them at additional risk by changing more things than just the security fix. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat -- Phoebe-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/phoebe-list
