commit 8469784d74af0fb4891923cf7d1d4dda90a20a79 parent 6525de06cbc84741c84c55dd9978757fa41069c6 Author: Morgan <morgan@torproject.org> Date: Wed, 2 Apr 2025 18:45:22 +0000 BB 43615: Add Gitlab Issue and Merge Request templates Diffstat:
| A | .gitlab/issue_templates/000 Bug Report.md | | | 131 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| A | .gitlab/issue_templates/010 Proposal.md | | | 70 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| A | .gitlab/issue_templates/020 Web Compatibility.md | | | 112 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| A | .gitlab/issue_templates/030 Test.md | | | 29 | +++++++++++++++++++++++++++++ |
| A | .gitlab/issue_templates/031 Fingerprinting.md | | | 149 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| A | .gitlab/issue_templates/040 Feature.md | | | 32 | ++++++++++++++++++++++++++++++++ |
| A | .gitlab/issue_templates/050 Backport.md | | | 39 | +++++++++++++++++++++++++++++++++++++++ |
| A | .gitlab/issue_templates/060 Rebase - Alpha.md | | | 157 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| A | .gitlab/issue_templates/061 Rebase - Stable.md | | | 120 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| A | .gitlab/issue_templates/063 Rebase - Rapid.md | | | 294 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| A | .gitlab/issue_templates/090 Emergency Security Issue.md | | | 105 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| A | .gitlab/issue_templates/Default.md | | | 20 | ++++++++++++++++++++ |
| A | .gitlab/merge_request_templates/Default.md | | | 92 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
13 files changed, 1350 insertions(+), 0 deletions(-)
diff --git a/.gitlab/issue_templates/000 Bug Report.md b/.gitlab/issue_templates/000 Bug Report.md @@ -0,0 +1,131 @@ +# 🐞 Bug Report +<!-- +Use this template to report problems with the browser which are unrelated to +website functionality (please use the Web Compatibility template for such issues). +The issue's title MUST provide a succinct description of the problem. + +Some good (hypothetical) titles: +- Browser crashes when visiting example.com in Safer mode +- Letterboxing appears even when disabled when using tiling window-manager +- All fonts in browser-chrome have serifs + +Please DO NOT include information about platform in the title, it is redundant +with our labeling system! +--> + +## Reproduction steps +<!-- +Provide specific steps developers can follow to reproduce your issue. +--> + +## Expected behaviour +<!-- +Provide a description of the browser feature or scenario which does not appear +to be working. +--> + +## Actual behaviour +<!-- +Provide a description of what actually occurs. +--> + +## User impact +<!-- +Provide an overview of consequences to users due to this bug. +--> + +## Bookkeeping +<!-- +Please provide the following information: +--> + +- Browser version: +- Browser channel: + - [ ] Release + - [ ] Alpha + - [ ] Nightly +- Distribution method: + - [ ] Installer/archive from torproject.org + - [ ] tor-browser-launcher + - [ ] homebrew + - [ ] other (please specify): +- Operating System: + - [ ] Windows + - Version: + - [ ] macOS + - Version: + - [ ] Linux + - Distribution + Version: + - Desktop Environment + Version: + - [ ] Android + - Version: + - Device: + - [ ] Tails + - [ ] Other (please specify): + +### Browser UI language +<!-- +Found in `about:preferences#general`. +Feel free to omit this if you like, but sometimes bugs can be language specific so having +this info may make it easier for developers to reproduce your problem. +--> + +### Have you modified any of the settings in `about:preferences` or `about:config`? If yes, which ones? +<!-- +If you changed any preference in about:config that aren't exposed in a UI, +could you try to see if you can reproduce without them? Generally speaking, such +changes are unsupported and bugs might be closed as invalid. +--> + +### Do you have any extra extensions installed? +<!-- e.g. Firefox Multi-Account Containers, uBlock Origin, etc --> + +## Troubleshooting +<!-- +This is optional, but it will help to resolve your problem. +--> + +### Does this bug occur in a fresh installation? + +### Is this bug new? If it is a regression, in which version of the browser did this bug first appear? +<!-- +Archived packages for past versions can be found here: +- https://archive.torproject.org/tor-package-archive +--> + +### Does this bug occur in the Alpha release channel? +<!-- +Sometimes bugs are fixed in the Alpha (development) channel but not in the Stable channel. +⚠️ However, the Alpha release channel is the development version and as such may be contain +critical bugs not present in the Stable release channel. Do not test in Alpha if you are an +at risk user unless you really, actually, truly know what you are doing! + +The latest Alpha can be found here: +- https://www.torproject.org/download/alpha/ +--> + +### Does this bug occur in Firefox ESR (Desktop only)? +<!-- +Tor Browser is based on Firefox ESR, so any bugs present in this upstream project will likely +also be present in Tor Browser. +Firefox ESR is available for download here: +- https://www.mozilla.org/en-US/firefox/all/desktop-esr/ +--> + +### Does this bug occur in Firefox Rapid Release? +<!-- +If the issue occurs in Firefox ESR, but does not occur in Firefox Rapid Release, we may be able +to identify and backport the patch which fixes it. + +Firefox Rapid Release is available for download here: +- https://www.mozilla.org/en-US/firefox/new/ + +If the issue has been fixed in Firefox, do you know the Bugzilla issue number associated with the fix? +--> + +<!-- Do not edit beneath this line <3 --> + +--- + +/label ~"Apps::Product::TorBrowser" +/label ~"Apps::Type::Bug" diff --git a/.gitlab/issue_templates/010 Proposal.md b/.gitlab/issue_templates/010 Proposal.md @@ -0,0 +1,70 @@ +# 💡 Proposal +<!-- +Use this template to request a feature or propose some change in the browser. +The issue will likely be edited many times over its life to flesh out the various +questions, so if you don't know the answers to something, jut leave it blank! + +The issue's title MUST provide a succinct description of proposal. + +Some good (hypothetical) titles: +- Remove 'Safer' option from Security Level +- Bundle uBlock Origin by default +- Replace NoScript with faith-based JavaScript sand-boxing +--> + +## User Story +<!-- +Provide a high-level summary of the proposed feature, the problem it solves, and +what it would allow users to do if implemented. --> + +## Security and Privacy Implications +<!-- +How would this proposal interact with our the browser's threat model? +Would this feature negatively affect the browser's security or privacy +guarantees? +--> + +### Security +<!-- +Outline any security implications this feature would introduce. The browser's +security requirements can be found in our threat model document here: +- https://gitlab.torproject.org/tpo/applications/wiki/-/wikis/Design-Documents/Tor-Browser-Design-Doc#21-security-requirements +--> + +### Privacy +<!-- +Outline any privacy implications this feature would introduce. The browser's +privacy requirements can be found in our threat model document here: +- https://gitlab.torproject.org/tpo/applications/wiki/-/wikis/Design-Documents/Tor-Browser-Design-Doc#22-privacy-requirements +--> + +## Accessibility Implications +<!-- +Would this proposal affect or interact with the browser's usability for users +with accessibility needs (e.g. vision or mobility issues). What problems would need +to be solved to ensure these users are not left behind? +--> + +## Other Trade-Offs +<!-- +Beyond the security, privacy and accessibility implications, what other implications +are there for users? +--> + +## Prior Art + +### Does this feature exist in other browsers? +- [ ] Yes + - [ ] Firefox + - [ ] Firefox ESR + - [ ] Other (please specify) +- [ ] No + +### Does this feature exist as an extension? If yes, which one provides this functionality? + +<!-- Do not edit beneath this line <3 --> + +--- + +/label ~"Apps::Product::TorBrowser" +/label ~"Apps::Type::Proposal" diff --git a/.gitlab/issue_templates/020 Web Compatibility.md b/.gitlab/issue_templates/020 Web Compatibility.md @@ -0,0 +1,112 @@ +# 🌍 Web Compatibility +<!-- +Use this template to report websites which do not work properly in the browser. +The issue's title MUST provide a succinct description of the problem. + +Some good (hypothetical) titles: +- Road signs do not render correctly on maps.foo.com +- Infinite CAPTCHA prompts on bar.nat +- Cannot login to baz.org +--> + +## URL +<!-- Provide a link to the website --> + +## Expected behaviour +<!-- +Provide a description of the how the website is supposed to work +--> + +## Actual behaviour +<!-- +Provide a description of what actually occurs +--> + +## Reproduction steps +<!-- +Provide specific steps developers can follow to reproduce your issue +--> + +## Bookkeeping +<!-- +Please provide the following information: +--> + +- Browser version: +- Browser channel: + - [ ] Release + - [ ] Alpha + - [ ] Nightly +- Distribution method: + - [ ] Installer/archive from torproject.org + - [ ] tor-browser-launcher + - [ ] homebrew + - [ ] other (please specify): +- Operating System: + - [ ] Windows + - [ ] macOS + - [ ] Linux + - [ ] Android + - [ ] Tails + - [ ] Other (please specify): +- Operating System Version: + +### Have you modified any of the settings in `about:preferences` or `about:config`? If yes, which ones? +<!-- +If you changed any preference in about:config that aren't exposed in a UI, +could you try to see if you can reproduce without them? Generally speaking, such +changes are unsupported and bugs might be closed as invalid. +--> + +### Do you have any extra extensions installed? +<!-- e.g. Firefox Multi-Account Containers, uBlock Origin, etc --> + +## Troubleshooting +<!-- +This is optional, but it will help to resolve your problem. +--> + +### Does this bug occur in a fresh installation? + +### Is this bug new? If it is a regression, in which version of the browser did this bug first appear? +<!-- +Archived packages for past versions can be found here: +- https://archive.torproject.org/tor-package-archive +--> + +### Does this bug occur in the Alpha release channel? +<!-- +Sometimes bugs are fixed in the Alpha (development) channel but not in the Stable channel. +⚠️ However, the Alpha release channel is the development version and as such may be contain +critical bugs not present in the Stable release channel. Do not test in Alpha if you are an +at risk user unless you really, actually, truly know what you are doing! + +The latest Alpha can be found here: +- https://www.torproject.org/download/alpha/ +--> + +### Does this bug occur in Firefox ESR (Desktop only)? +<!-- +Tor Browser is based on Firefox ESR, so any bugs present in this upstream project will likely +also be present in Tor Browser. +Firefox ESR is available for download here: +- https://www.mozilla.org/en-US/firefox/all/desktop-esr/ +--> + +### Does this bug occur in Firefox Rapid Release? +<!-- +If the issue occurs in Firefox ESR, but does not occur in Firefox Rapid Release, we may be able +to identify and backport the patch which fixes it. + +Firefox Rapid Release is available for download here: +- https://www.mozilla.org/en-US/firefox/new/ + +If the issue has been fixed in Firefox, do you know the Bugzilla issue number associated with the fix? +--> + +<!-- Do not edit beneath this line <3 --> + +--- + +/label ~"Apps::Product::TorBrowser" +/label ~"Apps::Type::WebCompatibility" diff --git a/.gitlab/issue_templates/030 Test.md b/.gitlab/issue_templates/030 Test.md @@ -0,0 +1,29 @@ +# 💣 Test +<!-- +Use this template to track testing of some feature. Please +try to make the title a good one-liner for the changelogs! + +Some good (hypothetical) titles: +- Add test exercising new circuit button +- Add tests for verifying built-in bridge connectivity +- Develop a mock Lox authority for automated testing +--> + +## Description +<!-- +Provide an overview of the technical/implementation aspects of this +test work a developer would need to know +--> + +## Scenarios +<!-- +Provide a list of high-level classes of desired test-cases +and the expected behaviour of each +--> + +<!-- Do not edit beneath this line <3 --> + +--- + +/label ~"Apps::Product::TorBrowser" +/label ~"Apps::Type::Test" diff --git a/.gitlab/issue_templates/031 Fingerprinting.md b/.gitlab/issue_templates/031 Fingerprinting.md @@ -0,0 +1,149 @@ +# 👣 Fingerprinting +<!-- +Use this template to track a browser fingerprinting vector. Such vectors +allow for stateless cross-site tracking (i.e. across somehow collaborating +but otherwise unrelated 1st party domains like foo.com and bar.com) + +For the purposes of developing a fix, this template is meant to define all of the things +we want to think about and analyze before implementing a fix. It's totally fine to leave +parts of this template empty on initial report! The the issue description can be updated +and edited as we learn things. + +This template is also meant to serve as documentation/explanation about how we think +about fingerprinting vectors and minimising their utility. +--> + +## Problem Statement +<!-- +Please give an overview of the problem you think we should address. + e.g. system fonts (`font: caption`) might expose desktop + environment/distribution/language/customization because Firefox uses OS + settings. +--> + +## Documentation +<!-- +Please provide a links to the relevant standards or documentation for the affected web +platform features. Additionally, please provide links to relevant academic research, +upstream Bugzilla issues, etc (if available). +--> + +## Repro Steps +<!-- +Please provide any proof of concept which can help us under how this feature +can be used for fingerprinting and that we can use as a test for our patches. +--> + +## Analysis + +### Metric Distribution +<!-- +- How many different possible buckets of values exist without fingerprinting +mitigations? +- How are users distributed between these buckets? +- Do any group of users stand-out by default? +- Do users in each of these buckets likely have different risk profiles? +--> + +### Metric Stability +<!-- +- How does the metric change during and between browsing sessions without mitigations? + e.g. Window size may be mostly stable during a browsing session + but may change between browsing sessions + e.g. User-Agent string is stable during a browsing session, but may change + between major browser updates +--> + +## Mitigation Strategy +<!-- +Outline (at least) one of the possible mitigation strategies for this metric +(normalisation, randomisation, or disabling) +--> + +### Normalisation +<!-- +Describe a strategy whereby all users report the same value for the metric, or the pros +and cons if there are multiple potential normalisation strategies. + e.g. Standardising reported WebGL constants such as maximum framebuffer size +- After normalisation, would this metric be equivalent another normalised metric? + e.g. fonts are usually equivalent to the OS, which is already exposed. +- Sometimes it is impossible to use the same value for all users, but reducing the + number of user buckets is still a win. + +✅ This is the preferred mitigation strategy. +--> + +### Randomisation +<!-- +Describe a strategy whereby users return randomised metrics + e.g. when enumerating webcams, choose a number of devices from a `[1; 3]` uniform + distribution +- How did you choose this distribution and its parameters? +- What strategies should we use to hide the randomization? + e.g. randomize the value only once per session and per first-party +- Why is it not possible to use a normalized value, instead? Normalization is often + better than randomization because it is often easier to conceal + +A randomised metric should ideally be: +- Different per first party domain + e.g. different websites measure a different value for the metric +- Stable per session per first party domain + e.g. a website repeatedly measuring the metric will get back the same value + during the same browsing session +- Different between sessions, regardless of first party domain + e.g. a website measuring a metric between browsing sessions will get back a different + value + +⚠️ We should only resort to randomisation if providing normalised values completely +and utterly breaks web compatibility, usability, or accessibility. +--> + +### Disabling +<!-- +Describe a strategy whereby the fingerprintable metric is just outright disabled + e.g. Disabling WebAuthN feature entirely +- Why is it not possible to spoof a (normalized) value instead? Disabling an API might + break some sites. + e.g. Rejecting the permission prompt request promise would be preferable to removing + or disabling the relevant APIs +- Is this a temporary change? + e.g. necessary on the ESR version of Firefox we use for Tor Browser, but fixed in a + later version of Firefox. +--> + +## Other Considerations + +### Usability and Accessibility +<!-- +- Would the proposed mitigation make websites unusable for non-technical/human reasons? + e.g. Always requesting language as en-US makes websites usable for non English-reading + users +- Would it make the browser unusable for some users? + e.g. Forcing overlay scrollbars would make websites unusable for some users with motor + issues +- Do we need to provide a user-accessible 'escape-hatch' to allow users to opt-out of the + proposed mitigation? + e.g. Providing an option in about:preferences +--> + +### Web Compatibility +<!-- +Would the proposed mitigation break websites for technical reasons? + e.g. Disabling WebAuthN preventing YubiKey authentication +--> + +### Plausibility +<!-- +Would the proposed mitigation make the browser stand out as a potential bot or scraper or +some other non-standard browser configuration? + e.g. Reporting only 2 CPU-cores is unlikely for modern PCs in the year 2025 +--> + +<!-- Do not edit beneath this line <3 --> + +--- + +/confidential +/label ~"Apps::Product::BaseBrowser" +/label ~"Project 131" +/label ~"Fingerprinting" diff --git a/.gitlab/issue_templates/040 Feature.md b/.gitlab/issue_templates/040 Feature.md @@ -0,0 +1,32 @@ +# ✨ Feature +<!-- +Use this template to track implementation of some feature. Please +try to make the title a good one-liner for the changelogs! + +Some good (hypothetical) titles: +- Bundle AwesomeFont Sans Font +- Implement new user on-boarding UX +- Publish Linux aarch64 alpha builds +--> + +## Description +<!-- +Provide an overview of the technical/implementation aspects of this feature +--> + +## Bookkeeping + +### Proposal +<!-- Add links to associated proposal issues (or delete block) --> +- tor-browser#xxxxx + +### Design +<!-- Add links to associated design issues (or delete block) --> +- tpo/UX/Design#xyz + +<!-- Do not edit beneath this line <3 --> + +--- + +/label ~"Apps::Product::TorBrowser" +/label ~"Apps::Type::Feature" diff --git a/.gitlab/issue_templates/050 Backport.md b/.gitlab/issue_templates/050 Backport.md @@ -0,0 +1,39 @@ +# ⬅️ Backport Patchset +<!-- +This is an issue for tracking back-porting a patch-set (e.g. from Alpha to Stable or from +Mozilla Rapid-Release to Alpha). + +please ensure the title has the following format: + +- Backport tor-browser#12345: Title of original issue +- Backport Bugzilla 1234567: Title of original issue + +--> + +## Bookkeeping + +### Issue(s) +- tor-browser#xxxxx +- mullvad-browser#xyz +- https://bugzilla.mozilla.org/show_bug.cgi?id=xxxxxxx + +### Merge Request(s) +- tor-browser!xxxx + +### Target Channels + +- [ ] Alpha +- [ ] Stable +- [ ] Legacy + +## Notes + +<!-- whatever additional info, context, etc that would be helpful for backporting --> + + +<!-- Do not edit beneath this line <3 --> + +--- + +/label ~"Apps::Product::TorBrowser" +/label ~"Apps::Type::Backport" diff --git a/.gitlab/issue_templates/060 Rebase - Alpha.md b/.gitlab/issue_templates/060 Rebase - Alpha.md @@ -0,0 +1,157 @@ +# ⤵️ Rebase Alpha + +**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=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 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: + - **Branch**: `*-$(ESR_VERSION)esr-$(BROWSER_MAJOR).$(BROWSER_MINOR)-1*` + - **Example**: `*-102.8.0esr-12.5-1*` + - **Allowed to merge**: `Maintainers` + - **Allowed to push and merge**: `Maintainers` + - **Allowed to force push**: `false` + - If you copied and pasted from old rules, double check you didn't add spaces at the end, as GitLab will not trim them! + +### **Create New Branches** + +- [ ] Fetch Mozilla's firefox repo and identify this release's ${ESR_TAG} +- [ ] Create new alpha `base-browser` branch from Firefox ${ESR_TAG} + - Branch name in the form: `base-browser-$(ESR_VERSION)esr-$(BROWSER_MAJOR).$(BROWSER_MINOR)-1` + - **Example**: `base-browser-102.8.0esr-12.5-1` +- [ ] Create new alpha `tor-browser` branch from Firefox mercurial tag + - Branch name in the form: `tor-browser-$(ESR_VERSION)esr-$(BROWSER_MAJOR).$(BROWSER_MINOR)-1` + - **Example**: `tor-browser-102.8.0esr-12.5-1` +- [ ] Push new `base-browser` branch to `upstream` +- [ ] Push new `tor-browser` branch to `upstream` + +### **Rebase tor-browser** + +- [ ] Checkout a new local branch for the `tor-browser` rebase + - **Example**: `git branch tor-browser-rebase FIREFOX_102_8_0esr_BUILD1` +- [ ] **(Optional)** `base-browser` rebase and autosquash + - **NOTE** This step may be skipped if the `HEAD` of the previous `base-browser` branch is a `-buildN` tag + - [ ] Cherry-pick the previous `base-browser` commits up to `base-browser`'s `buildN` tag onto new `base-browser` rebase branch + - **Example**: `git cherry-pick FIREFOX_102_7_0esr_BUILD1..base-browser-102.7.0esr-12.5-1-build1` + - [ ] Rebase and autosquash these cherry-picked commits + - **Example**: `git rebase --autosquash --interactive FIREFOX_102_8_0esr_BUILD1 HEAD` + - [ ] Cherry-pick remainder of patches after the `buildN` tag + - **Example**: `git cherry-pick base-browser-102.7.0esr-12.5-1-build1..upstream/base-browser-102.7.0esr-12.5-1` + +- [ ] `tor-browser` rebase and autosquash + - [ ] Note the current git hash of `HEAD` for `tor-browser` rebase+autosquash step: `git rev-parse HEAD` + - [ ] Cherry-pick the appropriate previous `tor-browser` branch's commit range up to the last `tor-browser` `buildN` tag + - **Example**: `git cherry-pick base-browser-102.7.0esr-12.5-1-build1..tor-browser-102.7.0esr-12.5-1-build1` + - **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` + - **BUILD CONFIGURATION** - tools/scripts, gitlab templates, etc + - **BROWSER CONFIGURATION** - branding, mozconfigs, preference overrides, etc + - **SECURITY PATCHES** - security improvements, hardening, etc + - **PRIVACY PATCHES** - fingerprinting, linkability, proxy bypass, etc + - **FEATURES** - new functionality: updater, UX, letterboxing, security level, add-on + - Relocate new `tor-browser` patches in the patch-set to enforce this rough thematic ordering: + - **BUILD CONFIGURATION** - tools/scripts, gitlab templates, etc + - **BROWSER CONFIGURATION** - branding, mozconfigs, preference overrides, etc + - **UPDATER PATCHES** - updater tweaks, signing keys, etc + - **SECURITY PATCHES** - non tor-dependent security improvements, hardening, etc + - **PRIVACY PATCHES** - non tor-dependent fingerprinting, linkability, proxy bypass, etc + - **FEAURES** - non tor-dependent features + - **TOR INTEGRATION** - legacy tor-launcher/torbutton, tor modules, bootstrapping, etc + - **TOR SECURITY PATCHES** - tor-specific security improvements + - **TOR PRIVACY PATCHES** - tor-specific privacy improvements + - **TOR FEATURES** - new tor-specific functionality: manual, onion-location, onion service client auth, etc + - [ ] Cherry-pick remainder of patches after the last `tor-browser` `buildN` tag + - **Example**: `git cherry-pick tor-browser-102.7.0esr-12.5-1-build1..upstream/tor-browser-102.7.0esr-12.5-1` + - [ ] Rebase and `pick` new security backport patches to the end of the **MOZILLA BACKPORTS** section of the commit history + - **Example**: `git rebase --interactive FIREFOX_102_8_0esr_RELEASE` + - [ ] 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 - + - `git diff $(ESR_TAG_PREV)..$(BROWSER_BRANCH_PREV) > current_patchset.diff` + - `git diff $(ESR_TAG)..$(BROWSER_BRANCH) > rebased_patchset.diff` + - 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) + - [ ] rangediff: `git range-diff $(ESR_TAG_PREV)..$(TOR_BROWSER_BRANCH_PREV) $(ESR_TAG)..HEAD` + - **Example**: `git range-dif FIREFOX_102_7_0esr_BUILD1..upstream/tor-browser-102.7.0esr-12.5-1 FIREFOX_102_8_0esr_BUILD1..HEAD` +- [ ] Open MR for the `tor-browser` rebase +- [ ] Merge +- Update and push `base-browser` branch + - [ ] Reset the new `base-browser` branch to the appropriate commit in this new `tor-browser` branch + - [ ] Push these commits to `upstream` +- [ ] Set `$(TOR_BROWSER_BRANCH)` as the default GitLab branch + - [ ] Go to [Repository Settings](https://gitlab.torproject.org/tpo/applications/tor-browser/-/settings/repository) + - [ ] Expand `Branch defaults` + - [ ] Set the branch and leave the `Auto-close` checkbox unchecked + - [ ] Save changes + +### **Sign and Tag** + +- [ ] Sign/Tag `HEAD` of the merged `tor-browser` branch: + - In **tor-browser.git**, checkout the new alpha `tor-browser` branch + - In **tor-browser-build.git**, run signing script: + ```bash + ./tools/browser/sign-tag.torbrowser alpha build1 + ``` + - [ ] Push tag to `upstream` +- [ ] Sign/Tag HEAD of the merged `base-browser` branch: + - In **tor-browser.git**, checkout the new alpha `base-browser` branch + - In **tor-browser-build.git**, run signing script: + ```bash + ./tools/browser/sign-tag.basebrowser alpha build1 + ``` + - [ ] Push tag to `upstream` +- [ ] Update tor-browser-build's `main` branch (no MR required, you can just push it if you have the permissions) + - [ ] Update `projects/firefox/config` + - [ ] Update `firefox_platform_version` + - [ ] Set `browser_build` to 1 (to prevent failures in alpha testbuilds) + - [ ] Update `projects/geckoview/config` + - [ ] Update `firefox_platform_version` + - [ ] Set `browser_build` to 1 (to prevent failures in alpha testbuilds) + +<!-- Do not edit beneath this line <3 --> + +--- + +/label ~"Apps::Product::TorBrowser" +/label ~"Apps::Type::Rebase" +/label ~"Apps::Impact::High" +/label ~"Priority::Blocker" diff --git a/.gitlab/issue_templates/061 Rebase - Stable.md b/.gitlab/issue_templates/061 Rebase - Stable.md @@ -0,0 +1,120 @@ +# ⤵️ Rebase Stable + +**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.0-1` +- `$(BASE_BROWSER_BRANCH_PREV)`: the full name of the previous `base-browser` branch + - **Example**: `base-browser-102.7.0esr-12.0-1` +- `$(TOR_BROWSER_BRANCH)`: the full name of the current `tor-browser` branch + - **Example**: `tor-browser-102.8.0esr-12.0-1` +- `$(TOR_BROWSER_BRANCH_PREV)`: the full name of the previous `tor-browser` branch + - **Example**: `tor-browser-102.7.0esr-12.0-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 stable `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-$(BROWSER_MAJOR).$(BROWSER_MINOR)-1*` + - **Example**: `*-102.8.0esr-12.0-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** + +- [ ] Fetch Mozilla's firefox repo and identify this release's ${ESR_TAG} +- [ ] Create new stable `base-browser` branch from tag + - Branch name in the form: `base-browser-$(ESR_VERSION)esr-$(BROWSER_MAJOR).$(BROWSER_MINOR)-1` + - **Example**: `base-browser-102.8.0esr-12.0-1` +- [ ] Create new stable `tor-browser` branch from + - Branch name in the form: `tor-browser-$(ESR_VERSION)esr-$(BROWSER_MAJOR).$(BROWSER_MINOR)-1` + - **Example**: `tor-browser-102.8.0esr-12.0-1` +- [ ] Push new `base-browser` branch to `upstream` +- [ ] Push new `tor-browser` branch to `upstream` +- [ ] Push new `$(ESR_TAG)` to `upstream` + +### **Rebase tor-browser** + +- [ ] Checkout a new local branch for the `tor-browser` rebase + - **Example**: `git branch tor-browser-rebase FIREFOX_102_8_0esr_BUILD1` +- [ ] **(Optional)** `base-browser` rebase + - **NOTE** This step may be skipped if the `HEAD` of the previous `base-browser` branch is a `-buildN` tag + - [ ] Cherry-pick the previous `base-browser` commits up to `base-browser`'s `buildN` tag onto new `base-browser` rebase branch + - **Example**: `git cherry-pick FIREFOX_102_7_0esr_BUILD1..base-browser-102.7.0esr-12.0-1-build1` + - [ ] Rebase and autosquash these cherry-picked commits + - **Example**: `git rebase --autosquash --interactive FIREFOX_102_8_0esr_BUILD1 HEAD` + - [ ] Cherry-pick remainder of patches after the `buildN` tag + - **Example**: `git cherry-pick base-browser-102.7.0esr-12.0-1-build1..upstream/base-browser-102.7.0esr-12.0-1` +- [ ] `tor-browser` rebase + - [ ] Note the current git hash of `HEAD` for `tor-browser` rebase+autosquash step: `git rev-parse HEAD` + - [ ] Cherry-pick the appropriate previous `tor-browser` branch's commit range up to the last `tor-browser` `buildN` tag + - **Example**: `git cherry-pick base-browser-102.7.0esr-12.0-1-build1..tor-browser-102.7.0esr-12.0-1-build1` + - **Example (if separate base-browser rebase was skipped)**: `git cherry-pick FIREFOX_102_7_0esr_BUILD1..tor-browser-102.7.0esr-12.0-1-build1` + - [ ] Rebase and autosquash these newly cherry-picked commits: `git rebase --autosquash --interactive $(PREV_HEAD)` + - **Example**: `git rebase --autosquash --interactive FIREFOX_102_8_0esr_RELEASE` + - [ ] Cherry-pick remainder of patches after the last `tor-browser` `buildN` tag + - **Example**: `git cherry-pick tor-browser-102.7.0esr-12.0-1-build1..upstream/tor-browser-102.7.0esr-12.0-1` + - [ ] Rebase and `pick` new security backport patches to the end of the **MOZILLA BACKPORTS** section of the commit history + - **Example**: `git rebase --interactive FIREFOX_102_8_0esr_RELEASE` + - [ ] 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 - + - `git diff $(ESR_TAG_PREV)..$(BROWSER_BRANCH_PREV) > current_patchset.diff` + - `git diff $(ESR_TAG)..$(BROWSER_BRANCH) > rebased_patchset.diff` + - 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) + - [ ] rangediff: `git range-diff $(ESR_TAG_PREV)..$(TOR_BROWSER_BRANCH_PREV) $(ESR_TAG)..HEAD` + - **Example**: `git range-dif FIREFOX_102_7_0esr_BUILD1..upstream/tor-browser-102.7.0esr-12.0-1 FIREFOX_102_8_0esr_BUILD1..HEAD` +- [ ] Open MR for the `tor-browser` rebase +- [ ] Merge +- Update and push `base-browser` branch + - [ ] Reset the new `base-browser` branch to the appropriate commit in this new `tor-browser` branch + - [ ] Push these commits to `upstream` + +### **Sign and Tag** + +- [ ] Sign/Tag `HEAD` of the merged `tor-browser` branch: + - In **tor-browser.git**, checkout the new stable `tor-browser` branch + - In **tor-browser-build.git**, run signing script: + ```bash + ./tools/browser/sign-tag.torbrowser stable build1 + ``` + - [ ] Push tag to `upstream` +- [ ] Sign/Tag HEAD of the merged `base-browser` branch: + - In **tor-browser.git**, checkout the new stable `base-browser` branch + - In **tor-browser-build.git**, run signing script: + ```bash + ./tools/browser/sign-tag.basebrowser stable build1 + ``` + - [ ] Push tag to `upstream` + +<!-- Do not edit beneath this line <3 --> + +--- + +/label ~"Apps::Product::TorBrowser" +/label ~"Apps::Type::Rebase" +/label ~"Apps::Impact::High" +/label ~"Priority::Blocker" diff --git a/.gitlab/issue_templates/063 Rebase - Rapid.md b/.gitlab/issue_templates/063 Rebase - Rapid.md @@ -0,0 +1,294 @@ +# ⤵️ Rebase Rapid + +- **NOTE**: All examples in this template reference the rebase from Firefox 129.0a1 to 130.0a1 +- **TODO**: + - Documentation step for any difficulties or noteworthy things for each rapid rebase + +<details> + <summary>Explanation of Channels</summary> + + There are unfortunately some collisions between how we and Mozilla name our release channels which can make things confusing: + - **Firefox**: + - **Nightly**: \_START and \_END tags, version in the format `$(MAJOR).$(MINOR)a1` + - **Example**: Firefox Nightly 130 was `130.0a1` + - **Note**: Nightly is 2 major versions ahead of the current Release + - **Beta**: tagged each Monday, Wednesday, and Friday until release, version in the format `$(MAJOR).$(MINOR)b$(PATCH)` + - **Example**: the first Firefox Beta 130 was `130.0b1` + - **Note**: Beta is 1 major version ahead of the current Release, should be irrelevant to us + - **Release**: tagged monthly, version in the format `$(MAJOR).$(MINOR)` or `$(MAJOR).$(MINOR).$(PATCH)` + - **Example** Firefox Release 130 was `130.0` + - **ESR**: tagged monthly, version in the format `$(ESR_MAJOR).$(ESR_MINOR).$(ESR_PATCH)esr` + - **Example**: Firefox ESR 128.1 is `128.1.0esr` + - **Tor+Mullvad Browser**: + - **Rapid**: tagged monthly, based on the latest Firefox Nightly + - **Nightly**: not tagged, built nightly from our current Alpha branch's `HEAD` + - **Alpha**: tagged monthly, based on the latest Firefox ESR + - **Stable**: tagged monthly, based on oldest supported Firefox ESR + +</details> + +<details> + <summary>Branching Overview</summary> + + Rebasing Tor Browser Rapid onto the current Firefox Nightly is a bit more confusing/involved than rebasing Tor Browser Alpha or Stable from one minor ESR to the next minor ESR. + + The general process basically involves rebasing the previous Firefox Nightly-based Tor Browser Rapid onto the latest Firefox Nightly, and then cherry-picking all of the commits from the previous Firefox ESR-based Tor Browser Alpha after that channel's `build1` tag. This process presumes that the previous Tor Browser Alpha branch is locked and receiving no more changes. + + This diagram provides a high-level view of the overall code-flow for rebasing/cherry-picking commits from Tor Browser Alpha based on Firefox 128.1.0esr and Tor Browser Rapid based on Firefox 129.0a1 onto Firefox 130.0a1: + + ```mermaid +%%{init: { 'themeVariables': {'git0': '#0072b2', 'gitBranchLabel0': '#fff', 'git1': "#e69f00", 'gitBranchLabel1': '#fff', 'git2': '#009e73', 'gitBranchLabel2': '#fff', 'git3': '#cc79a7', 'gitBranchLabel3': '#fff'}, 'gitGraph': {'mainBranchName': 'tor-browser-128.1.0esr-14.5-1'}} }%% +gitGraph: + branch tor-browser-129.0a1-15.0-2 + branch tor-browser-130.0a1-15.0-1 + branch tor-browser-130.0a1-15.0-2 + + checkout tor-browser-128.1.0esr-14.5-1 + commit id: "FIREFOX_128_1_0esr_BUILD1" + commit id: "base-browser-128.1.0esr-14.5-1-build1" + commit id: "tor-browser-128.1.0esr-14.5-1-build1" + commit id: "tor-browser-128.1.0esr-14.5-1-build2" + + checkout tor-browser-129.0a1-15.0-2 + commit id: "FIREFOX_NIGHTLY_129_END" + %% commit id: "tor-browser-129.0a1-15.0-2-build1" + + checkout tor-browser-130.0a1-15.0-1 + commit id: "FIREFOX_NIGHTLY_130_END" + + checkout tor-browser-130.0a1-15.0-2 + commit id: "FIREFOX_NIGHTLY_130_END " + + checkout tor-browser-130.0a1-15.0-1 + merge tor-browser-129.0a1-15.0-2 + + checkout tor-browser-130.0a1-15.0-2 + merge tor-browser-130.0a1-15.0-1 + + + checkout tor-browser-129.0a1-15.0-2 + commit id: "tor-browser-129.0a1-15.0-2-build1" + + checkout tor-browser-130.0a1-15.0-1 + merge tor-browser-129.0a1-15.0-2 id: "tor-browser-130.0a1-15.0-1-build1" + + checkout tor-browser-130.0a1-15.0-2 + merge tor-browser-130.0a1-15.0-1 + + checkout tor-browser-130.0a1-15.0-1 + merge tor-browser-128.1.0esr-14.5-1 + + checkout tor-browser-130.0a1-15.0-2 + merge tor-browser-130.0a1-15.0-1 + + checkout tor-browser-128.1.0esr-14.5-1 + commit id: "tor-browser-128.1.0esr-14.5-1" + + checkout tor-browser-130.0a1-15.0-1 + merge tor-browser-128.1.0esr-14.5-1 id:"tor-browser-130.0a1-15.0-1-build2" + + checkout tor-browser-130.0a1-15.0-2 + + merge tor-browser-130.0a1-15.0-1 + commit id: "tor-browser-130.0a1-15.0-2-build1" + + ``` + + In this concrete example, the rebaser performs the following steps: + - create new `tor-browser-130.0a1-15.0-1`, and `tor-browser-130.0a1-15.0-2` branches from the `FIREFOX_NIGHTLY_130_END` tag. + - these will be the rebase review branches + - onto `tor-browser-130.0a1-15.0-1`, cherry-pick the range `FIREFOX_NIGHTLY_129_END..tor-browser-129.0a1-15.0-2-build1` (i.e. the Firefox Nightly 129-based Tor Browser Rapid commits) + - this updates the previous Tor Browser Rapid onto Firefox Nightly 130 + - cherry-pick the new alpha patches onto `tor-browser-130.0a1-15.0-1` (i.e. cherry-pick `tor-browser-128.1.0esr-14.5-1-build2..origin/tor-browser-128.1.0esr-14.5-1`) + - onto `tor-browser-130.0a1-15.0-2`, rebase and autosquash the `FIREFOX_NIGHTLY_130_END..tor-browser-130.0a1-15.0-2-build1` commit range + - onto `tor-browser-130.0a1-15.0-2`, cherry-pick the remaining commit range `tor-browser-130.0a1-15.0-2-build1..origin/tor-browser-130.0a1-15.0-2` + - re-order any remaining fixup! commits to be adjacent to their parents (i.e. the same rebase command queue as one would get from `git rebase --autosquash`, but with the `fixup!` commands replaced with `pick!` commands). + - this re-organises the branch in a nicely-bisectable way, and will ensure the rebase+autosquash step for the next release *should* succeed without any additional effort + +</details> + +<details> + <summary>Explanation of Variables</summary> + +- `$(NIGHTLY_VERSION)`: the Mozilla defined nightly version, used in various places for building tor-browser tags, labels, etc + - **Example**: `130.0a1` +- `$(NIGHTLY_TAG)`: the Mozilla defined hg (Mercurial) tag associated with `$(NIGHTLY_VERSION)` + - **Example**: `FIREFOX_NIGHTLY_130_END` +- `$(NIGHTLY_TAG_PREV)`: the Mozilla defined hg (Mercurial) tag associated with the previous nightly version when rebasing (ie, the nightly version we are rebasing from) + - **Example**: `FIREFOX_NIGHTLY_129_END` +- `$(BROWSER_VERSION)`: the browser version which will first be based on the next major ESR version this *Firefox* Nightly series is leading up to + - **Example**: `15` +- `$(TOR_BROWSER_BRANCH)`: the full name of the current `tor-browser` branch based off of the Firefox Nightly channel + - **Example**: `tor-browser-130.0a1-15.0-1` +- `$(TOR_BROWSER_BRANCH_PREV)`: the full name of the previous `tor-browser` branch based off of the Firefox Nightly channel + - **Example**: `tor-browser-129.0a1-15.0-1` +</details> + +### Update Branch Protection Rules + +- [ ] In [Repository Settings](https://gitlab.torproject.org/tpo/applications/tor-browser/-/settings/repository): + - [ ] Remove previous nightly `tor-browser` branch protection rules (this will prevent pushing new changes to the branches being rebased) + - [ ] Create new `tor-browser` branch protection rule: + - **Branch**: `tor-browser-$(NIGHTLY_VERSION)-$(BROWSER_VERSION)-*` + - **Example**: `tor-browser-130.0a1-15.0-*` + - **Allowed to merge**: `Maintainers` + - **Allowed to push and merge**: `Maintainers` + - **Allowed to force push**: `false` + - ⚠️ **IMPORTANT**: If you copied and pasted from old rules, double check you didn't add spaces at the end, as GitLab will not trim them! + +### **Create New Branches** + +- [ ] Fetch Mozilla's firefox repo and identify this release's ${NIGHTLY_TAG} +- [ ] Create two new rapid `tor-browser` branches from Firefox ${NIGHTLY_TAG} + - Branch name in the form: `tor-browser-$(NIGHTLY_VERSION)-$(BROWSER_VERSION)-${BRANCH_NUM}` + - **Example**: `tor-browser-130.0a1-15.0-1` and `tor-browser-130.0a1-15.0-2` +- [ ] Push new `tor-browser` branches and the `firefox` tag to `upstream` + +### **Rebase previous `-2` rapid branch's HEAD onto current `-1` rapid branch** + +- **Desired outcome**: + - An easy to review branch with the previous rapid branch rebased onto the latest Firefox Nighty tag + - It must be possible to run `git range-diff` between the previous `-2` and the new branch + - We want to see only the effects of the rebase + - No autosquash should happen at this point + - **Expected difficulties**: + - Conflicts with upstream developments + - Sometimes it will be hard to keep a feature working. It's fine to drop it, and create an issue to restore it after a deeper investigation. +- [ ] Checkout a new local branch for the first part of the `-1` rebase + - **Example**: `git checkout -b rapid-rebase-part1 origin/tor-browser-130.0a1-15.0-1` +- [ ] Firefox Nightly-based `tor-browser` rebase: + - [ ] cherry-pick previous Tor Browser Rapid `-2` branch to new `-1` rebase branch + - **Example**: `git cherry-pick FIREFOX_NIGHTLY_129_END..origin/tor-browser-129.0a1-15.0-2` +- [ ] Rebase Verification: + - [ ] Clean range-diff between the previous rapid branch and current rebase branch + - **Example**: + ```bash + git range-diff FIREFOX_NIGHTLY_129_END..origin/tor-browser-129.0a1-15.0-2 FIREFOX_NIGHTLY_130_END..rapid-rebase-part1 + ``` + - [ ] Optional: clean diff of diffs between previous rapid branch and current rebase branch + - **Example**: + ```bash + git diff FIREFOX_NIGHTLY_129_END origin/tor-browser-129.0a1-15.0-2 > 129.diff + git diff FIREFOX_NIGHTLY_130_END HEAD > 130.diff + # A two-column diff tool is suggested rather than plain-diff, e.g., meld on Linux. + meld 129.diff 130.diff + ``` + - **Note**: Only differences should be due to resolving merge conflicts with upstream changes from Firefox Nightly +- [ ] Open MR +- [ ] Merge +- [ ] Sign/Tag `HEAD` of the merged `tor-browser` branch: + - In **tor-browser.git**, checkout the `-1` rapid `tor-browser` branch + - In **tor-browser-build.git**, run signing script: + ```bash + ./tools/browser/sign-tag.torbrowser rapid build1 + ``` + - [ ] Push tag to `upstream` + +### **Port new alpha patches to `-1`** + +- **Desired outcome**: + - The previous release-cycle's new alpha patches cherry-picked to the end of the current nightly + - It must be possible to run `git range-diff ESR-build1..ESR NIGHTLY-build1..` + - **Expected difficulties**: + - Conflicts with upstream developments (similar to the previous part) + - The range might contain cherry-picked upstream commits, which will result in empty commits: it's fine to skip them + - **Note**: The Tor Browser Alpha branch should be closed at this point and not receiving any more MRs +- [ ] Checkout a new local branch for the second part of the `-1` rebase + - **Example**: `git checkout -b rapid-rebase-part2 origin/tor-browser-130.0a1-15.0-1` +- [ ] Cherry-pick the new `tor-browser` alpha commits (i.e. the new dangling commits which did not appear in the previous Tor Browser Alpha release): + - **Example** `git cherry-pick tor-browser-128.1.0esr-14.5-1-build1..origin/tor-browser-128.1.0esr-14.5-1` +- [ ] Rebase Verification + - [ ] Clean range-diff between the alpha patch set ranges + - **Example**: + ```bash + git range-diff tor-browser-128.1.0esr-14.5-1-build1..origin/tor-browser-128.1.0esr-14.5-1 origin/tor-browser-130.0a1-15.0-1..HEAD + ``` + - [ ] Clean diff of diffs between the alpha patch set ranges + - **Example**: + ```bash + git diff tor-browser-128.1.0esr-14.5-1-build1 origin/tor-browser-128.1.0esr-14.5-1 > 128.1.0esr.diff + git diff origin/tor-browser-130.0a1-15.0-1 HEAD > 130.diff + # A two-column diff tool is suggested rather than plain-diff, e.g., meld on Linux. + meld 128.1.0esr.diff 130.diff + ``` + - **Note**: Only differences should be due to resolving merge conflicts with upstream changes from Firefox Nightly +- [ ] Open MR +- [ ] Merge +- [ ] Sign/Tag `HEAD` of the merged `tor-browser` branch: + - In **tor-browser.git**, checkout the `-1` rapid `tor-browser` branch + - In **tor-browser-build.git**, run signing script: + ```bash + ./tools/browser/sign-tag.torbrowser rapid build2 + ``` + - [ ] Push tag to `upstream` + +### **Squash and Reorder tor-browser `-1` branch to new `-2` branch** +- **Desired outcome**: + - The rapid branch from the previous step prepared for the next nightly + - **Rationale**: + - We squash a lot of commits. We want to keep them a little bit longer rather than squashing them immediately for troubleshooting and documentation purposes. + - Doing this as a separate pass helps to separate errors due to upstream changes from errors due to processes created by our workflow. + - **Expected difficulties**: + - our patches aren't disjoint, therefore we might have conflicts when shuffling them around. +- [ ] Checkout a new local branch for the `-2` rebase, aligned to -1-build1 + - **Example**: `git checkout -b rapid-rebase-part3 tor-browser-130.0a1-15.0-1-build1` +- [ ] Rebase with autosquash. This step should be trivial and not involve any conflicts. + - **Example**: `git rebase -i --autosquash FIREFOX_NIGHTLY_130_END` +- [ ] Cherry-pick the remaining commits + - **Example**: `git cherry-pick tor-browser-130.0a1-15.0-1-build1..upstream/tor-browser-130.0a1-15.0-1` +- [ ] Create a branch for self-reviewing purposes, or take note of the current commit hash somewhere + - **Example**: `git branch rapid-rebase-part3-review` + - You do not need to publish this, and you can delete it at the end of the process (`git branch -D rapid-rebase-part3-review`) + - When you are a reviewer, it might be useful to repeat these steps locally. They should not involve mental overhead (and PieroV has a script to automate this) +- [ ] Rebase and reorder commits (i.e. replace `fixup `, `fixup -C ` and `squash ` with `pick ` commands) + - Notice the space at the end, to avoid replacing `fixup!` with `pick!` in the commit subject, even though git will probably not care of such changes +- [ ] Rebase Verification + - [ ] Clean range-diff between the temporary review branch and the final branch + - **Example**: + ```bash + git range-diff FIREFOX_NIGHTLY_130_END..rapid-rebase-part3-review FIREFOX_NIGHTLY_130_END..rapid-rebase-part3 + ``` + - If you are the reviewer, it should be trivial to create such a branch on your own, as no shuffling is involved + - [ ] Clean diff of diffs between rapid branches + - **Example**: + ```bash + git diff FIREFOX_NIGHTLY_130_END tor-browser-130.0a1-15.0-1-build2 > 130-1.diff + git diff FIREFOX_NIGHTLY_130_END HEAD > 130-2.diff + ``` + - [ ] Understandable range-diff (i.e. `fixup!` patches are distributed from end of branch next to their parent) + - **Example**: + ```bash + git range-diff FIREFOX_NIGHTLY_130_END..tor-browser-130.0a1-15.0-1-build2 FIREFOX_NIGHTLY_130_END..HEAD + ``` +- [ ] Open MR +- [ ] Merge +- [ ] Sign/Tag `HEAD` of the merged `tor-browser` branch: + - In **tor-browser.git**, checkout the `-2` rapid `tor-browser` branch + - In **tor-browser-build.git**, run signing script: + ```bash + ./tools/browser/sign-tag.torbrowser rapid build1 + ``` + - [ ] Push tag to `upstream` + +### **Create and Tag base-browser `-2` branch** +- [ ] Find the last commit in the merged `-2` `tor-browser` branch with a `BB XXXXX...` subject +- [ ] Create new branch from this commit + - Branch name in the form: `base-browser-$(NIGHTLY_VERSION)-$(BROWSER_VERSION)-2` + - **Example**: `base-browser-130.0a1-15.0-2` +- [ ] Push branch to `upstream` +- [ ] Sign/Tag latest `HEAD` of the merged `base-browser` branch: + - In **tor-browser.git**, checkout the `-2` rapid `tor-browser` branch + - In **tor-browser-build.git**, run signing script: + ```bash + ./tools/browser/sign-tag.basebrowser rapid build1 ${COMMIT} + ``` + - [ ] Push tag to `upstream` + +<!-- Do not edit beneath this line <3 --> + +--- + +/label ~"Apps::Product::TorBrowser" +/label ~"Apps::Type::Rebase" +/label ~"Apps::Impact::High" +/label ~"Priority::High" diff --git a/.gitlab/issue_templates/090 Emergency Security Issue.md b/.gitlab/issue_templates/090 Emergency Security Issue.md @@ -0,0 +1,105 @@ +# 🚨 Emergency Security Issue + +**NOTE** This is an issue template to standardise our process for responding to and fixing critical security and privacy vulnerabilities, exploits, etc. + +## Information + +### Related Issue +- tor-browser#AAAAA +- mullvad-browser#BBBBB +- tor-browser-build#CCCCC + +#### Affected Platforms + +- [ ] Android +- [ ] Desktop + - [ ] Windows + - [ ] macOS + - [ ] Linux + +### Type of Issue: What are we dealing with? + +- [ ] Security (sandbox escape, remote code execution, etc) +- [ ] Proxy Bypass (traffic contents becoming MITM'able) +- [ ] De-Anonymization (otherwise identifying which website a user is visiting) +- [ ] Cross-Site Linkability (correlating sessions across circuits and websites) +- [ ] Disk Leak (persisting session information to disk) +- [ ] Other (please explain) + +### Involvement: Who needs to be consulted and or involved to fix this? + +- [ ] Applications Developers + - [ ] **boklm** : build, packaging, signing, release + - [ ] **clairehurst** : Android, macOS + - [ ] **dan** : Android, macOS + - [ ] **henry** : accessibility, frontend, localisation + - [ ] **jwilde** : windows, firefox internals + - [ ] **ma1** : firefox internals + - [ ] **pierov** : updater, fonts, localisation, general + - [ ] **morgan** : signing, release + - [ ] **thorin** : fingerprinting +- [ ] Other Engineering Teams + - [ ] Networking (**ahf**, **dgoulet**) + - [ ] Anti-Censorship (**meskio**, **cohosh**) + - [ ] UX (**donuts**) + - [ ] TPA (**anarcat**, **lavamind**) +- [ ] External Tor Partners + - [ ] Mozilla + - [ ] Mullvad + - [ ] Brave + - [ ] Guardian Project (Orbot, Onion Browser) + - [ ] Tails + - [ ] Other (please list) + +### Urgency: When do we need to act? + +- [ ] **ASAP** :rotating_light: Emergency release :rotating_light: +- [ ] Next scheduled stable +- [ ] Next scheduled alpha, then backport to stable +- [ ] Next major release +- [ ] Other (please explain) + +#### Justification + +<!-- Provide some paragraph here justifying the logic behind our estimated urgency --> + +### Side-Effects: Who will be affected by a fix for this? +Sometimes fixes have side-effects: users lose their data, roadmaps need to be adjusted, services have to be upgraded, etc. Please enumerate the known downstream consequences a fix to this issue will likely incur. +- [ ] End-Users (please list) +- [ ] Internal Partners (please list) +- [ ] External Partners (please list) + +## Todo: + +### Communications + +- [ ] Start an initial email thread with the following people: + - [ ] **bella** + - [ ] Relevant Applications Developers + - [ ] **(Optional)** **micah** + - if there are considerations or asks outside the Applications Team + - [ ] **(Optional)** Other Team Leads + - if there are considerations or asks outside the Applications Team + - [ ] **(Optional)** **gazebook** + - if there are consequences to the organisation or partners beyond a browser update, then a communication plan may be needed + - [ ] **(Optional)** **ruihildt** + - if there are consequences to Mullvad and/or Mullvad Browser + +Godspeed! :pray: + +<!-- Do not edit beneath this line <3 --> + +--- + +/cc @bella +/cc @ma1 +/cc @micah +/cc @morgan + +/confidential + +/label ~"Apps::Product::TorBrowser" +/label ~"Apps::Product::MullvadBrowser" +/label ~"Apps::Type::Bug" +/label ~"Priority::Blocker" +/label ~"Emergency" diff --git a/.gitlab/issue_templates/Default.md b/.gitlab/issue_templates/Default.md @@ -0,0 +1,20 @@ +# Open a new Issue + +Please select the appropriate issue template from the **Description** drop-down. + +--- + +- 🐞 **Bug Report** - report a problem with the browser +- 💡 **Proposal** - suggest a new feature +- 🌐 **Web Compatibility** - report a broken website + +*NOTE*: the following issue types are intended for internal use + +- 💣 **Test** - develop a test or update testing infrastructure +- 👣 **Fingerprinting** - open a fingerprinting issue +- ✨ **Feature** - implement new features +- ⬅️ **Backport** - cherry-pick change to other release channels +- ⤵️ **Rebase - Alpha** - rebase alpha to latest Firefox ESR version +- ⤵️ **Rebase - Stable** - rebase stable to latest Firefox ESR version +- ⤵️ **Rebase - Rapid** - rebase rapid to latest Firefox Nightly version +- 🚨 **Emergency Security Issue** - manage fixing and publishing a critical security fix diff --git a/.gitlab/merge_request_templates/Default.md b/.gitlab/merge_request_templates/Default.md @@ -0,0 +1,92 @@ +## Merge Info + +<!-- Bookkeeping information for release management --> + +### Issues + +#### Resolves +- tor-browser#xxxxx +- mullvad-browser#xxxxx +- tor-browser-build#xxxxx + +#### Related + +- tor-browser#xxxxx +- mullvad-browser#xxxxx +- tor-browser-build#xxxxx + +### Merging + +<!-- This block tells the merger where commits need to be merged and future code archaeologists where commits were *supposed* to be merged --> + +#### Target Branches + +- [ ] **`tor-browser`** - `!fixups` to `tor-browser`-specific commits, new features, security backports +- [ ] **`base-browser`** *and* **`mullvad-browser`** - `!fixups` to `base-browser`-specific commits, new features to be shared with `mullvad-browser`, and security backports + - ⚠️ **IMPORTANT**: Please list the `base-browser`-specific commits which need to be cherry-picked to the `base-browser` and `mullvad-browser` branches here + +#### Target Channels + +- [ ] **Alpha**: rapid release, 16.0 +- [ ] **Stable**: esr140-15.0 +- [ ] **Legacy**: esr115-13.5 + +### Backporting + +#### Timeline +- [ ] **No Backport (preferred)**: patchset for the next major stable +- [ ] **Immediate**: patchset needed as soon as possible (fixes CVEs, 0-days, etc) +- [ ] **Next Minor Stable Release**: patchset that needs to be verified in nightly before backport +- [ ] **Eventually**: patchset that needs to be verified in alpha before backport + +#### (Optional) Justification +- [ ] **Security update**: patchset contains a security fix (be sure to select the correct item in _Timeline_) +- [ ] **Censorship event**: patchset enables censorship circumvention +- [ ] **Critical bug-fix**: patchset fixes a bug in core-functionality +- [ ] **Consistency**: patchset which would make development easier if it were in both the alpha and release branches; developer tools, build system changes, etc +- [ ] **Sponsor required**: patchset required for sponsor +- [ ] **Localization**: typos and other localization changes that should be also in the release branch +- [ ] **Other**: please explain + +### Upstream +- [ ] Patchset is a candidate for uplift to Firefox +- [ ] Patchset is a backport from Firefox + - Bugzilla link: + - Upstream commit: + +### Issue Tracking +- [ ] Link resolved issues with appropriate [Release Prep issue](https://gitlab.torproject.org/groups/tpo/applications/-/issues/?sort=updated_desc&state=opened&label_name%5B%5D=Apps%3A%3AType%3A%3AReleasePreparation&first_page_size=100) for changelog generation + +### Review + +#### Request Reviewer + +- [ ] Request review from an applications developer depending on modified system: + - **NOTE**: if the MR modifies multiple areas, please `/request_review` all the relevant reviewers + - **accessibility** : henry + - **android** : clairehurst, dan + - **build system** : boklm + - **ci/cd**: brizental, henry + - **extensions** : ma1 + - **firefox internals (XUL/JS/XPCOM)** : jwilde, ma1 + - **fonts** : pierov + - **frontend (implementation)** : henry + - **frontend (review)** : donuts, morgan + - **localization** : henry, pierov + - **macOS** : clairehurst, dan + - **nightly builds** : boklm + - **rebases/release-prep** : brizental, clairehurst, dan, ma1, pierov, morgan + - **security** : jwilde, ma1 + - **signing** : boklm, morgan + - **updater** : pierov + - **windows** : jwilde, morgan + - **misc/other** : pierov, morgan + +#### Change Description + +<!-- Whatever context the reviewer needs to effectively review the patchset; if the patch includes UX updates be sure to include screenshots/video of how any new behaviour --> + + +#### How Tested + +<!-- Description of steps taken to verify the change -->