On 13 Mar 2003, Philip Wyett wrote: >> Additionally, I don't think that there are any known security holes in >> Red Hat's products. In the specific case you mention, Red Hat back >> ported the fix to zlib 1.1.3. See >> http://rhn.redhat.com/errata/RHSA-2002-026.html. Note that this errata >> does not include RHEL AS because it shipped after the errata was >> released, so it included the fix from day one. Hence no errata was >> necessary. If you see other security issues that might not have been >> addressed, please check the errata lists at >> http://rhn.redhat.com/errata, and, if they haven't been, email >> [EMAIL PROTECTED] > >No, the version in AS is 1.1.3 and until someone updates the rpm to say >it's 1.1.4, it is 1.1.3. So they maybe back ported the fix, but there is >no direct info related to AS that says it has the fix and it is not an >AS users job to go search other RH versions errata or checking the 1.1.3 >source rpm or rpm --changelog and seeing if the issue has been >addressed.
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. When a security hole is discovered or otherwise made known to us, we resolve the issue by one of 2 methods: 1) By backporting _just_ the security fix(es) and applying them to the older software release that we are shipping already. or 2) By updating the software package to the new version containing the security fix. In general, almost all security fixes are of category 1 above, where we backport the security fix. This is done so that *just* the security issue that has been found is what is being addressed. We then know that the software is not changing randomly in a bunch of other ways. In *some* cases, we opt to update the software to a newer version for one reason or another, however this is very rare. One example of this is "pine" the mail client. In the past, I have released pine updates with backported security fixes, and other times I have released security update to a new version of pine. It depends on what the issue is being addressed as well as other relevant factors. In the pine case - I had already been planning on doing a pine "enhancement" erratum to upgrade pine to a new version, when all of a sudden a security issue came along. So, the two got merged into one erratum. Nonetheless, the overwhelming majority of Red Hat Linux security updates are the form of backported security fixes, and that is because it is the safest possible way to provide security fixes in our products while minimizing risk. When the security update is released, we provide erratum notices, which are emailed via RHN, or on our redhat-watch-list, as well as posted on our website. Users can monitor those locations to know what security issues have arisen, and how we've addressed them. If we ship a new product, and that product contains backported security fixes, then the product ships without the security vulnerability in the first place, and we have no need to provide security erratum notices because the product does not contain the problem in the first place. Do not assume that because you see version x.y.z of a software package being shipped in a new product, that we have not applied security updates to it that were released for other products as erratum. That is broken thinking. If you're going to assume anything, assume that if we've relesed security updates for other products, that those security fixes will also go into our future products as well. 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. If you want to know if an issue is fixed, you have several options: 1) Check the RPM changelog 2) Check the src.rpm for patches 3) Telephone your Red Hat technical support representative 4) Ask other users on a mailing list 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. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat -- Phoebe-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/phoebe-list
