[CentOS] This doesn't make sense

[Lamar Owen]

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?