...

⏰ After getting a “New security vulnerability” email from security@openedx.org

1. Fix the vulnerability in a temporary private fork. Do not merge yet. [GitHub docs]

2. Post a release time in Security Announcements.

   1. Don’t post until you test your fix.

   2. Note: topics in Security Announcements are moderated. They may take a little time to appear publicly.

   3. Make the release time on a weekday at least 48 hours after your post.

   4. Template:

      1. Title:

         Code Block
         Security: Upcoming Security Release for {{repository_name}} on {{YYYY-MM-DD}}

      2. Body:

         Code Block
         **openedx/{{repository_name}}** version **{{version_number}}** will be released on [date={{YYYY-MM-DD}} time={{HH:MM:SS}} timezone="America/New_York"]. It will fix one security defect with a "{{severity}}" [CVSS 3.1 severity rating](https://nvd.nist.gov/vuln-metrics/cvss). Details will be published here after release: [GitHub security advisory]({{github_security_advisory_url}}).

   5. Example:

      1. Title:

         Code Block
         Security: Upcoming Security Release for xblock-drag-and-drop-v2 on {{2023-01-24}}

      2. Body:

         Code Block
         **openedx/xblock-drag-and-drop-v2** version **3.0.0** will be released around [date=2023-01-24 time=12:00:00 timezone="America/New_York"]. It will fix one security defect with a "high" [CVSS 3.1 severity rating](https://nvd.nist.gov/vuln-metrics/cvss). Details will be published here after release: [GitHub security advisory](https://github.com/advisories/GHSA-3244-8mff-w398).

3. Around release time, within a 2 hours window:

   1. Merge temporary private fork. [GitHub docs]

   2. PR and merge the fix to the active release branches:

      1. open-release/<current-release-name>.master

      2. open-release/<next-release-name>.master, if it already exists

      3. Find release-names in https://docs.google.com/spreadsheets/d/11DheEtMDGrbA9hsUvZ2SEd4Cc8CaC4mAfoV8SVaLBGI/edit

   3. Link the PR(s) for the active release branches in #wg-build-test-release

      1. This way, BTR can take any actions needed to include your PR in releases.

   4. Publish security advisory. [GitHub docs]

   5. If this is a library, publish the new version to PyPI or NPM

   6. Reply to your Security Announcements post with the PR URLs:

      1. Template:

         1. Body:

            Code Block
            This security fix has been published. The fix has been merged to: * `{{main_branch}}`: {{main_branch_pr_url}} * `open-release/{{supported_named_release_1}}.master`: {{supported_named_release_1_pr_url}} * `open-release/{{supported_named_release_2}}.master`: {{supported_named_release_2_pr_url}}

      2. Example:

         1. Body:

            Code Block
            This security fix has been published. The fix has been merged to: * `master`: https://github.com/openedx/edx-platform/pull/31353 * `open-release/nutmeg.master`: https://github.com/openedx/edx-platform/pull/31354 * `open-release/olive.master`: https://github.com/openedx/edx-platform/pull/31353

See For maintainers.

🩹 Apply a security patch to a Python or NPM package

...

1. Merge the fix into openedx-animals' main branch.

2. Release openedx-animals==3.1.1 from its main branch.

3. In edx-platform and credentials, upgrade the openedx-animals version pin from 3.1.0 → 3.1.1.

4. Considering: is the openedx-animals version used in Zebrawood compatible?

   1. It is a major release behind (2.5.0 vs 3.1.1), so assume no.

      1. Check-out openedx-animals==2.5.0 and create an new branch: security/2.5.1

      2. Apply the security fix to this branch.

      3. Release openedx-animals==2.5.1

      4. In both edx-platform and credentials, on branch open-release/zebrawood.master, upgrade the openedx-animals version pin from 2.5.0 → 2.5.1

🛠️ Apply a security patch to a Django Service

1. Before you start working on a security issue, ensure that you have a GitHub security advisory that has been created by the security working group or yourself.

2. On the advisory, create a new private fork on which to make any fixes.

3. Add your changes to a new branch on the temporary private fork.

4. Create a new pull request so that your changes can be reviewed.

   1. The new PR will not run tests because actions workers can’t get access to the private fork. (Link)

      1. Image Added

5. Get the PR reviewed an approved.

6. BEFORE MERGING

   1. Post a Security Announcement 2 business days before merging that you will be merging a security fix and the level of importance of the fix (Example text below, update the date, severity level and second link.)

      Code Block

      A security patch for **openedx/edx-platform** will be added to the **Palm** release and to the current github master branch around [date=2023-07-25 time=15:00:00 timezone="America/New_York"]. It will fix one security defect with a "critical" [CVSS 3.1 severity rating](https://nvd.nist.gov/vuln-metrics/cvss). Details will be published here after release: [GitHub security advisory](https://github.com/openedx/edx-platform/security/advisories/GHSA-blah-blah-blah).

7. Merge the fix to the current main branch. Backport it to the currently supported named release.