On Saturday 14 December 2002 03:43, Ben Russo wrote: > On Fri, 2002-12-13 at 16:11, [EMAIL PROTECTED] wrote: > > The latest 7.3 openssh package is 3.1p1-6 > make sure the redhat mirror you are using has the latest. > The 3.1p1-x, the 'X' part is the epoch number which according to redhat > outweighs the version number of the package. > > So it could be possible for RedHat to release a package versioned > 2.2-1, then release an errata package 2.3-2, and then have a superceding > errata release that is 2.2-3.... I guess that could be confusing, but I > can't think of a better way to do it.
I assume that this is strictly within a RH distribution model. For example, the openssh-3.1p1-6.i386.rpm for RH 7.3 does not supercede openssh-3.4p1-2.i386.rpm for RH 8.0 even though the epoch number for the former would indicate that it should. > The Errata Notes for Security problems almost always do refer to the > CERT or the CVE announcement. Heck a lot of times CERT even tells > you what package and FTP url to get the RedHat patch. > > If I remember correctly there is a very VALID reason to back-port the > security fix to 3.1p1 rather than just distribute 3.4 > The reason I think I remember is that version 3.4 required a newer > version of openssl, that new version of openssl that might have required > a change of lots of other programs like mod_ssl, stunnel, links, w3m, > fetchmail, etc.... At the very least all those programs would > have to have been tested. > > I'm really glad that RedHat backports the fixes, cause I would be caught > between a rock and a hard place if I had to make a choice between > changing the openssl lib version on a production server or having > a known hole in my SSHd. I feel confident knowing that any potential > bug I am introducing is limited to the program that would be vulnerable > without the fix, rather than making a sweeping change that could > introduce *new* bugs to all kinds of other apps I have on my box. > > -Ben. >From another conversation I had in this thread it appears the errata page cannot be depended on for history so I guess the source files are going to be what's required. You bring up some good points and I'll consider pulling down the source rpms for the stuff that I find to be critical before bailing out entirely and going to the source tarballs assuming the rpms are available in a timely fashion. Regards, Mike Klinke -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/redhat-list
