Making a public issue for security.drupal.org issues with status "Needs public followup"

What security issues can be public?

Do not make a public issue for a security bug. Security issues need to be considered by the security team before being public.

Related/Background documentation

1. How to report a security issue with Drupal core, contrib or Drupal.org
2. Message Template: Vulnerability which can be fixed publicly because it requires an advanced permission

Rationales that the security team might provide for making public versions of security issues:

1. Exploit is very difficult to do or cannot be automated.
2. Exploit requires advanced permissions
3. The vulnerability is information disclosure, denial of service, content injection, or other category covered by PSA-2023-07-12

Make a public issue for a security.drupal.org issue with status "Needs public followup"

Only make a public d.o issue for s.d.o issues that have already been marked by the Security Team as needing a public issue. For general procedure on how to report a security issues, follow How to report a security issue with Drupal core, contrib or Drupal.org.

When in doubt, ask a (another) security team member. They are nice and helpful.

1. Sometimes a member of the Security Team may be working with someone who is not a member of the security team to help create public issues. Security Team members can give non-team members access to individual private s.d.o issues and other unpublished documentation such as PSAs.
2. Read through the security issue. Note information that should not be public as you are reading such as exploitation details.
3. Pick a public place for the issue.
   • If a public issue did exist at one point, but was unpublished by the security team to be handled in private, it might be appropriate to be re-published.
     • If the unpublished issue contains exploit details a new issue should be created instead of re-publishing it.
   • If creating a new issue, create an issue in the appropriate project. For core issues use the "Drupal core" project. This link is useful to create a core issue with the "Bug report" category and the "Security" tag. Make sure the version of the project matches the (most recent version) the bug effects. (Some security issues for example, might effect only D7 so the public issue would be for 7.x-dev, or might effect both D7 and D8 so the public issue would be for 8.y.x-dev .)
4. In the public issue summary,
   • Follow the best practices in the Contributor Task document about writing an issue summary including using the issue summary template to write/update the public issue summary.
   • Much of the information in the private s.d.o issue is not appropriate to copy over to the public issue.
     • Make sure the public issue does not contain details of how to exploit the bug.
   • Include a link to the s.d.o issue, with a note so people who try to click on it understand why they might get access denied, for example:
     

     <h3 id="summary-background">Background information</h3>
     
       <ul>
         <li>security.drupal.org private issue: https://security.drupal.org/node/NNNNN
         (included for reference. Please do not report access denied as an error.)</li>
       </ul>
     

   • Include the reasons this particular issue is OK to be public.
   • Add the usernames of people who worked on the private s.d.o issue to the public issue so they can get credit. (Or, if a maintainer of the project, add the users to the "Credit & committing" fieldset.)
   • Verify tags on the public issue include the "security" tag.
   • Attach the most recent patch from the s.d.o issue to the public issue (matching the version of the issue).
     • Caution. Some patches might have tests that could include exploit information that should not be public. When in doubt,
       ask a (another) security team member.
   • If the private s.d.o issue had patches for multiple versions, follow the project backport guidelines. For example, the Drupal Core backport policy is that there should be separate issues for D7 and D8. They should be related (linked) to each other.
   • Set the public issue status appropriately. Typical status for a public Drupal Core issue based on a s.d.o private issue are "Active", "Needs review", or "Needs work".
5. Update the s.d.o private issue.
   • If questions or concerns have arisen, document them by making a comment on the s.d.o issue.
   • If a public issue was created or re-published, comment on the s.d.o private issue to say a new issue was created (or, that the unpublished public issue was published) and include a link to the public issue.
   • Change the status of the s.d.o issue to "Closed (can be public)".