-`$(ESR_VERSION)`: the Mozilla defined ESR version, used in various places for building tor-browser tags, labels, etc
-**Example**: `102.8.0`
-`$(RR_VERSION)`: the Mozilla defined Rapid-Release version; Tor Browser for Android is based off of the `$(ESR_VERSION)`, but Mozilla's Firefox for Android is based off of the `$(RR_VERSION)` so we need to keep track of security vulnerabilities to backport from the monthly Rapid-Release train and our frozen ESR train.
-**Example**: `110`
-`$(PROJECT_NAME)`: the name of the browser project, either `base-browser` or `tor-browser`
-`$(TOR_BROWSER_MAJOR)`: the Tor Browser major version
-**Example**: `12`
-`$(TOR_BROWSER_MINOR)`: the Tor Browser minor version
-**Example**: either `0` or `5`; Alpha's is always `(Stable + 5) % 10`
-`$(BUILD_N)`: a project's build revision within a its branch; many of the Firefox-related projects have a `$(BUILD_N)` suffix and may differ between projects even when they contribute to the same build.
-**Example**: `build1`
</details>
**NOTE:** It is assumed the `tor-browser` rebases (stable and alpha) have already happened and there exists a `build1` build tags for both `base-browser` and `tor-browser` (stable and alpha)
### **Bookkeeping**
-[ ] Link this issue to the appropriate [Release Prep](https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/?sort=updated_desc&state=opened&label_name%5B%5D=Release%20Prep) issues (stable and alpha).
**NOTE:**`android-components` and `fenix` used to have their own repos, but since November 2022 they have converged to a single `firefox-android` repo. Any backports will require manually porting patches over to our legacy repos until we have transitioned to ESR 115.
- [ ] Go through the `Security Vulnerabilities fixed in Firefox $(RR_VERSION)` report and create a candidate list of CVEs which potentially need to be backported in this issue:
- CVEs which are explicitly labeled as 'Android' only
- CVEs which are fixed in Rapid Release but not in ESR
- 'Memory safety bugs' fixed in Rapid Release but not in ESR
- [ ] Foreach issue:
- Create link to the CVE on [mozilla.org](https://www.mozilla.org/en-US/security/advisories/)
- Create link to the associated Bugzilla issues (found in the CVE description)
- Create links to the relevant `gecko-dev`/other commit hashes which need to be backported OR a brief justification for why the fix does not need to be backported
- To find the `gecko-dev` version of a `mozilla-central`, search for a unique string in the relevant `mozilla-central` commit message in the `gecko-dev/release` branch log.
-**NOTE:** This process is unfortunately somewhat poorly defined/ad-hoc given the general variation in how Bugzilla issues are labeled and resolved. In general this is going to involve a bit of hunting to identify needed commits or determining whether or not the fix is relevant.
### CVEs
<!-- CVE Resolution Template, foreach CVE to investigate add an entry in the form:
- [ ] Backport any Android-specific security fixes from Firefox rapid-release
-**NOTE**: Since November 2022, this repo has been merged with `fenix` into a singular `firefox-android` repo: https://github.com/mozilla-mobile/firefox-android. Any backport will require a patch rewrite to apply to our legacy `android-components` project.
- [ ] Backport patches to `android-components` stable branch
- [ ] Open MR
- [ ] Merge
- [ ] Rebase patches onto `android-components` alpha
- [ ] Backport any Android-specific security fixes from Firefox rapid-release
-**NOTE**: Since February 2023, this repo has been merged with `android-components` into a singular `firefox-android` repo: https://github.com/mozilla-mobile/firefox-android. Any backport will require a patch rewrite to apply to our legacy `fenix` project.
**NOTE:** All examples in this template reference the rebase from 102.7.0esr to 102.8.0esr
<details>
<summary>Explanation of Variables</summary>
-`$(ESR_VERSION)`: the Mozilla defined ESR version, used in various places for building tor-browser tags, labels, etc
-**Example**: `102.8.0`
-`$(ESR_TAG)`: the Mozilla defined hg (Mercurial) tag associated with `$(ESR_VERSION)`
-**Example**: `FIREFOX_102_8_0esr_RELEASE`
-`$(ESR_TAG_PREV)`: the Mozilla defined hg (Mercurial) tag associated with the previous ESR version when rebasing (ie, the ESR version we are rebasing from)
-**Example**: `FIREFOX_102_7_0esr_BUILD1`
-`$(BROWSER_MAJOR)`: the browser major version
-**Example**: `12`
-`$(BROWSER_MINOR)`: the browser minor version
-**Example**: either `0` or `5`; Alpha's is always `(Stable + 5) % 10`
-`$(BASE_BROWSER_BRANCH)`: the full name of the current `base-browser` branch
-**Example**: `base-browser-102.8.0esr-12.5-1`
-`$(BASE_BROWSER_BRANCH_PREV)`: the full name of the previous `base-browser` branch
-**Example**: `base-browser-102.7.0esr-12.5-1`
-`$(TOR_BROWSER_BRANCH)`: the full name of the current `tor-browser` branch
-**Example**: `tor-browser-102.8.0esr-12.5-1`
-`$(TOR_BROWSER_BRANCH_PREV)`: the full name of the previous `tor-browser` branch
-**Example**: `tor-browser-102.7.0esr-12.5-1`
</details>
**NOTE:** It is assumed that we've already identified the new ESR branch during the tor-browser stable rebase
### **Bookkeeping**
-[ ] Link this issue to the appropriate [Release Prep](https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/?sort=updated_desc&state=opened&label_name%5B%5D=Release%20Prep) issue.
### Update Branch Protection Rules
-[ ] In [Repository Settings](https://gitlab.torproject.org/tpo/applications/tor-browser/-/settings/repository):
- [ ] Remove previous alpha `base-browser` and `tor-browser` branch protection rules (this will prevent pushing new changes to the branches being rebased)
- [ ] Create new `base-browser` and `tor-browser` branch protection rule:
-**Example (if separate base-browser rebase was skipped)**: `git cherry-pick FIREFOX_102_7_0esr_BUILD1..tor-browser-102.7.0esr-12.5-1-build1`
- [ ] Rebase and autosquash **ONLY** these newly cherry-picked commits using the commit noted previously: `git rebase --autosquash --interactive $(PREV_HEAD)`
-**Example**: `git rebase --autosquash --interactive FIREFOX_102_8_0esr_RELEASE`
- [ ] **(Optional)** Patch reordering
-**NOTE**: We typically want to do this after new features or bug fix commits which are not !fixups to an existing commit have been merged and are just sitting at the end of the commit history
- Relocate new `base-browser` patches in the patch-set to enforce this rough thematic ordering:
-**MOZILLA BACKPORTS** - official Firefox patches we have backported to our ESR branch: Android-specific security updates, critical bug fixes, worthwhile features, etc
-**MOZILLA REVERTS** - revert commits of official Firefox patches
-**UPLIFT CANDIDATES** - patches which stand on their own and should be uplifted to `mozilla-central`
- [ ] Rebase and autosquash again, this time replacing all `fixup` and `squash` commands with `pick`. The goal here is to have all of the `fixup` and `squash` commits beside the commit which they modify, but kept un-squashed for easy debugging/bisecting.
-**Example**: `git rebase --autosquash --interactive FIREFOX_102_8_0esr_RELEASE`
- [ ] Compare patch sets to ensure nothing *weird* happened during conflict resolution:
- [ ] diff of diffs:
- Do the diff between `current_patchset.diff` and `rebased_patchset.diff` with your preferred difftool and look at differences on lines that starts with + or -
- diff `current_patchset.diff` and `rebased_patchset.diff`
- If everything went correctly, the only lines which should differ should be the lines starting with `index abc123...def456` (unless the previous `base-browser` branch includes changes not included in the previous `tor-browser` branch)
