[wp-hackers] Security Releases Proposal

[Peter Westwood]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alex Günsche wrote:
> On Mon, 2007-06-11 at 11:40 -0700, Lloyd Budd wrote:
>> For example, step in my time machine:
>> 2.1.4 would have been released if new severe security issues, instead
>> of focusing that we were really close to releasing 2.2 and that it
>> addressed the issue.
>> 2.2 released
>> 2.1.n released if any new severe security issue
>> 2.2.1 released
>> 2.1.n released if any new severe security issue, waiting on feedback
>> regarding 2.2.1 then retire 2.1 branch.
> 
> I absolutely agree! Security fixes must be installed quickly, and admins
> must be sure that there are (almost) no functional changes beyond what
> the fix does. Feature upgrades may need the right time for deployment,
> and if a security fix comes only with a major feature upgrade, people
> tend to resign from upgrading. So I also think that it is crucial to
> distinguish between security releases and feature upgrades.
> 

I am not quite convinced that this is the right way to go about it.

At present we have a security only supported version (v2.0.x) and if
security above features is your bag then this is what you should run.

However, we should always release a security update to the current
version if an issue exists even if the next feature release is to be
within the next couple of days.

To summaries:

On Day x current version is 2.2.7 and exploit y is published then we
should asap release 2.2.8 with a fix.

However if the current version is 2.3 then the security fix should go
into 2.3.1 - and probably any other non-security fixes that have already
been made but have not had sufficient testing should be kept until 2.3.2

In general in order for an efficient development process you need to
ensure that you are supporting the minimum number of code sets.

What we really need is a clear concise security response policy, that
defines the process under which issues are handled from notification
through to release (preferably with a quick but achievable timeline).

We should always be able to respond to security issue(s) with a new
point release of the currently supported version which just fix the
issue(s) - this makes it very safe for people to upgrade.

westi
- --
Peter Westwood
http://blog.ftwr.co.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGbbebVPRdzag0AcURAqfcAJ4ldu4/rWoAoh2MJVqLHok259JkfwCffQ5A
hx9OoXMHrAwXdBSeIffaQlg=
=2HDg
-----END PGP SIGNATURE-----