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.
--
Les Mikesell
lesmikesell at gmail.com