On 6/21/2011 3:00 PM, Ljubomir Ljubojevic wrote:
Les Mikesell wrote:
So, if you were managing an internet connected host running CentOS, would you configure it to track the CR repo or not? Or what criteria would you use to make this decision? I'm still having trouble seeing why, if upstream decided they should go out, that someone running what is essentially identical to that upstream code doesn't need them for the same reasons. Or why to think the risk of installing them outweighs the risk of continuing to run what upstream had its reasons to replace.
We are not talking about regular updates, but **only** the time between RHEL point release and CentOS point release. So completed packages do not wait for *all* packages and ISO's to be released, but are available as soon as QA team approves them. If there is fundamental error for a base package that requires for some of those packages to be recompiled, we need to have some kind of automatic protection for that case scenario.
That doesn't address the risk of *not* installing these updates. Generally speaking, I think most users of CentOS trust upstream's choices and for me that includes when it is time to fix the bugs they shipped last time around. And generally speaking, I trust the CentOS project to be able to recompile working source and catch obvious mistakes before pushing them out.
So, again, under what circumstances does anyone think it is a good idea to not opt into this repo and instead keep running code that will very likely have published exploits over a time span that we've seen can run for months? I agree that this is a fuzzy area where not all of the point release updates address vulnerabilities or even serious bugs, but some certainly will. It just seems to me that not doing them is betting against the upstream wisdom or the project's building/QA capability. But I also agree that yum should be smarter and know something about rebuilds with no source change.