On Fri, 2003-03-14 at 13:25, Mike A. Harris wrote: > On 14 Mar 2003, Philip Wyett 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. > >> > > > >Ok, I may have put it slightly wrongly and stated 'back ported the fix' > >when it should have been generic, say 'back ported a fix'. Other than > >that I stated what you have that until it's says it's 1.1.4 it's not. > > I read your above paragraph 4 times and I still can't make > comprehend what it says. ;o) >
It is perfectly understandable. Some more punctuation would have been nice. <blush> However, your attempt at a sentence isn't much better. :) > > >> Please do not claim that a given Red Hat product ships with a > >> given security hole such as above without specifically confirming > >> that the problem does exist. Otherwise you are just spreading > >> FUD. > > > >I did not state Red Hat shipped anything with a given security hole. I > >was merely attempting to stress the pointlessness of the previous post > >pointing at another Red Hat versions errata and the assertion that AS > >post dated this version and must have any given fix. > > Um.. here is what you said: > > <quote> > any mirror and the AS errata, it's gets rather scary. The first > thing I noticed was AS 2.1 shipped with zlib 1.1.3, but there has > seemingly been no errata (security fix) update to 1.1.4. There is > more stuff, but it's pointless for me to go on listing stuff. > </quote> > > We don't ship errata for a security hole if the security hole is > not present in the product in the first place. It's pointless > for you to go on listing stuff only because your claims are all > false and invalid. > Other than a poor 'scary' reference - I see nothing inaccurate as I did point out 'seemingly been no errata (security fix) update'. You must remember you are coming from this as a RH developer and not a user taking pure face value information. The pure face value info says 1.1.3. > > >Oh, don't do the FUD thing on me as it's totally misplaced. > > No it isn't. FUD == Fear Uncertainty and Doubt. You are trying > to do just that. > I will ask you to cease asserting I am trying to spread fear, uncertainty and doubt. It was never stated categorically that the fix was not in the AS zlib release and has since been subsequently established on more than one occasion. > > >> If you want to know if an issue is fixed, you have several > >> options: > >> > >> 1) Check the RPM changelog > > > >Nope, usually poor descriptions and no terms of reference e.g. > > > >* Wed Jan 30 2002 removed_name <[EMAIL PROTECTED]> 1.1.3-25.7 > > > >- Fix double free > > You just contradicted yourself by showing that the fix to zlib is > indeed listed in the changelog, and also that you were able to > actually find it once you checked. > > I will however state that we are not able to always put details > about security fixes in our changelogs because sometimes a > security fix is embargoed but we have to roll out our products. > In other words, for some security fixes, we have to not disclose > them until a certain date, however we might have a fix for that > security flaw already and have to wait to make it public. We > sometimes have to also put the security fix (with permission from > whomever set the embargo) into our product so that CDs can be > created. If we had to wait until an issue could be public just > to create a changelog entry, and THEN ship off CDs to be created, > that delays us making the change and getting the CDs created only > for the purpose of making a changelog entry. That makes no good > business sense to do so. > The snippet I added on purposely, knowing which fix it was. :) However, it makes no effort to tell you it's a back ported fix, which would have been nice. As you stated it is sometimes beyond your control and info must be omitted due to time constraints or an embargo. Though how this can apply in this particular case, I'm not entirely sure as of yet and would not like to comment. > > >> 2) Check the src.rpm for patches > > > >Don't have the time to do this kind of trawling as don't many others. > > You don't need to. We do the work for you. By using Red Hat > Linux and other Red Hat products, our name stands for itself. > Either you trust our products and trust us, or you don't. We > apply security fixes to software when there are problems and we > release erratum. New OS products will go out the door with those > security fixes automatically built-in if the versions of the > software in the new product were vulnerable in their stock > upstream versions. That is the way it is done. > > Aside from unnecessarily upgrading to a given new upstream > package version which has security fixes upstream, how exactly > would you prefer us to indicate that our packages are shipped > with security fixes to all known security problems at the time > the product was shipped? I suppose we could put a piece of paper > in every box that says "The versions of software included in this > OS product contains backported security fixes for every package > to which the stock upstream source code contained flaws fixed in > newer releases of the software which we chose to backport in > order to maximize stability and minimize risk for our customers" > however I'm not sure that would end up being a useful piece of > paper for anyone. > > I believe our customers choose Red Hat Linux because they trust > us to make good judgement, and to do the right thing in a > reliable and secure manner. And I also strongly believe that we > do this and do it properly. > With the politicians about these days and the talk about trusted computing that will take from us not aid us - trust is a bit thin on the ground. Red Hat produce the #1 Linux distro IMHO and have a level of trust which is far higher than others in the field. This I believe to be true and I hope continues and grows. But don't expect trust, it needs to be _continuously_ earned. > > >> 4) Ask other users on a mailing list > > > >These folks can always be counted on to help. ;) > > Sometimes yes. Other times they can try to mislead people by > spreading FUD, so you need to be careful too. > True. > > >> If those are not enough options, I'm not sure what exactly you > >> would be requesting of us. I'm sure if anyone out there is > >> curious about wether or not our Red Hat Enterprise Linux products > >> contain a given security fix or not, that our sales department > >> would be more than glad to do the dirty work of finding out for > >> you before you make your purchase order. > > > >I too am sure that anyone ready to part with the cash and having queries > >are going to ask the sales dept to clarify before the deal is done - > >Would be a bit daft not too. :) > > Then there should be no problems with customers worrying wether > or not a given security fix is included in a given release of the > OS. They can trust Red Hat and our products, or they can contact > us to clarify any of their concerns and allay their possible > fears. > > 1-888-RED-HAT-1 <-- for all your OS purchasing needs. ;o) > Poor multimedia support due to mpeg licensing issues - Not your fault I know. So lets say - Nearly all your OS purchasing needs. :) Regards Phil -- ICQ: 135463069 Email: [EMAIL PROTECTED] -- Public key: http://www.philipwyett.dsl.pipex.com/gpg/public_key.txt --
signature.asc
Description: This is a digitally signed message part
