On 17 Jan 2011, at 00:00, Christopher Chan wrote: > On Saturday, January 15, 2011 11:35 PM, Guido Berhoerster wrote: > >>> To make the above easier to manage, one proposal I have is to match the >>> versions of Apache, PHP, MySQL, Tomcat etc to the same versions shipped in >>> RHEL 6/CentOS 6. This way we can monitor their repositories for security >>> updates against these packages, and share the same backports. This will >>> make life a lot easier for us as a project. >> >> I strongly object to this approach, not only would it be a large >> amout of work to update all these packages but we would also need >> to do a lot of QA work and ensure they all work together. > > It might probably be just the initial preparation that takes a lot of work. > eg: Instead of building against glibc and with gcc, things would be built > against sun libc and with sun cc. Once the initial spec files are worked out, > automating the process for updated packages should be pretty much possible > would it not?
On reflection I think Guido's probably correct - we know the packages in oi_148 currently work together, so lets stick with that. Producing our own backported security patches should not be too difficult - typically a security backport fix only affects a small amount of code. For example if we're running foobar 1.5.5 and CentOS has foobar 1.5.1, and a security fix is put into the latest foobar release 1.5.9, then the security backport patch CentOS make for foobar 1.5.1 would no doubt apply on foobar 1.5.5. If it doesn't, then some interpretation may be needed. For a more concrete example, OI ships PHP 5.2.12. Debian ships PHP 5.2.6. They have a CVE-2010-2225 patch for this version: http://patch-tracker.debian.org/patch/series/view/php5/5.2.6.dfsg.1-1+lenny9/CVE-2010-2225.patch This patch isn't present in PHP 5.2.12 as it came out after. However it applies cleanly against php 5.2.12: root ~ (alasdair.fastdev01): gpatch -p0 < CVE-2010-2225.patch patching file spl_observer_512.c root ~ (alasdair.fastdev01): echo $? 0 So using other peoples patches isn't going to be too hard - anyone who knows how to patch code can assist with this (Although security patch contributions from non-core team members will need to be audited/code reviewed for hopefully obvious reasons). >> Furthermore, RHEL is a totally different platform, packages have >> different patches etc., not every issue in RHEL needs to apply >> to OI and vice versa. Such a Frankenstein-Release is just >> unfeasible. > > Certainly kernel related stuff in RHEL would not apply and also configuration > path related patches won't too. It should be simple to identify these > packages/patches and leave them out. The rest will probably apply unless they > are linux kernel related which again would be identifiable. In the example above, CVE-2010-2225 is: "Use-after-free vulnerability in the SplObjectStorage unserializer in PHP 5.2.x and 5.3.x through 5.3.2 allows remote attackers to execute arbitrary code or obtain sensitive information via serialized data, related to the PHP unserialize function." It doesn't matter whether the PHP is in CentOS, Debian, or Solaris - a patch to fix this will apply on all of them assuming the code hasn't changed between releases. In most software projects, all the code isn't changing all the time, so security patches will typically apply to a wide range of versions. So that means we can just stick with the versions OI_148 ships with and patch those. <snip> >> Since this is just a bridge for those who already use OpenSolaris >> or OI in production I'm categorically against demands for feature >> additions sucha as providing postfix and a pony that already seem >> to pop up. >> This is a temporary solution, so please let's treat it that way. >> > > Merci. I guess I would have to look elsewhere then. Nice comparing postfix to > a pony. I would have thought something like zimbra would be a pony, not a > mainstay like postfix. Sendmail is the default MTA on OI, so for this stable release, we'll only provide security patches for it. Postfix isn't even in the /dev repo at present, so security patches will have to remain an exercise for the reader :-) But I am very keen for pkg.openindiana.org to ship Postfix, Exim and lots of other useful free open source software - thats what OIAC is about: http://wiki.openindiana.org/oi/OpenIndiana+Addon+Consolidations But extending the supported software list will require the number of people contributing to the project to grow significantly. So please, anyone reading this, if you want OI to support more software, contribute. It's not hard, it's fun, it'll look great on the CV, and it helps out a lot of people. The easiest first step you can do is to install an IRC client and join #oi-dev on irc.freenode.net and meet the guys making OI happen. We can then guide you on where to start! Cheers, Alasdair _______________________________________________ oi-dev mailing list [email protected] http://openindiana.org/mailman/listinfo/oi-dev
