$customHeader
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

⏰ 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: 

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

      2. Body:

        **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: 

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

      2. Body: 

        **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:

          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: 

          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

🩹 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

  • No labels
$customFooter