Security issues on git.drupalcode.org

security.drupal.org is being replaced with confidential issues on git.drupalcode.org

Working with issues

Reporting an issue

Report issues at https://git.drupalcode.org/drupal-security/issues/-/issues/new?issue[confidential]=true and use the project’s machine name in the title like machine_name: issue title , e.g. "token: access bypass in …". As part of triage, as a security team member, you can edit the issue to include the name if it is not currently there.

When the title is found, automation will create a private fork to include the project’s maintainers, add initial labels, and instructions. Work on any fix for the issue should happen within that private fork.

Access for collaborators

Security team members can grant someone access by including at the start of a line anywhere in a comment

/access @gitlab-username, @another-user

Multiple names are comma-separated. The username is the git.drupalcode.org username, which can differ from Drupal.org username. Contributed project maintainers are added at the time of issue opening and security team members will already have access, so won’t be added again.

This will grant them access to the security issue fork project, so they will have access to private branches in the fork and private merge requests.

And to remove access a similar feature exists:

/remove-access @gitlab-username, @another-user

It's recommended to use the removal comment to remind folks how to handle security issues, e.g.:

Cutting down access for principle of least privilege. Continue not discussing details of this issue, even within your own teams.

/remove-access @gitlab-username, @another-user

Labels

A list of labels on Drupalcode shows all the available lables, their meaning, how they are used, and their role in automation.

Security advisory drafting

Adding the label ”Security advisory::needed” will add a comment to prompt the maintainers to create an advisory.

Changing the project of an issue

Edit the title of the issue to be prefixed with the new project’s machine name. Like when the issue is created, a new private fork of the new project will be created.

If the issue is in fact an issue for the original project, the “closed (moved)” issue should be reopened.

Merge requests

When a fix is needed, use merge requests to propose changes. Take care to not push code to the canonical project, or make a public merge request.

You can make a read-only clone of the project using the https://… git remote URL. This will prevent accidental pushes from happening, and allow you to get upstream changes committed after the security issue’s fork was made.

You can either add the private security issue fork as an additional remote with git remote add or you can clone only the fork with git clone.

Always work in a branch, this reduces the risk of accidentally pushing the fix publicly, and clearly shows which commits are part of the fix. For example

• If the fix will be for the 1.x branch, you can git checkout -b 1.x-security
• If you’d like to make a minimal release with only the security fix, you can git checkout 1.0.0 then git checkout -b 1.0.0-security
• Branch names have no programatic significance and projects are free to choose their own convention

Once your fix can be reviewed, push your branch to the remote for the security issue. Review which remote is which with git remote -v

You can follow GitLab’s prompts to create the merge request.

• Double check the merge request target. It should be a branch in the security issue fork, not the public canonical project. Adjust the target branch if the branch you are fixing isn’t the default branch.
• Be sure to mention the issue in the description to link the merge request to the issue.

Fixing multiple branches

Every supported branch of the project that’s vulnerable will need a fix applied. This may mean you need to make a branch and merge request for each version being fixed. You can validate the fix in just one branch to start, and then see how it applies to other branches.

Drafting a security advisory

When asked, fill out the security advisory draft to the best of your ability. It will be reviewed and corrected by security team members as the fix gets closer to release. Drafting the security advisory when needed is a responsibility of project maintainers.

For more details, see Drafting a security advisory.

Releasing fixes

Follow instructions in the security issue for coordinated disclosure. Do not push the commit to the public project until instructed to do so. If you miss the security release window, do not push the commit publicly; instead, work in the issue to reschedule.

Merging

When instructed, use a diff to make the commit to the public project. The merge request is targeted at the forked project, so a merge will not fix the canonical public repository. We also want to limit details of the merge request disclosed publicly, so do not change the target project of the merge request.

Append .diff to the merge request URL, or click Code and select Download “Plain diff.” Save the patch and then use git apply on a Git clone of your canonical project for pushing the fix publicly. Commit with a generic commit message, to avoid exposing extra details, and push.

Then tag and create a release as usual, being sure to check “Security update” when making the security release.

Update the security issue to confirm the release has been made and security advisory are ready. A security team member will publish both when ready.