How do we handle security updates
Hello All-
Pardon me if this has been hashed out before. I'm seriously considering the use of some of the Cool Stack packages to run a SAMP setup. However, what I can't find anywhere is how security updates and such are managed... for example if a security bug in PHP is discovered, who's responsible for making sure it gets pushed back into these packages and then how is notification handled for updates to these packages?
These are neato packages for getting a box up and running quickly... I just worry about the longer term maintainability of them.
Thanks for your thoughts-
John
[618 byte] By [
John.Tracy] at [2007-11-26 11:59:41]
# 1
I guess you would handle them like any other open source application. Namely, download it and rebuild it yourself ! Seriously though, Cool Stack is not an officially supported package even though we do try hard to answer all questions on this forum. It would be quite difficult to keep with all of the updates in the different libraries and apps on a timely basis.
Having said that, I'd like to point out that we are working on the next release which will include Apache 2.2 and PHP 5.2. The PHP build in particular is going to be greatly enhanced to handle a huge number of extensions. We also plan to include memcached and perhaps Ruby as well. So if you have any specific requirements, now's the time to get them in.
Shanti
# 2
Hi Shanti-
Thanks for your reply. I realize that Sun Cool Stack is not a Sun supported product and I'm certainly not trying to bang on anybody for the provision of such a wonderful package. However, I'm wondering if it would be possible to consider taking this to the second level. I'm worried about all of the new administrators out there who just apply these packages and think they're good to go forever--or at least until a new version of the Cool Tools comes out. Are we really doing anybody a service by providing packages which might potentially compromise their system?
What would it take to bring this up to the next level--meaning (in my mind) something like a table or matrix of all all of the dependent libraries utilized in these packages, and have folks assigned to watch for vulnerabilities in those libraries? And then be responsible for notifying the team or upgrading the package itself? I'm guessing we're talking about a few dozen libraries here?
And then we could setup some sort of versioning system, where this is Cool Tools Stack version 1.01, and a security release might make it 1.02, and so on. As we know, security and convenience are always a tradeoff, but if I can make a change on one package on my system to accommodate a security vulnerability and submit it back to the Cool Tools Stack which might potentially benefit hundreds of people, why shouldn't we have a mechanism in place for this and not duplicate the effort/time of sysadmins everywhere.
I guess that's what it all boils down to for me--duplication of effort and providing a product which really has a sustainable future, instead of just installing a package once today not considering the inevitable security ramification that will come tomorrow.
Thanks for hearing me out. I'd love to know the community's thoughts on this.
John
# 3
Do you have an expected time-frame to release the next version with updated PHP modules?
I'm in the process of building a server to replace my aging one, but I need to have IMAP and ZLIB at the very least and CURL would be nice. Those are the only ones that I would need.
HIstorically, I have compiled and built my own packages, but this gets me SO close to taking that work effort out and this would be PERFECT timing if it's something you plan on releasing in the next two weeks or so. I can live without the RUBY.
Thanks for the great work!
