-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 14 Mar 2003 14:02:28 -0500 (EST), Mike A. Harris wrote:
> 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? There is no solution except getting them to understand that they need NOT install the latest version, but will be safe with the errata releases. rpmfind.net or searching the web for "the latest package from Red Hat" is too popular, however. Maybe that is where they see that the recommended latest release is not available as rpm and conclude that they need a new release. > >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. My paragraph above was badly worded and badly placed and should have referred to vendor's own advisories earlier. Of course do Red Hat's security advisories mention the vulnerability and also mention that the update packages contain _a fix_. As an example: "These erratum packages contain a patch provided by the OpenSSL group that corrects this vulnerability." However, I think not many people compare in detail whether an erratum from Red Hat fixes exactly the vulnerabilities which they read about on popular web sites. It boils down to "foo version 1.23 from www.foo.org is safe and recommended", but "foo version 1.18 from Red Hat is... uhm, is not the latest, so does it contain all fixes?" or something like that. And in a message board some helping freak recommends visiting www.foo.org to get the latest foo-1.23.tgz. So, maybe the header of an advisory could explain that "foo 1.18-30 [from Red Hat] contains all security fixes up to and including foo 1.23 which also affect version 1.18". Does that make sense? It would compare the security of the erratum with the latest vendor release (that 1.23 might contain a few yet undiscovered vulnerabilities, is not important because the user should install 1.18-30). If users insist on getting 1.23 because it contains new features and other changes, that's not my problem. > ie: redhat-zlib-50.0.0secure.i386.rpm > > Would that suffice? ;o) Yeah, what about "redhat-zlib.i386.rpm"? ;-} Adding time-stamps to version numbers reported by servers and tools would not get rid of all misunderstandings either. > 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? This is a problem I see. It is a matter of trust and a matter of understanding *why* and when Red Hat back-port fixes rather than pushing out the "latest and greatest". Is this documented anywhere on www.redhat.com? It is also a matter of impatience. Once you have installed a vendor update yourself, you're out-of-sync and either must install future patches yourself as well or "downgrade" to Red Hat's packages. Btw, it also scares me a bit when I see users who have no errata installed at all. - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+cl130iMVcrivHFQRAnG6AJ9+fjdpEOXGAwtzFbZka+bbuRseEQCfS8gq MjfRET78Tjbj/J7yrm8wQSs= =tFu7 -----END PGP SIGNATURE----- -- Phoebe-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/phoebe-list
