[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: Latest UTB Newsletter
- From: "Mike A. Harris" <mharris redhat com>
- To: phoebe-list redhat com
- Subject: Re: Latest UTB Newsletter
- Date: Fri, 14 Mar 2003 08:25:23 -0500 (EST)
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
>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
>> 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]