[wp-hackers] Development Process

[Brian Layman]

Robert wrote:
> Personally, I like the idea of a mailing list, but one
> that is closed to invitation only (and maybe with archives that are
> updated after each release for the public to see the discussion that
> took place).

I agree there has to be a limited number of people notified of security
issues as they are discovered and evaluated.  It seems that, as of 2.0.3,
the largest hole is fixed. But, that doesn't mean that large hole won't be
found again.  When something like that occurs, I'm sorry, but some attempt
to restrict its spread is warranted.

Conversely, I don't know how such a team could do quick security releases -
or even an SVN check-ins, in a way that the majority of sites will be
willing to apply these frequent updates.  

Maybe peter's update notification thing will help some, but it still means
work for people.  Releasing a critical fix that only a few sites apply is
practically the same as publicly discussing the original security hole.  And
most bloggers are not into blogging for the technical site of it.  Ever more
often they are people who don't enjoy spending hours playing with the
technical stuff.  They just want their sites to work.

There seems to be no easy fix for this that isn't just some pie in the sky
solution.... If the WordPress install had an md5 for each file and an
automatic update system that could apply fixes if the md5 matched the
version requirement for the fix, then security fixes could be released
quickly and applied to the majority of the sites at no pain for the users.
Strategic code changes and targeted fixes released long before the next
minor release that includes new features.  Pie in the sky...



Doug wrote:
> There needs to be a Dashboard widget that alerts blog owners to the fact
> that DrDave has updated SK2, that Mark J.'s Subscribe To plugin has
> patched a security hole, or that Skippy's Gravatars plugin now lets you
> select between curl() and fopen().

A similar, but more targeted idea might be to develop a plugin certification
process and a server that could respond whether a particular version of the
plugin has been certified or not.  

There would need to be a group of people that could look at plugins
submitted for approval.  They'd be experienced enough to do a once over to
verify that the current approved standard practices are applied.  This could
be done fairly easily with a set number of checks - Does the check the user
level before adding its pages?  Can any pages be accessed directly without
verifying user capabilities?  If fields are submitted, are the contents
filtered/protected?

If you wanted an automatic safety report on the plugin page or dashboard or
wherever, you could require each certified plugin have a GUID in its header.
A the plugin checking feature would send requests to the server with each
plugin's GUID and version.  The certification server, could respond with a
single character response: 
C = Certified/Current; 
O=Old/Out of Date; 
R=Red Flagged/Revoked Certification; 
I=Invalid/Incomplete Submission. 
That would be a relatively small server load.

The biggest thing, other than the volunteer recruitment, would be coming up
with the list of what certification means.  And that, pretty much, would
match a FAQ that should already exist anyway.  

_______________________________________________
Brian Layman
www.TheCodeCave.com