[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Latest UTB Newsletter

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)

>> 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:

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.

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.

>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.

>> 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 <removed redhat com> 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.

>> 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.

>> 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.

>> 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 

1-888-RED-HAT-1 <-- for all your OS purchasing needs.  ;o)

Mike A. Harris     ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]