Define a policy on how to handle security issues opened on drupal.org for security-team-supported projects

DamienMcKenna's picture

We need some clarification and standardizing around how to handle an issue logged on the public drupal.org site for a project which is covered by the security team. There currently isn't a standard process, though the following appear to be the defacto process:

  • The node is unpublished.
  • An sdo issue is created if needed.
  • The person is added to the sdo issue.

This leaves a few open questions:

  • Webmasters looking at an unpublished node may not be aware of why it's unpublished and might mistake it for e.g. spam.
  • If a revision comment is left when the node is unpublished it won't be particularly obvious to webmasters.
  • It isn't currently possible / easy to get a list of all public issues that were unpublished for security reasons.

Proposal:

  • Unpublish the issue.
  • Add the following tag to the issue: security
  • Add a comment that the issue was closed for security purposes and will be followed up on separately, or some standard sentence that explains what's going on.
  • Look for an existing sdo issue for the bug.
  • Invite the reporter (plus anyone who worked on any patches, if applicable) to the sdo issue.
  • Update public documentation to disclose this process.

Outstanding questions:

  • Would it be useful to add a filter to admin/content/node on drupal.org to specifically look for the security tag? Or maybe just add a generic tag filter?
  • Should all webmasters be notified of the workflow, or would a documentation change be enough?

Comments

The "security" tag is used a

greggles's picture

The "security" tag is used a lot, so I don't think that will work to denote anything special. I suggest something unique like "unpublished for security" to uniquely identify them.

I think https://www.drupal.org/node/1750902 should be considered as well. My sense is that https://www.drupal.org/node/1750902 was written before our current system where maintainers can be invited. We could change that and/or remove it from the process now that they will get an automated email when the reporter/maintainers are added to the s.d.o issue.

Great idea!

dsnopek's picture

Great idea! I've had the experience a couple of times that a public issue I unpublished to move to s.d.o got published again, then I unpublished it again, and it got published again. :-) These steps would probably help with that!