[oi-dev] Proposal: OpenIndiana Stable Branch

[Guido Berhoerster]

* Alasdair Lumsden <alasdairrr at gmail.com> [2011-01-14 21:36]:
> The release would be aimed for February, and titled "2011.02". It would be based
> on oi_148. We would only provide the Text Installer and Automated Installer
> ISOs.
> 
> We would provide security and critical bug fixes only for:
> 
> 1. OS/Net (The core OS consolidation)
> 2. A limited set of server oriented packages that have the greatest usage and
> attack "surface area". The initial list I can think of includes:
> 
>  - OpenSSL
>  - Sendmail
>  - Perl 5.8.4
>  - Python 2.6
>  - Ruby
>  - zip, bzip2, gzip
>  - Apache HTTPD 2.2
>  - PHP 5.X
>  - MySQL 5.X.X
>  - Postgresql 8.4
>  - Java
>  - Tomcat
>  - GNU Coreutils
>  - GCC
>  - RSync
>  - ISC BIND
>  - Bash
>  - Curl
>  - wget
> 
> We should also aim to provide security fixes for any bit of software in the repo that allows an easily exploitable remote access vulnerability or root privilege escalation, although we cannot guarantee to do so as monitoring security updates for over 1000 software packages is unfeasible. An example would be the recent Exim vulnerability on CentOS that allowed remote root access by sending appropriately formatted emails. This area is something where we will depend on users, not OI developers, alerting the project to the issue so that a judgement call can be made on whether we have the resources to fix the issue.

I agree with that, however I consider this strictly a makeshift
solution for those who are now desperately in need for a
replacement of OpenSolaris to bridge the time until the
Illumos-based OI has stabilized.

> Security updates would be provided from 6 months of the release date, or until the next stable release is released. Potentially we have the option as a project of providing commercial support past the 6 month date if enterprises desired this. I feel this could be a good way of generating revenue for the project to fund development if there was a market for it.

Since this is based on Oracle ONNV which is a dead end we should
not carry aound this burden and waste resources any longer than
necessary and force a switch to Illumos.  After that we can
discuss whether it is an option for later Illumos-based releases.

> If external contributors were able and willing to commit patches/fixes beyond the supported list, we'd accept them with open arms, and this could be a great way to extend the contributor list and get more people involved.

Note that this is not just be about accepting contributions,
it would also involve review and testing by regular developers,
in particular if we make committments about stability. I think
there are better ways for potential contributors to get involed
into the project so let's stick to the above list.

> 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.
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.
You could probably piggyback on Solaris Express and update all
non-ONNV consolidations to b151a but even that would be a lot of
potentially unnecessary work.
I think the best approach is probably to just do what everybody
else does and monitor upstream projects and security mailing list
and to port patches.

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.

-- 
Guido Berhoerster