Ever since Drupal uses major versions for compatibility changes and minor versions for bugfix and security updates (since Drupal 5), it was most often the case that a new minor Drupal release included bugfixes and security fixes packaged into one update.
The process to bundle bugfixes and security fixes into one was so common that the Drupal 6.17 release that did not include security fixes but only covered bugs was a grand surprise to many people. We have even seen "security researchers" who ran automated version detection scripts, and considered sites not running 6.17 insecure. That a Drupal 6 release would include security fixes is that strong in the minds.
Most Drupal 6 releases however included numerous other changes. These in an ideal world do not affect your site and will only fix stuff rather then breaking anything. However, sometimes people find that the bugfixes result in side effects we did not think beforehand. Therefore sites where quality assurance (QA) is applied take time to ensure the new update do not break existing functionality.
To help people roll out security fixes without the requirement for lengthy QA cycles, we followed the tradition to make patches available (see for example SA-CORE-2010-001). These patches let site admins to quickly fix the site while the other fixes are in testing. However, running a patched Drupal is not for everyone, it should be done with careful attention. It also obscures Drupal 6's update module processes, since your site will tell you a security update is available, until you actually deploy the full thing. Drupal.org's usage tracking will see you are running an insecure version. Automated bots and script kiddies will register your site as insecure and attempt to run exploits. If you do not apply the patch however trying to stay away form killing kittens, your site will actually stay insecure.
So if you do not update to the security release, it's bad for everybody. If you do apply the patch but not the full release with bugfixes, it's bad for many reasons. Ideally, Drupal would provide an official release with the security improvements only, so you can choose to use that only and maybe later upgrade to include the bugfixes.
That is what the Drupal Security team discussed and arrived to at Drupalcon San Francisco. The decision was to make available actual security-only releases as well as a security plus bugfix release. This now makes it possible to just deploy the security fixes as soon as possible, without maintaining a Drupal fork. Then - given the usual timeframe of Drupal releases - you'll have plenty of time to review the other bugfixes and ensure they'll not affect your Drupal website in any wrong way. (Not that its expected that bugfixes could break your site, but it does happen).
This new process is applied first to Drupal 6.18 and 6.19 which were released at the same time. We tried to explain this new concept in the release announcement and the security announcement respectively. We hope this will help in rolling out security fixes quicker and that this new process is well received.
You can hear more about Drupal security at Drupalcon Copenhagen at the Drupal security - configuration and process session and at Drupal security for coders and themers.
The Drupal Security team can be reached at security at drupal.org or via the form at http://drupal.org/contact.
Quick confirmation
What about Drupal 6.20, the next security only release? Will it be based off of 6.18 or 6.19? I'm assuming 6.19 but confirmation would be helpful. I like the policy... allow admins one point release of time to regression test an update.
Exactly
Exactly. Otherwise we'd fork Drupal in two ways, one which only has security fixes since Drupal 6.17 and nothing else, and another where bugs and security issues are fixed. Thats not at all intended. All this new release approach does is it provides an actual point release for people who are only interested in security fixes but it does not make it the process to fork off from Drupal 6.17 indefinitely. People will have time until the next point release to figure out if they have issues with the bugfixes, the next security fix will include the previous bugfixes.
s/its bad for everybody/it's
s/its bad for everybody/it's bad for everybody/
s/its bad for many reasons/it's bad for many reasons/
thanks
Thanks, fixed.
So how does this work from
So how does this work from you the committer's point of view? Do you wait on committing bug fixes till after the security release has been tagged? or do you maintain a separate short-lived branch? This would of course be easier to do with Git, but how do you pull it off with CVS?
"short-lived" branch
If you look at the dropdown in http://drupalcode.org/viewvc/drupal/drupal/ listing the available branches, you'll see we have a DRUPAL-6-18-SECURITY branch. That is the new branch.
We basically keep having fixes committed to DRUPAL-6 and when the time comes for a security and a bugfix release, we branch from the previous stable tag (in this case I branched DRUPAL-6-18-SECURITY from DRUPAL-6-17). Then we commit the security fixes and version info to this branch and tag the next release from there. I tagged DRUPAL-6-18 on that branch.
Then on the regular branch (DRUPAL-6), we also commit the security fixes and tag the next release from there. So this release includes the security fixes as well as all bugfixes since the last release. This was DRUPAL-6-19 in this case.
Finally, once time comes for the next release, we do the same, so DRUPAL-6-19 becomes the base for the next security branch that is going to be DRUPAL-6-20-SECURITY.