[meta] Improve security release update rate

Tagging to get on the UX team's radar. Good initiative!

Incidentally, the way that most desktop/mobile programs handle this is they inform me "We've just updated $foo application. Click here to restart." or else "BZZZT. You can't enter until after you've updated." I'm not sure if we could get away with exactly that here, but there's a very far cry from that and what is needed to perform upgrades today.

It might be worth a poll of some kind (maybe on g.d.o/core) to get broader feedback into the "Why don't you upgrade?" question. Off-the-cuff, I would say those reasons boil down to something like:

- Lack of education on the core/security update schedule to know when to look for updates.
- Upgrading core is a difficult and time-consuming manual process (#606592: Allow updating core with the update manager would help).
- Lack of education about the automatic upgrade capability in Drupal 7+ for contrib modules/themes.
- On a typical site with 50+ contrib modules, update notifications come out so frequently that e-mails about available upgrades get ignored.
- Unlike "Extensions/Apps" in browsers, mobile OSes, etc. upgrading a module can have complex ripple effects and is not a one-click operation, but requires setting up a test site, backing up your data, praying, etc.

Most of these are not easy to fix. :\

The security update rate is only important for issues that affect sites. It's reasonable to keep a vulnerable module around when that vulnerability doesn't affect the site.

As a personal interest I mailed some people that reported being exploited via the ckeditor issue (fixed way March 2012) why the site was running old code. A few responded. A lot of sites still haven't updated btw.

Select quotes:

Basically the site is not hosted by us and we don't have any maintenance contract so we didn't check it module updates recently. Another big problem IMHO that this is a big vulnerability and i think that needs a dedicated space of informations on the module page, otherwise it is quite hard to understand which are the risks.

[Update notification] lumps ALL updates together into the status module and creates 'error messages' for clients on even the slightest of updates. Clients see these as 'errors' when they are not and in order to turn them off, ALL update statuses need to be disabled. This includes security updates. Once they are told what the statuses are for, the clients will generally ask for them to be removed regardless of what they are for. [...]

Then you get the other clients who dont even care about the warnings and get accustomed to seeing them and they just ignore them because they've had those messages for so long.

There are so many updates that if that statuses module was enabled, there would be something to update every single day and thats not how clients operate.

Another issue is that there is no 'level' of criticalness in security alerts. Every alert is the same, whether its warranted or not and thats simply not going to fly.

Those are great data points, Heine. Thanks.

To expand on this point in #5:

The security update rate is only important for issues that affect sites. It's reasonable to keep a vulnerable module around when that vulnerability doesn't affect the site.

I took a look at all the security advistories for Drupal 7, and based on the information provided:

SA-CORE-2011-001

Two issues:

1. One mitigated by restricting access to administer themes and/or not having color.module installed
2. One mitigated by not using private files.

SA-CORE-2011-002

One issue, mitigated by not using a contrib node acccess module.

SA-CORE-2011-003

One issue, mitigated by not using private files.

SA-CORE-2012-001

Three issues:

1. One mitigated by not using aggregator.module.
2. One mitigated by not using openid.module.
3. One mitigated by not using field access modules.

SA-CORE-2012-002

Five issues:

1. One mitigated by not granting access to fields using the text filtering system (an unlikely scenario).
2. One unmitigatable due to a reliance on users being aware enough to detect an attack
3. One mitigated by not using the forum module.
4. One mitigated by not using private files.
5. One migitated by not using node access modules.

Due to the first two issues, this one is the first, affects-all-Drupal-sites-upgrade-right-away security advisory and corresponds to Drupal 7.13.

SA-CORE-2012-003

Two issues:

1. One issue mitigated partially by standard security practices, but not fully.
2. One issue mitigiated by not using openid.module.

This is the second issue that's a definite upgrade and corresponds to Drupal 7.16.

SA-CORE-2012-004

Two issues:

1. One mitigated by not having blocked users and/or not using core search.
2. One mitigated by using one of the web servers that account for 94% of web traffic anyway

SA-CORE-2013-001

Three issues:

1. One unmitigatable issue
2. One mitigated by not using book.module and/or not granting "use printer-friendly version" if you do.
3. One mitigated by not using private files.

This is the third issue that is a definite upgrade and corresponds to Drupal 7.19.

So, unless the security advisories are downplaying the critical nature of the security updates, there were only three security updates that every Drupal site should've upgraded regardless of their own situation: 7.13, 7.16, and 7.19 (7.19 just came out yesterday, so it's not really possible to judge its adoption rate).

Otherwise, unless you're using private files, one of the optional features Drupal core provides (book, forum, aggregator, color, etc.), or a contrib access module, there didn't seem to be anything compelling other than if you needed bugfixes for contrib compatibility.

If it is the case that the security advisories don't convey how critical the issues are for people where the mitigating factors apply, then it's definitely an education problem. Otherwise, any more nagging just becomes white noise: it's like the boy who cried wolf. Even the current situation is annoying and borders on being more noise than signal:

• Like Heine mentioned, update.module throws an error on every page even if the updates are extremely minor. It's less of a hassle for all parties except the admin in charge of updating to just disable update.module entirely.
• Subscribing to the security advisory newsletter is more convenient, but every advisory comes in its own email and they're staggered throughout the day. On a particularly high-volume Wednesday, that means getting email after email from the list every few minutes, and the really critical ones (i.e., core) get drowned out in the minutae of security advisories from modules I don't care about or have ever installed.

This is all to say that rather than throwing up more roadblocks or more nags or more information at people, maybe we can improve the signal to noise ratio:

• Create two levels of security issues: critical and not. The current system seems functionally meaningless: do people really understand the difference between highly critical, moderately critical, critical, and less critical?
• Provide better education and guidance for contrib authors on when and how to separate bugfixes from critical security updates. Perhaps something like git-flow?
• update.module should only nag when someone directly goes to the update page unless there's a critical security issue.
• Figure out a way to condense the information provided in the weekly security advistories. Perhaps instead of, or in addition to, one long email with a lot of boilerplate for each and every issue—contrib and core alike—there could be a digest version that touches on every issue, but expands on the really critical stuff in an executive summary?

Anyway, I know this was long: software administration—including a few dozen Drupal sites—has been part of my job description for several years and I've had a lot of time to think and stew about all the nagging. :P More of it doesn't make the job any easier, so I figured I had to say something.

I think the desktop software solution of downloading/installing for you is an example of a fundamental idea: make it easier to upgrade. There are lots of things we can do to help with that, but they are probably all small wins compared to the level of effort required to achieve them.

re #6: One trick about assigning "critical" levels is that something that is not critical to a certain site might mean certain business failure on another. There are definitely a few things we can try to add update module and the associated xml feed to reduce the noise it creates:

* A sense of trusted roles on a site and then the permissions to exploit becomes a field in the xml feed, that way update can know if an untrusted role has the permission to do something bad.
* A boolean in the xml for "affects private files" and "affects sites with node access" and then update module can check to see if either is in use.

Those three additions would reduce the naggy-ness of update.module but it also puts additional work on the security team to figure out exactly which permissions are impacted (and we may not know them all, especially if custom code or a contrib does something).

I did a small review of Joomla! and Wordpress in this area - WordPress lists updates but doesn't nag you nor mention if any future updates are security related. The upshot is that the WP admins I talked to thought they were secure even though they had pending updates - they just didn't know that the pending updates were security related.

I do hope we can find some ways to improve this.

Updated issue summary.