On 10 Jun 2008, at 21:55, Kevin McArthur wrote:
Matthew et al,
There are three key issues.
1. How do security vulnerabilities get disclosed to Zend. Especially
serious ones that a vendor should know about before the public.
2. What will Zend do to ensure the bug is verified, fixed and patched.
3. How will Zend distribute those patches.
Possible solutions
1. We need a well publicized security contact point.
2. Zend needs to spin up a zf-security team to deal with issues in a
timely fashion.
I agree with these two points and they aren't especially difficult to
implement.
3. This is where it gets tricky:
So far, any bugs patched have been done so in the next version
(usually a point release) just as any other bug would be. You'd have
to be really on the ball to know whether or not you need to upgrade
to the latest point release due to a vulnerability.
So I propose:
That a USN page be setup to disclose security issues which require
user intervention. (Like upgrading applications)
That a fw-security-announce mailing list be setup to send emails
about recently fixed security bugs.
Not sure what USN stands for. I think that fw-announce should be used.
Security announcements are first class "announcement" citizens IMO.
Next,
Lets talk about Zend_Tool, version specific packaging, patching,
updating (backports) and the like.
My biggest concern is the availability of (or lack thereof) of
security-only patch sets for old released versions. Eg if one wants
to get security fixes for an application dependant on 1.0.0 -- they
shouldn't have to upgrade their applications to 1.0.X or 1.5.X newer
vers, as there are some compatibility problems in just upgrading.
It's certainly not something a sysadmin could just do.
I think that it's unrealistic to expect security updates for 1.0.0,
1.0.1, 1.0.2, 1.0.3, 1.0.4, 1.5.0, 1.5.1 and 1.5.2.
It's not unreasonable for a sysadmin to be able to update within a
minor series with no BC issues. (e.g. 1.5.1 to 1.5.2).
Personally, I think that security issues should be back ported to
1.0.x and released as a new version. Similarly for 1.5.x when 1.6
comes out. BC breaks at the x.y version change are inevitable and
upgrading costs money for sites that have been delivered to a client
(and hence invoiced).
Hence, I think that we should be even more strict on what is allowed
to happen on the release-1.x branches to ensure that they are
completely BC compatible, even if it means that incorrect
functionality has to live on in that branch.
There should ideally be something in Zend_Tool to automate the
process of checking for security updates, and applying them to a
specific framework version.
Whilst nice, I would prefer to be able to just update to the latest
x.y.z release in confidence of full security update and no breaks.
I'd also like to see a Zend_Security component that could check a
webservice to see if the currently running framework has known
vulnerabilities such that an application could be programed to shut
down instead of running insecurely. This would be a huge feature to
prevent the problems that have plagued other mainstream php projects.
I can't see any of my clients being happy with that :)
Rob...
