[wp-hackers] WordPress 3.0.3

[Andrew Nacin]

2010/12/8 Mitch Canter <mitch at mitchcanter.com>

>
> Sorry, maybe I mis-spoke as to what I meant.
>
> I know that there's release posts and changesets, but I mean more of a
> "security release lifecycle".
>
> Etc: Someone finds a bug, it gets reported to trac, some things happen,
> then a security release is done.
>
> I'd like to fill in the blanks as to what happens from start to finish and
> get a complete look at "this is what happens when we find a bug that is
> urgent enough to get a security release".


Please don't report it to Trac. That's a huge no-no. Security
vulnerabilities should never be reported to any project in the open.

Security issues should go to security at wordpress.org. See
http://codex.wordpress.org/FAQ_Security.

Basic lifecycle: Vulnerability is reported to that email, which goes to the
core team and a few others. It is reviewed and discussed privately. If
legitimate, a fix is privately prepared. We privately decide on a timeline
and method for release, based on the severity of the vulnerability and
whether it has already been disclosed elsewhere. We then test it privately
until we are ready to commit it and offer a public release.

In this case, we were alerted to this vulnerability late last week, and took
appropriate steps over the days that followed to confirm and isolate the
issue, prepare a fix, do a full audit of the capability checks in XML-RPC,
and test everything thoroughly.

Security vulnerabilities are rare. 3.0.2 was released a few days before this
one was reported to us, hence two releases in 8 days. That's the only
explanation we have for two releases in a short time period. It's not like
we planned that.

I also described 3.0.2's lifecycle in a previous post to wp-hackers:
http://lists.automattic.com/pipermail/wp-hackers/2010-December/036276.html.
While 3.0.3's lifecycle spanned about six days, 3.0.2 was released four
hours after we were notified. Those are probably the two extremes.

Nacin