[prev in list] [next in list] [prev in thread] [next in thread] 

List:       centos
Subject:    Re: [CentOS] This doesn't make sense
From:       Lamar Owen <lowen () pari ! edu>
Date:       2011-09-23 17:57:07
Message-ID: 201109231357.07573.lowen () pari ! edu
[Download RAW message or body]

On Friday, September 23, 2011 01:29:51 PM Dennis Jacobfeuerborn wrote:
> What you are suggesting here is that people should expect centos systems to 
> be insecure and go the RHEL if they want secure systems.

If the timeliness of security updates is essential/critical you cannt get faster \
updates than with the upstream paid subscription; it is impossible for a rebuild to \
release the update before it's posted.  So, yeah, if getting the fix the quickest is \
mission-critical then a subscription to upstream should be purchased.  If you can't \
afford or don't want to pay for a subscription, then you have two options:

1.) Build and test it yourself;
2.) Wait on someone else to build it and test it, where 'someone else' can be an \
individual or one of the rebuild projects, of which CentOS has the largest \
distribution with SL next largest.

If you can't wait and can't build it and can't pay for a subscription, then you have \
two options: 1.) Get your server off the net immediately;
2.) Be insecure until you get the update.

> Have you pondered the moral implications of your statement? Does that mean 
> that the centos project is perfectly fine with knowingly distributing a 
> system that insecure and a danger not only to its users but to others as well?

All systems are insecure.  Updates are for the known holes; there are and always will \
be unknown holes.  

Have you pondered the moral implications of knowlingly installing insecure software \
and placing it on the public internet?  Oh, wait, it's not a moral issue, since there \
is no such thing as secure software.

> Drop whatever 6.x related things you are 
> doing, build the package, put it online, make an announcement and then get 
> back to the regular schedule. 

You are missing some highly important steps.  Let me summarize:
1.) Get source RPM(s) for the update from upstream.  Upstream's source RPM's for the \
updates have been known to be delayed, sometimes for quite a while; 2.) Build;
3.) Verify binary compatibility (that is, does it have identical binary dependencies \
on identical versions of dependencies, verifying that it was built in an identical \
buildroot as upstream?) (you do realize that a given source RPM can be built to \
generate very different and potentially incompatible binary RPMs depending upon the \
contents of the buildroot, right?); 4.) QA the package to make sure other people with \
various systems can install and use the package, and that it really does fix the \
problem; 5.) Make sure the resulting repository is 'closed' (that is, in a consistent \
state so people updating don't get nasty surprises); 6.) Seed the mirror system.  A \
large package update set can take a significant amount of time to propagate; 7.) \
Announce, and wait on the inevitable bug reports and complaints that it broke users' \
systems.

Sounds like fun, no?
 
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


[prev in list] [next in list] [prev in thread] [next in thread]