Page Comparison

This document is an extracted version of LMS/Studio Security Fix Process. Please consult this documentation for details and explanations, This document will only provide steps by step procedure and doesn't discuss technical details. 

1. Ensure that the edx-platform-private:security-release branch is up-to-date. 
   1. If the branch is out-of-date and not tracking edx-platform:master closely (as will likely be the case):
      1. In GoCD, trigger the edxapp_private_public_merge_sync pipeline manually and ensure it completes successfully.

      2. 
         

         Note
         FSheets - Working to get this to be an automatic daily job

         
         

2. Clone edx-platform-private repo locally (Pull the latest changes if you have cloned the repo already).
   1. git clone git@github.com:edx/edx-platform-private.git
3. Create a branch off edx-platform-private:security-release (repo:branch)
   1. git checkout -t origin/security-release
   2. git checkout -b <branch_name>
4. Add the security fix commits to your branch.
5. Push the branch.
   1. git push --set-upstream origin <branch_name>
6. Create a pull request using edx-platform-private:security-release as its base branch with the following template in the PR description. 

   
   

   Code Block

   This is a security fix. Please read important process notices below. **NOTE:** Once the PR is marked as approved it will be deployed to production. DO NOT approve until you are ready for the patch to go! **NOTE:** Do NOT merge the PR after approval! Although there can be multiple reviewers, only one developer should approve the PR using the "Review changes"→ "Approve" → "Submit review" flow but should not merge it! Private Deployment: - [x] Squash changes. - [x] Approved and deployed to Production. After Private Deployment: - [ ] Send notification with patches. - [ ] Wait 48 hours. Once Deployment can be made Public: - [ ] Merge PR - A PR will automatically be created on public repo.

   
   

7. Request reviews of your PR from one developer but do not merge it!!
   1. The developer should approve the PR using the "Review changes"→ "Approve" → "Submit review" flow
   2. NOTE: Once the PR is marked as approved it will be deployed to production.  DO NOT approve until you are ready for the patch to go!
8. Code Deployment.
   1. Deployed to Staging
      
      1. The next edxapp release pipeline deploys to the stage environment will include the approved private PR commits.
      2. Please verify your changes on stage. 
      3. If you are unsure if Stage currently has your changes (), visit this page for more information >> /wiki/spaces/RELEASES/pages/182780356
   2. Deployed to Production
      
      1. When the stage release candidate is advanced to production, the production release will include the approved private PR commits.
      2. Please verify your changes in production.
      3. If you are unsure if Prod currently has your changes, visit this page for more information >> /wiki/spaces/RELEASES/pages/182780356
9. Send email notification with patches (both for master and the latest open edX branch), for more details LMS/Studio Security Fix Process
10. Wait for 48 hours after the email notification 
11. Make the private fix public
    1. Merge the private PR into its base branch, edx-platform-private:security-release.  NOTE: Do NOT rebase the PR - or the PR's branch!
       1. The bot creates a pull request against master in edx-platform.
       2. The tests will run against your PR
       3. The automation will merge the pull request automatically after the tests pass.
12. After the fix has been made public, the patch has to be applied on the latest upcoming open edX release. 
    1. At the time of writing this document, that next release is Ironwood. Check in the #openedx Slack channel if you are not sure about the current release.
    2. The open edX branch is present on the edx-platform, with format open-release/release_name.master. e.g. open-release/ironwood.master.
    3. Create a branch off that open edX branch and apply the patch.
    4. Push your branch & create a PR against the open-release/release_name.master branch. Wait for the tests to pass.
       1. If there are any failures, you will have to fix them.
    5. Get your PR reviewed from someone in the open edX channel.
    6. Merge the PR after getting the approval.
13. Send out general notifications as documented in Security Disclosure Reporting and Resolution.

Troubleshooting

Tests failing on the edx-platform PR created by the bot

If the tests are failing on the PR created by the automation on the edx-platform, it is possible that some requirements or test changes were incorporated during the time period of your security fix. Since the rebasing is not allowed, an available option is to merge the latest master into that branch and push it. See this PR for the example. You can do it as following:

1. Get Latest master: git pull origin master

2. Get the remote PR branch on your local: git fetch origin PR_branch_name:PR_branch_name

3. Checkout to the PR branch: git checkout PR_branch_name

4. Merge the master: git merge master

5. Push the changes

Notes and guidelines

1. Email Notifications
   1. When you send a notification, your audience is external people, please avoid internal jargon that will just confuse people. i.e. Do not mention your team name or any internal team information. 

Feel free to ask any question if you come across and make these steps even simpler.  

...