Define a policy on how long distributions should wait before releasing security updates

DamienMcKenna's picture

One thing I've noticed is that there are no policies around how quickly distributions should be updated once one of their dependencies has a security update. It might be useful to have one. I'm sure there are some packaging / d.o UI improvements that might help with this too, e.g. https://www.drupal.org/node/2842816, or maybe an opt-in thing to automatically update distributions?

Comments

Transparency

fen's picture

The DoD requires that critical security (e.g. CVE) patches be applied within 30 days after their release. This has always seemed slow to me, but given required review, testing, etc. it's not an unreasonable target. Assuming that the distribution maintainers can be notified of an available security patch, would it be possible to add - under Project information - a list of relevant CVEs accompanied by the number of days (starting at 30 for critical partches) since that CVE patch was announced and not applied.

Note also that code containing a module may not be affected by a security issue, in which case noting this in a README and (preferably) inline with e.g. update_advances settings would suffice. This could prevent the above warning from appearing.

Do distros get their own SAs?

DamienMcKenna's picture

This also brings up the question of whether distros deserve their own SAs for bundling the updated dependencies? If not, it may be entirely possible to automate the generation of issues and patches..

greggles's picture

I think an SA should only go out for a project that has the vulnerable code in it. If that code (module, theme, distro) is repackaged as a dependency of another item then there should not be a second SA. It seems fine to me for a release of a repackaged item to be a security update, but there should not be an SA.

For example:

  1. Let's just say that Views has a vulnerability - an SA is released.
  2. Dozens of distros repackage views - they should not have an SA
  3. But as those distros update to includes the views release it would be acceptable for them to use the "security update" tag if they want

The reason I suggest this standard is this specific extreme case: dozens (hundreds?) of distros include Views so publishing an SA for each distro would require dozens of SAs which means more noise to site maintainers and more editing for the security team.

Automation of issues and CVE timer

shrop's picture

Automating the patches might be challenges since some distros patch Drupal core and it could break the distro. I do think automating issue generation that Damien mentions and some sort of CVE release timing notice per fen's mention would be two excellent enhancements.

I know with both Panopoly and

mpotter's picture

I know with both Panopoly and Open Atrium doing automated updates would be difficult. It's not un-common for a security update to break something and not every distro has a full set of automated test coverage. Often there are complex dependencies between specific module versions and patches. But I'm all in favor for improvements such as the one linked in the OP.

Distros can already decide to make an SA if an update is a considered crucial security issue. I've used that twice on Atrium to help encourage people to update the distro when there was a severe update to a dependent module or core. But in general I wouldn't want to release a distro SA every time some contrib module has a security update. Almost every monthly Atrium release would end up being an SA. So I look at SAs for distros more subjectively and try to think if it represents a security issue that is core to the functioning of the distro. Sort of like applying the existing risk calculator to the distro as a whole.

I don't think we can dictate a specific security update window for every distro. However, I think it is very important for every distro to make their update timeframe and policy clear. Maybe a required section in the Project Page would have that (now that you mention it, I should probably go add that to the Atrium project page right now!)

Automatic issue & patch creation?

DamienMcKenna's picture

What about automatically generating a new "release" issue and appropriate patch, so there's at least some movement towards a new release?

Would be great in theory but

mpotter's picture

Would be great in theory but tricky in practice. Similar to the Update module it would need to traverse the dependency tree for the distro make files. For example, the Open Atrium drupal-org.make only contains references to Panopoly modules and some direct oa modules, like oa_core. Then oa_core has it's own make file with references to other dependencies.

So, for example, if "Views" has a security update, that is referenced in panopoly_core.make, which is referenced in the openatrium drupal-org.make. If the Organic Groups module has an update, that is referenced in oa_core.make which is referenced in drupal-org.make.

In those cases, that patches are to the panopoly_core.make and oa_core.make modules, which results in new releases to those modules. Once those modules have releases, then the drupal-org.make file is patched to refer to those new release version numbers. I cannot run a final integration test using drupal-org.make until those new versions of panopoly_core and oa_core are available on drupal.org. So it's a multistep process.

In many cases, the distro was applying patches to these modules that were potentially included in the new release. So in the Views case, the panopoly_core.make file might also need to be edited to remove a patch or change the URL of a patch that applies to the new release. In most cases these changes are easy to detect because they break the drush-make process, but other times the changes are more subtle.

I use a script to help me make these updates (modules.sh in the openatrium /scripts folder) but it's still far from being automated. Honestly, while it's a manual process, the stuff like creating patches and issues isn't the hard part. It's all the testing that needs to be done that usually delays me the most.