Apply for permission to opt into security advisory coverage

Last updated on
24 June 2023

Shared accounts are not allowed to commit code in Drupal.org repositories as per Drupal.org Term of Service / Accounts. For that reason, applications created by shared accounts are closed as won't fix.

Instead, each developer needs to create an account that used only by a single person and use that account to create an application.

Please read Security advisory process and permissions policy carefully. Once opted into security advisory coverage, you may not opt-out. Only the Security Team will be able to change this.

The purpose of these applications is giving to the user who applies a Drupal role. Once the role is assigned, it is not necessary to create another application, as it would just end up with assigning the same role already assigned.

You may go through a one-time review process to get permission to opt your opt projects into security advisory coverage.
This shows users they can be more confident in running your project on their site and re-affirms your agreement to work with the Drupal Security Team when necessary.

Purpose

The purpose of these applications is assigning a new Drupal role (vetted) after verifying what the user who applies understands of writing secure code that follows the Drupal coding standards and correctly uses the Drupal APIs, following the Drupal best practices, and promoting collaboration over competition.
While the application require users to choose a project they created, and for which they committed the code, the focus of the application is not the project but the users who apply, who will get a new Drupal role necessary to be able to opt into security coverage for projects they created or they will create.

Prerequisites

Before opening an application, please check the issues reported by phpcs --standard=Drupal,DrupalPractice for the project that will be used for the application and fix everything that needs to be fixed. That alone fixes most of what reviewers will report. Although it does not resolve every issue, it makes the application approval faster.

Before entering the project application process, the following conditions must be met.

  • There are not other, still open, applications from the same user. This includes postponed applications.
  • The user who applies is not yet able to opt projects into security advisory coverage.
  • The user who applies has committed code in the project used for the application (not an issue fork created to fix an issue in an existing project). Those commits must be (preferably) the only ones done in the branch used for the application, or be most of the commits for that branch.
  • The account used to create the application (and to commit code in the project) is not a shared account, as shared accounts are not allowed to commit code on Drupal.org repositories.
  • There is sufficient PHP code to see what the user who created the application understands of Drupal coding standards, Drupal APIs, and Drupal best practice; a project that only implements a hook or two to, for example, add a library (CSS or JavaScript) to most or all the Drupal pages does not contain sufficient PHP code for these applications.
  • The code needs to be as close as possible to release candidate quality code. The project is not required to have releases, nor do releases need to be created during the application process. The project just needs to have all the necessary code implemented (which means there should not be empty functions/methods or with a comment that says the code will be implemented later) and without debugging lines.

Application process description

  1. Obtain basic Git access and create a project for your code.
  2. Get your project into a state you feel is release-ready; ideally, you would commit the project early and have a track record of several weeks/months of commits so that application reviewers can get an idea of your development and maintenance style.
  3. Have a look at the security advisory coverage applications checklist and try to resolve the common issues.
  4. Once ready, create a new issue in the Drupal.org security advisory coverage applications queue.
  5. Fill out the issue form.
    • Title: The branch name and the project name (For example, for the 2.0.x branch of the Spam control project, the title would be [2.0.x] Spam control.)
    • Category: Task
    • Status: Needs review or, if you want reviewers wait before review the project, Active
    • Component: Select the option that better describes the type of project used for the application
    • Description
      1. Write a detailed description of what your project does, including how it is different from other, similar, projects (if applicable)
      2. For themes, a screenshot is also helpful
      3. Add the link to the project page
      4. Add the list of links to reviews of other project applications that you did
  6. Reviewers will then examine the project files and provide feedback over the coming days/weeks (again see Review process for security advisory coverage: What to expect). Please be patient, and make the requested changes.
  7. As the application process is fully volunteer driven, many of our most active reviewers may use the review bonus program to prioritize which applications they review. This program gives priority to those who are also helping to review other applications. Participation is not mandatory, but it does provide a significant fast-track through the applications process. Due to limited resources, it could otherwise take a number of weeks between reviews of your own application. To participate in the Review Bonus program, review three other applications and reference them in your own application. We are a community and we help each other, so we are counting on you!
  8. Once given the sign off, you will be able to opt all your projects into security advisory coverage.

    Once this comes into place, there is no need to submit another application for review, since (at this stage) you are considered a trusted contributor.

What happens next?

Once the application is set as fixed, and you have got the role that allows you to opt projects into security advisory coverage, you can edit the project to change the value assigned to the Security advisory coverage field.
You will be able to opt into security advisory coverage every project you create, including the ones created in the past. There is no need to open a new application for a different project.

See Application checklist and What to expect from the review process for more information on the application workflow and how to make the application approval faster.

FAQ

Where do I see if I can opt projects into security advisory application?

On your profile page, you will read Can opt projects into security advisory coverage, as in the following screenshot.

screenshot

Users who cannot opt into security advisory coverage will not see that phrase on their profile.

Do I need to apply for each new project I create?

You need to apply only once.
Once the permission to opt into security coverage is given, you will be able to opt into security coverage for all the projects you will create and for every project you already created.

Do I need to create a new release each time I fix what reported in a review?

We do not require that the project used for the application has releases. All the code can simply be committed in a branch. We expect the code is complete for the features described in the project page and close as possible to release candidate quality code. This means, for example, the project should not contain debugging code, or that the most important hooks/functions/methods, without which the project would not work as expected, must be implemented.

Do you verify the project used for the application is free from bugs?

We do not review projects to fix all the bugs in the code.
Reviewers could try to run the project, and report problems they had with the project, but that should be done to point out the code is possibly using the Drupal API in the wrong way. It should not be done to make the code 100% free from bugs.

Can I apply using a project for which I am offering to become maintainer?

You can only use a project for which you committed most of the code in a branch for that project.
This means that, for example, if you are co-maintainer of that project and you want to become maintainer (user with all the permissions on that project), or the new project owner, then you can use that project for the application, as long as there is a branch in that project with code committed mostly by you.

Can I apply using an issue branch I created for a project?

An issue branch or a merge request cannot be used for these applications, as the reviews done for these applications can require changes that are not allowed in an issue branch, which is instead used to fix a particular issue in a project. For example, an issue created to change code that uses a deprecated function or method cannot be used to fix the content of the README.md file, while a review done for these applications could require you to change the content of that file, or other files.

When I apply to be able to opt into security coverage and the application is marked as fixed, will all the maintainers of the project used for the application be able to opt into security coverage?

Only the user who created the application will be able to opt projects into security advisory coverage. The other co-maintainers/maintainers of the project who cannot opt projects into security advisory coverage will need to create individual applications.

Can a user who works on the same organization I work create an application to be able to opt into security coverage using a project where I committed all (or most of) the code?

A user who works on the same organization you work cannot use a project with code committed by you for these applications.
These applications are for users, not projects, nor organizations. We need to understand what the user who applies understands about writing secure code that correctly use the Drupal API and follow the Drupal coding standards. All we do is giving to the user who applies a new Drupal.org role that makes the user able to opt into security coverage; we do not change the project status.

Do I need the permission to opt into security coverage to become a project (co-)maintainer?

When the project opted into security coverage, site moderators will not add as co-maintainer/maintainer or new project owner a user who cannot opt into security coverage. When it is one of the project maintainers who handles the offer to become co-maintainer/maintainer, the project maintainer could require you to be able to opt into security coverage, or simply add you even if you cannot opt projects into security advisory coverage.

I applied to opt into security coverage advisory, I got the permission, but when I edit my project, I am not still able to opt the project into security coverage advisory. Why?

When the project is not at least 10 days old, it is not possible to edit the field to opt that project into security advisory coverage. The field will appear as in the following screenshot.

screenshot

When the project is 10 or more days old, that field will appear as in the following screenshot and you will be able to opt the project into security advisory policy.

screenshot

Help improve this page

Page status: No known problems

You can: