[CentOS-devel] moving the CR repo into mainstream release

Tue Nov 22 14:29:08 UTC 2011
Johnny Hughes <johnny at centos.org>

On 11/22/2011 08:04 AM, Les Mikesell wrote:
> On Tue, Nov 22, 2011 at 2:55 AM, Johnny Hughes <johnny at centos.org> wrote:
>>> The question is whether this person would be better off getting
>>> security updates that were built post-minor-rev-update or not in a
>>> default 'yum update'.   It's a yes or no question, where recommending
>>> doing one thing and making the default something else doesn't make a
>>> lot of sense.   With/without the CR approach, the non-security related
>>> updates are going to come along for the ride, and you will probably
>>> want them anyway.
>> BUT ... I think that giving the user the choice is certainly preferable.
> You have always had the choice of running 'yum update' or not.  Or
> running it for specific packages.  Or looking at the list it offers
> and making the choice then.  That's for people who are paying
> attention.   The question is what should happen if you don't pay
> attention and just expect 'yum update' to always install all available
> security updates for the life of the major rev like it always had
> before, dragging along some other bugfixes at minor releases.

It still does, when we get the release done.  We are not going to leave
the stuff in CR forever.  When the release happens, those people get the
same pacakges as the last version of CR.  So they will get the updates too.

>> We offer, at some increased risk (due to less QA), a repo staged updates.
> I think the risk factor goes the other way, at least for any machine
> that needs updates at all.  We just haven't had a well-known exploit
> to show it yet.

I don't know what to tell you ... it all comes down to choices.  If you
can't wait to get updates, Buy RHEL.  If you don't want RHEL, you decide
what YOU think is the riskiest situation.  if you do nothing, centos
works exactly like it does now.

Also, don't forget that we have made MAJOR changes to our build system
and we are building things much more efficiently now than before.

We have also found and fixed several issues like these:



Which caused us many bad packages.

>> We made this very easy to get ... just run yum install centos-release-cr
>> if you want it.
>> But we give the customer the option to take the increase risk or not.
> That would be reduce the risk if any security issues are involved.

You have the option to get it if you want it or you can wait.  If an
update breaks your system because of a QA issue and causes you downtime,
that is also a risk.  The issue is, you (the user) get to decide .. not
Johnny or Les, but the user.

>> I think this is the RIGHT way to do this.
> Maybe it would have been from the beginning, but at this point I'd bet
> that there are a lot of CentOS installations that haven't updated and
> don't know that they have to do something new and different to get
> security updates.

They do not HAVE to do anything new.  CR is an option thing that has a
limited time scope.  They will still get updates when we release the
point release.

And judge us by the 6.2 release.  It should happen soon and we now have
finalized all our scripting for the new build system for 6.x.  Of
course, new issues will mean we need new scripts, but I think we have it
working well now.

We are also expecting several very large build machines from 2 vary
large sponsors .. I can't name them, but everyone knows them.

>> I know that it means if you do not know how to manage your machine (and
>> issue a very simple command to get CR) then you don't get it ... but I
>> still think that the full repo with full QA should be the default.
> How long do you think it is reasonable to go without updates?  I'd
> call it mostly a matter of luck if you keep running after any
> combination of a remote exploit plus a local privilege escalation are
> known by anyone - and that has always been just a matter of time.

You are in complete control of this ... we get done when we get done.
If that is not fast enough for you, you must use something else.  RHEL
is available.

>> Then, we make people who want CR happy, they can install it and it works
>> after install ... and we make the people like Greg happy because he does
>> not have to do anything to turn it off if he perceives the risk is too
>> great to have it on.
> If updating is too much of a risk, don't update at all.  He's going to
> get the one he suggested as a problem as soon as you do a real release
> anyway. I don't think he really identified a problem related to having
> the minor rev updates come before a new anaconda/iso is available.

Not necessarily.  We have FIXED many issues from CR .. also even if they
are not fixed, they are called out in bugs.centos.org ... like this one:


Easy enough to fix if you are expecting it ... someone in CR found it
(also upstream).

The point is ... use CR or don't ... choice is yours.  Use CentOS or
RHEL ... that choice is also yours.  If you want SLA level update times,
you need an SLA level Enterprise Linux.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20111122/310eebef/attachment-0005.sig>