Posted by shrop on October 29, 2017 at 9:03pm
I have questions about Drupal distributions and their security coverage. If a Drupal distribution has security coverage and modules contained in the distribution do not:
- Do the distribution's maintainers accept security coverage responsibility for the non-covered module?
- What are the other implications and gotchas in this scenario?
Thanks!
shrop
Comments
Exclude distros entirely?
Given the problems with coverage for distros, should they just be excluded from security coverage entirely?
Exclude distros entirely for now?
As a distro maintainer, I try to update it as soon as possible when a security release comes out. In the meantime, on the distro's project page, it says the current release is covered by the the security advisory policy and it gets the green badge icon. I wish it would not appear secure until I updated it.
For now, excluding distros from security coverage seems better than the way it is now. It is sort of misleading right now, perhaps.
Panopoly does a release
Panopoly does a release within 48 hours (but usually same day) when a security update is released for one of the modules it includes. However, that has nothing to do with security team coverage - we do that as a project policy.
If the security team had the tooling to stay on it automatically somehow, I think it might make sense to make an insecure module be a security issue in a distro? But without that, it'd be a big drain on time for the security team and end up being inconsistently enforced.
What about the code in a distro that just part of the profile and not from a module? If we just say that distros don't get security coverage, how can we manage responsible disclosure for that code?
In the past we have not
In the past we have not issued SA's for distro unless there was code for the distro that had a security issue.
If a distro has an module that has an SA on it, we would not create another SA for the distro as all that distro does is include the module.
If we move to composer workflows for packaging then we might be able to do auto updates.
As another distro maintainer
As another distro maintainer I would be sad to see this issue just "exclude distros from coverage" as this would heavily impact the usage (or non usage) of distros. Some clients will not use a distro if they think it isn't being covered when I know many distro maintainers work very hard to keep up with security updates.
To answer the original post, with Open Atrium as an example, the answer was "Yes, we took over security responsibility" specifically in that if a module used in Atrium had an SA, we would update the distro within 24-48 hrs (depending on the severity). If a module became unsupported we would either find a replacement or try to become a co-maintainer.
There are already status fields a distro can use to indicate if it is actively maintained, etc. Also, a distro that does not update in a timely manner can already opt-out of security coverage (which should remove the badge).
Even though the badge icon on d.o doesn't update "in real time" when a module has a security update, if you actually use the distro you still get the normal security update warnings. It would be up to the d.o team to determine the resources and priority of improving the d.o icon, but don't personally see this as a big issue.
Perhaps distros just need a section in their project page describing their security policy to make people more aware?
I think an analogous
I think an analogous situation can help us decide what to do: what if a module (foo.module) that has security coverage depends on another module (bar.module) and the bar.module does not have security coverage? That is entirely possible and there are probably several examples of it right now as well as in the past. I don't think it's the responsibility of the maintainer of foo.module to jump in for bar.module, but it certainly happens and is probably healthy to help the module you rely on.
I think distributions should get security coverage for the code in the distribution itself regardless of code that gets packaged along with it.
I realize it's a big request, so this is totally optional: It would be nice if distribution maintainers (or their coworkers) could agree to maintain modules that are unsupported by the security team.
If a module is not covered by the security process and is included in a distribution that is covered, it would be a good idea for the distribution maintainer to subscribe to issue notifications about that module or just periodically looked for issues that are critical and tagged as security. Security issues will be published in public for those modules and will not get an advisory, so the maintainer needs to take extra steps to be aware of them so they can help the issue get fixed and a new release published ASAP (new release of both the module and the distro).
knaddison blog | Morris Animal Foundation