Help BTR Establish a Process for Taking Django Security Fixes

[feanil]

Playbook for frontend: https://openedx.atlassian.net/wiki/spaces/COMM/pages/3664412693/Applying+a+security+patch+to+a+package

Original conversations:

• On process for backend security patches
• On creating a playbook for frontend security patches

[kdmccormick]

Another conversation:

• On responsibility for backporting security patches to named releases

[pshiu]

Open question for BTR:

• Does the injection of proactive security fixes into named release branches impact BTR's testing processes?
• Would it make sense to limit backports of proactive security fixes to a certain severity level?
  • (Security WG can come up with the severity level; but would this benefit BTR in light of the previous question?)

[pshiu]

Informally discussed with the 2U Open Source Process Working Group to gain more ideas. Summary:

• Security issues should not be considered fixed until they are backported.
• Idea: Get Dependabot alerts for non-default branches. But seems impossible: [GitHub docs]
• Named releases don’t run “make upgrade”. They (BTR?) apply Django security patches though.
• From a maintainer's point of view, it would be great if it were clear for them to know what they need to backport and what they don't because it will be taken care of by, e.g., BTR.

Source from 2U Slack

[alangsto]

Informally discussed with BTR group to create a new role to handle security updates for Django and Node.

There is an existing github workflow for updating dependencies in specified repositories, this could be used to update the Django and Node versions when a security patch is released.

[feanil]

Jorge is working to establish a BTR Security Patcher role. I'm working with him on the definition of that role.

[magajh]

Hey there! I'll be working on this issue

[magajh]

assign me

[feanil]

The workflow needs a bit more work because the vulnerability databases we were looking at were not getting updated very quickly. We'll need to update to have manual intervention to start the patching process.

[magajh]

Update: From the BTR team, we are currently working on an issue that focuses on monitoring security vulnerabilities in our release branches. This effort is closely related to this task and is likely to have a significant impact on the process of managing Django security patches.
Link to the issue: openedx/wg-build-test-release#317

[magajh]

Here is a draft document detailing the process we are currently following in the BTR to apply Django security patches:
https://openedx.atlassian.net/wiki/spaces/COMM/pages/edit-v2/3878060063?draftShareId=cfc59029-e858-44fd-bee6-ec7163d05d89

[magajh]

Here's what we've accomplished to help the BTR establish a process for applying Django security patches regularly:

• A "security patcher" role has been created within the BTR, thanks to collaboration between @jalondonot and @feanil. This role will ensure security for Open edX releases by collaborating with the Security Working Group, prioritizing patches, leading testing, documenting vulnerabilities, and keeping dependencies secure. This includes making sure Django security fixes are applied regularly.

• A document outlining the process for identifying and applying security patches has been created: link to document.

This process may evolve further once issue openedx/wg-build-test-release#317 gets fully addressed, but in the meantime, we have a defined process in place for regular application of Django security patches. So I think we are good to close this issue
cc @feanil