**NOTE:** All examples in this template reference the rebase from 115.17.0esr to 115.18.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**: `115.18.0`
-`$(ESR_TAG)`: the Mozilla defined hg (Mercurial) tag associated with `$(ESR_VERSION)`
-**Example**: `FIREFOX_115_18_0esr_BUILD1`
-`$(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_115_17_0esr_BUILD1`
-`$(BASE_BROWSER_BRANCH)`: the full name of the current `base-browser` branch
-**Example**: `base-browser-115.18.0esr-13.5-1`
-`$(BASE_BROWSER_BRANCH_PREV)`: the full name of the previous `base-browser` branch
-**Example**: `base-browser-115.17.0esr-13.5-1`
-`$(TOR_BROWSER_BRANCH)`: the full name of the current `tor-browser` branch
-**Example**: `tor-browser-115.18.0esr-13.5-1`
-`$(TOR_BROWSER_BRANCH_PREV)`: the full name of the previous `tor-browser` branch
-**Example**: `tor-browser-115.17.0esr-13.5-1`
</details>
### **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=Apps%3A%3AType%3A%3AReleasePreparation) issue.
### Update Branch Protection Rules
-[ ] In [Repository Settings](https://gitlab.torproject.org/tpo/applications/tor-browser/-/settings/repository):
- [ ] Remove previous legacy `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:
-**Branch**: `*-$(ESR_VERSION)esr-13.5-1*`
-**Example**: `*-115.18.0esr-13.5-1*`
-**Allowed to merge**: `Maintainers`
-**Allowed to push and merge**: `Maintainers`
-**Allowed to force push**: `false`
### **Identify the Firefox Tagged Commit and Create New Branches**
- [ ] Find the Firefox mercurial tag here: https://hg.mozilla.org/releases/mozilla-esr102/tags
-**Example**: `FIREFOX_115_18_0esr_BUILD1`
- [ ] Find the analogous `gecko-dev` commit: https://github.com/mozilla/gecko-dev
-**Tip**: Search for unique string (like the Differential Revision ID) found in the mercurial commit in the `gecko-dev/esr115` branch to find the equivalent commit
- [ ] 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_115_18_0esr_BUILD1`
- [ ] 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)
-`$(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=Apps%3A%3AType%3A%3AReleasePreparation) issues (alpha, stable, and legacy).
- [ ] 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:
Manual QA test check-list for major desktop releases. Please copy/paste form into your own comment, fill out relevant info and run through the checklist!
Manual QA test check-list for major android releases. Please copy/paste form into your own comment, fill out relevant info and run through the checklist!