Security Updates to Drupal, Modules, and CiviCRM

A lot of work has gone into making it as easy as possible for anyone with basic site admin level skills to test an update to the Community Media Starter Kits. A clean copy of the ESK and MSK can be spun up on Pantheon for free in minutes. With the addition of https://www.drupal.org/node/2300357, site admin level users can override a module without ever seeing any code or an SFTP client. The links to spin up new Pantheon sites are now on the ESK and MSK project pages, so anyone can now do that too.

Contributions to Community Media Starter Kits are no longer limited to a select inner circle. The group of people contributing is larger than it's ever been and continues to grow with each release. Understanding the release cycle for the projects that make up the Community Media Starter Kits will help keep your site secure and running well.

Schedule for Drupal Updates:

Contrib security updates come out every Wednesday. Whether or not a that impacts the ESK, MSK, or DSK just depends on which modules have fixed issues that have been reported. Because security updates are made in private until the potential exploit has a fix, there is no way to predict when these will happen. But since individual sites can always apply the update as an override, we don't need an immediate response to these.

Core updates are different.

Core security updates are given windows in advance (normally the 3rd Wednesday of the month) and include ONLY the security updates in that release… no feature changes or other bug fixes. This makes it extremely unlikely that the security update will cause any issues if you are already running the previous update and give plenty of notice when an update may happen. Normally there is no advanced notice that a core security update will or will not happen in the Window.

While some sites update to the latest version of Drupal or CiviCRM using the dev snapshot of ESK and MSK, updates that don't include critical security updates or major functional improvements won't necessarily result in immediately rolling a new releases of the ESK, MSK, and DSK.

While the Drupal security updates combined with the security issues found in the rest of the stack (bash, SSL, PHP, Ubuntu, etc) make it seem like there is always something security related that needs to be updated, not all of these are a top priority.

The 7.32 update ("Drupalgedon") was unique in that many sites that didn't upgrade were compromised within hours of the announcement. This is why there was more advanced notice than normal about that update.

The updates since (7.33, 7.34 etc) have been "normal" security release in that it requires several things to be true in order for someone to hack your site, but still something that should get updated.

Because we can apply patches to the version of Drupal core we include in the distribution, we add or remove improvements and bug fixes at any time. The only drawback to not using the latest official Drupal release is the notification in the update status report.

Schedule for CiviCRM Updates:

CiviCRM reserves both the 1st and 3rd Wednesdays of the month for security updates (https://civicrm.org/security), but CiviCRM has been trying different ways to announce releases recently (https://civicrm.org/rc) so that organizations have a chance to test.

We are still using the 4.4.x release of CiviCRM since the initial testing of 4.5.x causes problems in several places many CMD groups have integrated. The move from CiviCRM 4.4.x -> 4.5.x will likely be as much work at the OG 1.x -> 2.x conversion and the CiviCRM 4.3.x -> 4.4.x upgrade. MNN footed most of the bill for the OG 1.x -> 2.x conversion… along with the required Node References -> Entity References and Auto Node Title to Auto Entity Label. channelAustin paid for a lot of the CiviCRM 4.3.x -> 4.4.x upgrade.

I've started the a 4.5 branch of https://www.drupal.org/project/civicrm_starterkit, but even just that and the base CiviCRM modules included like CiviCRM Cron have issues that will require several days to get that stable. It took hundreds of hours over several months to get all the issues the 4.3.x -> 4.4.x upgrade created resolved.

One option to slow the pace of change is in CiviCRM is to use the LTS version instead of the latest release (https://civicrm.org/blogs/dave-greenberg/long-term-support-lts-release-i...). Unfortunately the CiviVolunteer work MNN funded requires CiviCRM 4.5.x. Whether the MSK should stay on the same version of CiviCRM as the DSK, who is responsible to the 4.4.x -> 4.5.x upgrades, and when those upgrades should be done by is a much larger discussion we've been avoiding too long already.

Similar to Drupal, not using the latest version of CiviCRM results in notification to admin users.

Schedule of CMD Updates:

Like many things, the CMD update schedule has never been formalized. I'm committed to rolling out updates of the ESK and MSK to Pantheon "as soon as possible". Once packaged on Drupal.org and pushed to Pantheon, it is up to each site maintainer to actually apply these updates. I'll make a big deal (along with Pantheon and the Drupal and/or CiviCRM Community) about serious updates like 7.32, but site admins can either apply or ignore the less serious updates until they have time.

I don't think that pushing releases every 30 days is too often.

I don't think that asking maintainers, co-maintainers, and people who report issues to respond in 30 days is too much of a burden.

I also don't think it is fair to hold back all the work the other CMD groups have put into improvements at the the ESK and MSK. Some of the issues that now have fixes have been issues for > a year. The contributions towards these fixes are all being done openly, so it shouldn't come as a surprise to anyone who wants to follow the progress that a fix is now part of the distribution. People who don't follow the progress have the opting of reverting if an update causes an issue with their configuration… assuming they are testing and managing their backups will. The trade off between paying attention to what changes are made in a CMD update really isn't any different than blindly applying an update from Apple only to realize that it causes an issue with your FinalCut workflow.

You can either spend time up front staying informed or spend time reacting to unexpected consequences of a change.

When Drupal or CiviCRM have a security release, the improvements that have reached RBTC and/or a Fixed state will be included in the ESK and MSK. If there are no security updates, the question of when to package a new release is more subjective. Fortunately/unfortunately we've never had the issue of a backlog of bug fixes, improvements, and new features just waiting for the security release to force a new ESK, MSK, and DSK release. We're still scrambling to finish and thoroughly test updates with every ESK, MSK, and DSK release.