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

See For maintainers.

Apply a security patch to a Python or NPM package

Background

Per OEP-60, security patches need to be applied to main branches and then immediately backported to the most recent named release.

When a security patch is applied to a top-level repo (that is: edx-platform, micro-services, or anything else that has a open-release/<xyz>.master branch), backporting is easy: just merge the fix to main, and then cherry-pick the fix to the most recent release branch.

When the security patch is applied to a package that gets installed into another repo (specifically: Python packages and NPM packages), then it is more complex.

Playbook

1. Merge the fix to the package’s main branch.

2. Release a new package version from the main branch.

3. Apply that package upgrade to the main branch of the top-level repository/ies that use it.

4. Determine the version of the package that was installed into the most recent release. Does this version seem compatible to the new package version you just released?

   1. No →

      1. Create a branch off of the package version that is used in the most recent release.

      2. Backport the fix to that branch.

      3. Release another version of the package, using a lower version number so that it’s not considered the “latest” release.

      4. Apply that package upgrade to the release branch of the top-level repository/ies that use it.

   2. Yes →

      1. Just apply that package upgrade to the release branch of the top-level repository/ies that use it.

Example

Scenario: The openedx-animals package is installed into the edx-platform and credentials services. On main it is installed at version 3.1.0; in the most recent named release (Zebrawood) it is installed at version 2.5.0.

Process:

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. Open

         

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.)

      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.