On Thu, 22 Jul 2010, Jeff Johnson wrote: > In general, everyone doesn't really know what is contained in a "security" fix. Whether true or not in general, that doesn't apply here. Anyone can see exactly what is in the source code released upstream. > The details of a "security" fix are typically only summarized, and one > is expected to be able to infer from the patch the relevance to the > underlying security issue. Probably, but I don't think that is under discussion here. > The harder (general, true for all distros, not just CentOS) is the > release engineering involved. For starters -- because its "security" related -- > the priority and timeliness are important. timeliness *appears* not to be important to the CentOS project, hence this discussion. > However security fixes are invariably "out-of-band" in the sense > that there's never enough time and resources to run through a > full QA integration cycle. So the release engineering involves > shrewd/savvy guessing that nothing else is gonna be broken > by distributing the patch. > > There's the further procedural risk of mis-building. Keeping > build systems in perfect condition gets trickier and trickier as > distros (like CentOS5) age. All security patches need to be applied > as well as the original release. Any new package build relies on having > a build system sufficiently close to be able to rebuild reliably. Yes, but isn't this core business for the CentOS project, and apply equally to point releases as it does for security updates? > While of the above may seem obvious, the specific points are > 1) there are no steps and there is no process. Instead > its savvy guesses and spot checks and triple checks. I would hope that there are some standard steps, rather than a totally ad-hoc process. > 2) the bottleneck _IS_ in some sense the testing team, > who are expected to achieve the pretense of "perfection" > in spite of the "out-of-band" QA procedures involved. > You really start to think hard and carefully before claiming > WORKSFORME > when your reputation is at stake. Its embarassing when some > silly error has to be re-released or re-re-re-re-released to > achieve the desired "security" fix goal. I have seen no evidence that the testing team is the bottleneck here. > Security "fixes" are a hard problem to solve in _ALL_ distros, not just > CentOS. My expectation is that it is actually an easier problem for CentOS. They don't need to consider whether it is the correct or best fix, just whether it has been built correctly, and produces build output "sufficiently similar" to that produced by upstream. --- Charlie