Hi, Thanks for the reply. Distribution dot release is what I was referring to. I didn't make myself clear, so my bad. I'll give an example, which will make it clearer, hopefully.
The other rebuild project has not yet released their equivalent to RHEL 4.8. Obviously, RH themselves have (as have SL :o) ). As far as I understand, after RH release 4.8, all their subsequent errata updates against 4.X will be released with the assumption dependencies are met by packages in 4.8. The problem with the 'other' rebuild distribution is that they won't release security updates that require dependencies that are met in 4.8 until the have released their 4.8 equivalent distribution (Actually they 'roll-in' recent updates). So there is a potential delay of weeks and months before security updates are passed on whilst a distribution is being rebuilt, as they currently don't start rebuilding the dependencies of an errata updated package, unless it is part of the release. So they upshot is is that 4.7 users can't get security updates until 4.8 is released. As far as I remember, 5.3 took 2 months to appear from the other rebuild project. I am quite happy to wait a few days for a security updates, but I do take issue to an unknown exposure where security updates are delayed for an unspecified length of time. So, does SL work the same way? Thanks again. ________________________________ From: Dr Andrew C Aitchison <[email protected]> To: Ian Murray <[email protected]> Cc: [email protected] Sent: Tuesday, 11 August, 2009 9:41:23 Subject: Re: Security Updates Question On Tue, 11 Aug 2009, Ian Murray wrote: > Hi, > > I'm new to the list so please be gentle with me! > Does the Scientific Linux maintainers use the same approach as above, > or have they solved that issue in some other way? The Scientific Linux maintainers release very few security updates independently of Red Hat. > I am a user of another well known Redhat Rebuild distribution and it > has come to light that the maintainers don't/can't release interim security > updates while they are rebuilding a new dot release from upstream, as far as > I can understand. I don't really understand your description. In particular what is a "dot release" - rpm packages typically have lots of dots in their version and release strings ? Typically Red Hat, and hence SL, packages don't have the latest version as the package developers, so cannot use the up-up-stream patch but have to back-port the fix. For example last month the ISC released BIND updates 9.4.3-P3, 9.5.1-P3, 9.6.1-P1 and 9.7.0a1. The BIND in Red Hat 5 release 3 was updated from 9.3.4-10.P1.1 to 9.3.4-10.P1.3, so they couldn't directly update an ICS patch but had to back port the fix to 9.4.3. Is that what you are worried about ? > This is because upstream releases its security fixes against the most recent > dot release. Therefore there is a corresponding delay to security releases. Are we taking delays of hours, days or weeks ? I can imagine that it takes several hours to build a set of new packages for every supported version of the OS, and then test them. As far as I am aware, Red Hat don't make their security releases available to SL or CentOS ahead of the general release, so SL security packages can be a day or two behind the Red Hat versions. Yes, that can be annoying for day-one exploits; the alternatives are pay Red Hat and rebuild the package yourself. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [email protected] http://www.dpmms.cam.ac.uk/~werdna
