Tor Browser issueshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues2024-03-13T08:08:26Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42448Rebase Tor Browser stable onto Firefox 115.9.0esr2024-03-13T08:08:26ZPier Angelo VendrameRebase Tor Browser stable onto Firefox 115.9.0esr**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...**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**
- [x] 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 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**
- [ ] Find the Firefox mercurial tag here: https://hg.mozilla.org/releases/mozilla-esr102/tags
- **Example**: `FIREFOX_102_8_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/esr102` branch to find the equivalent commit
- **Example**: `3a3a96c9eedd02296d6652dd50314fccbc5c4845`
- [ ] Sign and Tag `gecko-dev` commit
- Sign/Tag `gecko-dev` commit :
- **Tag**: `$(ESR_TAG)`
- **Message**: `Hg tag $(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 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:
- **Tag**: `tor-browser-$(ESR_VERSION)esr-$(BROWSER_MAJOR).$(BROWSER_MINOR)-1-build1`
- **Message**: `Tagging build1 for $(ESR_VERSION)esr-based stable`
- [ ] Push tag to `upstream`
- [ ] Sign/Tag HEAD of the merged `base-browser` branch:
- **Tag**: `base-browser-$(ESR_VERSION)esr-$(BROWSER_MAJOR).$(BROWSER_MINOR)-1-build1`
- **Message**: `Tagging build1 for $(ESR_VERSION)esr-based stable`
- [ ] Push tag to `upstream`Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42446Improve accessible descriptions in built-in dialog2024-03-26T20:42:37ZhenryImprove accessible descriptions in built-in dialogCurrently the "Current bridge" label is present in the aria description for the radio options, even if the label is hidden.
Moreover, the "Current bridge" text is concatenated with the rest of the description, without any punctuation se...Currently the "Current bridge" label is present in the aria description for the radio options, even if the label is hidden.
Moreover, the "Current bridge" text is concatenated with the rest of the description, without any punctuation separation.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42437Drop "torbrowser.version" preference2024-03-26T20:27:58ZhenryDrop "torbrowser.version" preference"torbrowser.version" is defined based on `__BASE_BROWSER_VERSION_QUOTED__`, but is only used in one place: https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/8614325290175a7253f11501d823db65ab805257/browser/components/abou..."torbrowser.version" is defined based on `__BASE_BROWSER_VERSION_QUOTED__`, but is only used in one place: https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/8614325290175a7253f11501d823db65ab805257/browser/components/abouttor/AboutTorMessage.sys.mjs#L30.
But we could just use the existing "browser.startup.homepage_override.torbrowser.version" instead.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42425Improve accessibility of the bridge emoji cells2024-03-04T15:14:34ZhenryImprove accessibility of the bridge emoji cellsWhen testing https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42413 with screen readers I noticed:
+ NVDA does not like to read the table cell accessible name, but will instead read the content of the cell only.
+ Orc...When testing https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42413 with screen readers I noticed:
+ NVDA does not like to read the table cell accessible name, but will instead read the content of the cell only.
+ Orca will not read the `aria-describedby` in a table.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42421Remove bridge option should be hidden for Lox bridges2024-03-04T15:14:03ZhenryRemove bridge option should be hidden for Lox bridgesCurrently we allow individual Lox bridges to be removed through the "Bridge options" menu.Currently we allow individual Lox bridges to be removed through the "Bridge options" menu.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42415Improve focus styling for forced focus in bridge settings2024-02-14T10:21:05ZhenryImprove focus styling for forced focus in bridge settingsAs part of https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036, I set up a few places where we wanted to move focus to the start of an area by calling `.focus` on an element with `tabindex = -1`. This issue is just ...As part of https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036, I set up a few places where we wanted to move focus to the start of an area by calling `.focus` on an element with `tabindex = -1`. This issue is just to tidy up some of the focus styling of these elements for these rare moments where they have `:focus-visible`.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42414Show ellipsis when the tor bridge address overflows2024-02-14T10:20:22ZhenryShow ellipsis when the tor bridge address overflowsCurrently the ellipsis doesn't show, as intended in the mockup: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036/designs/lox-added.pngCurrently the ellipsis doesn't show, as intended in the mockup: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036/designs/lox-added.pnghenryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42390Betterboxing: make the decorator border disappear when the corners are flat2024-02-08T14:48:36Zma1Betterboxing: make the decorator border disappear when the corners are flatReported by @thorin, who provided also the screenshot: the decorator line from #42387, which should usually blend with the letterboxing background, is unpleasantly visible when the window is at letterboxing-rounded size.
Since the decor...Reported by @thorin, who provided also the screenshot: the decorator line from #42387, which should usually blend with the letterboxing background, is unpleasantly visible when the window is at letterboxing-rounded size.
Since the decorator is useful only when the corners are rounded, and we auto-flatten them whenever the letterboxing margin is less than the rounded corners radius, we can hide the decorator as soon as the corner are flattened and bring it back when they're rounded again.
While we're here, per @donuts 's request, we'll remove the thin shadow separating the toolbar from the browser content, originally implemented in https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests/886#note_2984761.
![image](/uploads/d71b4fefac2cce27f0ecb62d18a6b909/image.png)ma1ma1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42389Betterboxing: gradient is never shown2024-02-07T17:58:03ZThorinBetterboxing: gradient is never shownwindows: theme is system auto (and OS is dark) cc: @ma1
![lbgradient](/uploads/91b640d9aa2a359bceb4616b2e1c4acc/lbgradient.png)windows: theme is system auto (and OS is dark) cc: @ma1
![lbgradient](/uploads/91b640d9aa2a359bceb4616b2e1c4acc/lbgradient.png)ma1ma1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42354Refactor exclusions in ShouldSanitizePreference() to the pref list.2024-01-30T10:45:22Zguest475646844Refactor exclusions in ShouldSanitizePreference() to the pref list.This is second issue related to MR !765 which requires uplifting changes to upstream as per Tom's [suggestion](https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests/765#note_2943521 "Draft: Bug 41165: Onion rewrite ...This is second issue related to MR !765 which requires uplifting changes to upstream as per Tom's [suggestion](https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests/765#note_2943521 "Draft: Bug 41165: Onion rewrite static pref causes a crash in debug builds"):
> ```plaintext
> tjr | my suggestion would be to make a new override list, move these prefs
> | (https://searchfox.org/mozilla-central/source/modules/libpref/Preferences.cpp#6137-6143) into it, along with your pref.
> ```
Please refer to original MR for details. I'll update code comments and post it here.
/cc @pierov @tjrguest475646844guest475646844https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42345Identity difference in exposed functions between private-browsing and normal-...2024-01-18T13:09:53ZThorinIdentity difference in exposed functions between private-browsing and normal-browsing, Tor Browser, Mullvad Browser and Firefox ESRSo I whipped up a new toy to scrape function properties - the list of functions come from window properties (nightly) :smile:
- https://arkenfox.github.io/TZP/tests/functionprops.html
- you can select `All` to get a full list - it's very...So I whipped up a new toy to scrape function properties - the list of functions come from window properties (nightly) :smile:
- https://arkenfox.github.io/TZP/tests/functionprops.html
- you can select `All` to get a full list - it's very boring unless you compare to other releases
So I thought I would compare TB13 vs ESR115 (using a PB window) - because we spoke about how some FP protections in the past have been to kill the API/feature and leave a ticket open "to investigate", which isn't necessarily true given the "few" diffs I see here - I say "few" because it's only a handful of decisions, even though it generates a bunch of noise
diffs to followThorinThorinhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42339Backport Android security fixes from Firefox 121 to 115.6 - based Tor Browser2023-12-19T15:37:49Zma1Backport Android security fixes from Firefox 121 to 115.6 - based Tor Browser<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`
- `$(RR_VERSION)`: the Mozilla def...<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`
- `$(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**
- [x] 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).
### **Security Vulnerabilities Report**: https://www.mozilla.org/en-US/security/advisories/
- Potentially Affected Components:
- `firefox`/`geckoview`: https://github.com/mozilla/gecko-dev
- `application-services`: https://github.com/mozilla/application-services
- `android-components` (ESR 102 only): https://github.com/mozilla-mobile/firefox-android
- `fenix` (ESR 102 only): https://github.com/mozilla-mobile/firefox-android
- `firefox-android`: https://github.com/mozilla-mobile/firefox-android
**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/)
- **Example**: https://www.mozilla.org/en-US/security/advisories/mfsa2023-05/#CVE-2023-25740
- 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
- [x] [CVE-2023-6869: Content can paint outside of sandboxed iframe](https://www.mozilla.org/en-US/security/advisories/mfsa2023-56/#CVE-2023-6869)
- [Bug 1799036](https://bugzilla.mozilla.org/show_bug.cgi?id=1799036)
- **Note**: _NO backport_ (sec low, complicate back-out/fix in a [regression](https://bugzilla.mozilla.org/show_bug.cgi?id=1863402) bug story)
- [x] [CVE-2023-6870: Android Toast notifications may obscure fullscreen event notifications](https://www.mozilla.org/en-US/security/advisories/mfsa2023-56/#CVE-2023-6870)
- [Bug 1823316](https://bugzilla.mozilla.org/show_bug.cgi?id=1823316)
- **Note**: Backported (firefox-android!52)
- [x] [CVE-2023-6871: Lack of protocol handler warning in some instances](https://www.mozilla.org/en-US/security/advisories/mfsa2023-56/#CVE-2023-6871)
- [Bug 1828334](https://bugzilla.mozilla.org/show_bug.cgi?id=1828334)
- **Note**: _NO backport_ (unlikely issue for us, mozdevs advised against uplift/backport)
- [x] [CVE-2023-6866: TypedArrays lack sufficient exception handling](https://www.mozilla.org/en-US/security/advisories/mfsa2023-56/#CVE-2023-6866)
- [Bug 1849037](https://bugzilla.mozilla.org/show_bug.cgi?id=1849037)
- **Note**: _NO backport_ (very complex 3 commits patch w/dependencies, they're tracking 115esr for 122+)
- [x] [CVE-2023-6872: Browsing history leaked to syslogs via GNOME](https://www.mozilla.org/en-US/security/advisories/mfsa2023-56/#CVE-2023-6872)
- [Bug 1849186](https://bugzilla.mozilla.org/show_bug.cgi?id=1849186)
- **Note**: _NO backport_ (it's @pierov's uplift we had to disable b/c UX)
- [x] [CVE-2023-6135: NSS susceptible to "Minerva" attack](https://www.mozilla.org/en-US/security/advisories/mfsa2023-56/#CVE-2023-6135)
- [Bug 1853908](https://bugzilla.mozilla.org/show_bug.cgi?id=1853908)
- **Note**: _NO backport_ (3rd party, AFAICT we can't do anything about this, but network latency should save our bacon until Moz does)
- [x] [CVE-2023-6873: Memory safety bugs fixed in Firefox 121](https://www.mozilla.org/en-US/security/advisories/mfsa2023-56/#CVE-2023-6873)
- [Bug 1855327](https://bugzilla.mozilla.org/show_bug.cgi?id=1855327)
- **Note**: _NO backport_ (undisclosed, no commit found)
- [x] [CVE-2023-6873: Memory safety bugs fixed in Firefox 121](https://www.mozilla.org/en-US/security/advisories/mfsa2023-56/#CVE-2023-6873)
- [Bug 1862723](https://bugzilla.mozilla.org/show_bug.cgi?id=1862723)
- **Note**: _NO backport_ (unaffected)
- [x] [CVE-2023-6868: WebPush requests on Firefox for Android did not require VAPID key](https://www.mozilla.org/en-US/security/advisories/mfsa2023-56/#CVE-2023-6868)
- [Bug 1865488](https://bugzilla.mozilla.org/show_bug.cgi?id=1865488)
- **Note**: Backported (firefox-android!52)
- [x] [CVE-2023-6862: Use-after-free in nsDNSService](https://www.mozilla.org/en-US/security/advisories/mfsa2023-54/#CVE-2023-6862)
- [Bug 1868042](https://bugzilla.mozilla.org/show_bug.cgi?id=1868042)
- **Note**: _NO backport_ (fixed in 115.6)
### **tor-browser**: https://gitlab.torproject.org/tpo/applications/tor-browser.git
- [ ] Backport any Android-specific security fixes from Firefox rapid-release
- [ ] Backport patches to `tor-browser` stable branch
- [ ] Open MR
- [ ] Merge
- [ ] Rebase patches onto:
- [ ] `base-browser` stable
- [ ] `tor-browser` alpha
- [ ] `base-browser` alpha
- [ ] Sign/Tag commits:
- **Tag**: `$(PROJECT_NAME)-$(ESR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-$(BUILD_N)`
- **Message**: `Tagging $(BUILD_N) for $(ESR_VERSION)-based stable|alpha)`
- [ ] `base-browser` stable
- [ ] `tor-browser` stable
- [ ] `base-browser` alpha
- [ ] `tor-browser` alpha
- [ ] Push tags to `upstream`
- **OR**
- [x] No backports
### **application-services**: https://gitlab.torproject.org/tpo/applications/application-services
- **NOTE**: we will need to setup a gitlab copy of this repo and update `tor-browser-build` before we can apply security backports here
- [ ] Backport any Android-specific security fixes from Firefox rapid-release
- [ ] Backport patches to `application-services` stable branch
- [ ] Open MR
- [ ] Merge
- [ ] Rebase patches onto `application-services` alpha
- [ ] Sign/Tag commits:
- **Tag**: `application-services-$(ESR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-$(BUILD_N)`
- **Message**: `Tagging $(BUILD_N) for $(ESR_VERSION)-based stable|alpha`
- [ ] `application-services` stable
- [ ] `application-services` alpha
- [ ] Push tags to `upstream`
- **OR**
- [x] No backports
### **android-components (Optional, ESR 102)**: https://gitlab.torproject.org/tpo/applications/android-components.git
- [ ] 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
- [ ] Sign/Tag commits:
- **Tag**: `android-components-$(ESR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-$(BUILD_N)`
- **Message**: `Tagging $(BUILD_N) for $(ESR_VERSION)-based stable|alpha)`
- [ ] `android-components` stable
- [ ] `android-components` alpha
- [ ] Push tags to `upstream`
- **OR**
- [x] No backports
### **fenix (Optional, ESR 102)**: https://gitlab.torproject.org/tpo/applications/fenix.git
- [ ] 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.
- [ ] Backport patches to `fenix` stable branch
- [ ] Open MR
- [ ] Merge
- [ ] Rebase patches onto `fenix` alpha
- [ ] Sign/Tag commits:
- **Tag**: `tor-browser-$(ESR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-$(BUILD_N)`
- **Message**: `Tagging $(BUILD_N) for $(ESR_VERSION)-based stable|alpha)`
- [ ] `fenix` stable
- [ ] `fenix` alpha
- [ ] Push tags to `upstream`
- **OR**
- [ ] No backports
### **firefox-android**: https://gitlab.torproject.org/tpo/applications/firefox-android
- [x] Backport any Android-specific security fixes from Firefox rapid-release
- [x] Backport patches to `firefox-android` stable branch
- [x] Open MR
- [x] Merge
- [x] Rebase patches onto `fenix` alpha
- [x] Sign/Tag commits:
- **Tag**: `firefox-android-$(ESR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-$(BUILD_N)`
- **Message**: `Tagging $(BUILD_N) for $(ESR_VERSION)-based stable|alpha)`
- [x] `firefox-android` stable
- [x] `firefox-android` alpha
- [x] Push tags to `upstream`
- **OR**
- [ ] No backportsma1ma1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42331tb-dev fetch command is missing repository argument2023-12-19T12:32:15Zhenrytb-dev fetch command is missing repository argumentThe `tb-dev` script git fetch commands are missing the upstream repository argument.
Also, we can limit them to just fetch the upstream branch we actually need for the command.The `tb-dev` script git fetch commands are missing the upstream repository argument.
Also, we can limit them to just fetch the upstream branch we actually need for the command.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42308Update README for tor browser2023-12-19T14:25:57ZhenryUpdate README for tor browserAs a first step, we can replace the README.txt file content that comes from mozilla with our own wiki links.
/cc @clairehurst @dan @ma1 @pierov @richardAs a first step, we can replace the README.txt file content that comes from mozilla with our own wiki links.
/cc @clairehurst @dan @ma1 @pierov @richardhenryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42306Tor Browser crashes when extensions popups are opened with Wayland enabled2024-02-06T20:08:48ZCodingThunderTor Browser crashes when extensions popups are opened with Wayland enabled<!--
* Use this issue template for reporting a new bug.
-->
### Summary
**Summarize the bug encountered concisely.**
I have `MOZ_ENABLE_WAYLAND=1` set in my environment in order to hint my FireFox installation to use Wayland. With this ...<!--
* Use this issue template for reporting a new bug.
-->
### Summary
**Summarize the bug encountered concisely.**
I have `MOZ_ENABLE_WAYLAND=1` set in my environment in order to hint my FireFox installation to use Wayland. With this environment variable set, Tor Browser consistently crashes when trying to open NoScript from pinned extensions menu. I haven't tried to reproduce this with other extensions as it can potentially create a unique fingerprint for me.
### Steps to reproduce:
**How one can reproduce the issue - this is very important.**
1. Install Tor Browser from torproject.org/torbrowser-launcher.
2. Launch tor browser with `MOZ_ENABLE_WAYLAND=1` set as environment variable.
3. Pin NoScript to extensions toolbar from Settings
4. Try opening the NoScript extension.
5. The Tor Browser crashes with no feedback to the user about why the crash occured
### What is the current bug behavior?
**What actually happens.**
Tor Browser crashes without any feedback to the end user. This can be frustrating or also lead people into believing that they have been infected with malware/or they have been compromised. I think this behaviour got introduced with the last update a day or two ago, as I remember opening the NoScript extension once without any issues (not sure if I actually did use NoScript before, as my FireFox installation also has NoScript and I have used both browsers side by side so I might have hallucinated)
### What is the expected behavior?
**What you want to see instead**
Tor Browser should not crash with `MOZ_ENABLE_WAYLAND=1` set. I guess this bug is fixed in later versions of Firefox as I have never come across any crash with Wayland on my FireFox setup. I have been forcing FireFox to use Wayland since a long time and use plugins all the time, and also access them. Since Tor Browser is based on ESR, it might be missing the necessary bug fixes for the same.
Additionally, I think Tor Browser should ignore `MOZ_ENABLE_WAYLAND=1` atleast for the time Wayland is not mainstream, as it can lead to fingerprinting based on specific behavior caused by the display protocol in use, especially with JavaScript enabled. I'm not sure how the fingerprinting would work, but surely changing the display protocol would bring about some specific behavior which may be detected by sophisticated JavaScript.
### Environment
**Which operating system are you using? For example: Debian GNU/Linux 10.1, Windows 10, Ubuntu Xenial, FreeBSD 12.2, etc.**
**Which installation method did you use? Distribution package (apt, pkg, homebrew), from source tarball, from Git, etc.**
- Tor Browser installed with torbrowser-launcher/torproject.org from extras repository on Arch Linux with KDE Plasma 5 Wayland session (all packages up to date)
- Tor Browser installed with torbrowser-launcher/torproject.org from extras repository on Arch Linux with GNOME Wayland session (this one's pretty much stock with no modifications at all unlike my Plasma 5 session)
### Relevant logs and/or screenshots
I don't know how to obtain logs for the Tor Browser, even when trying to launch Tor Browser from the terminal, Tor Browser seems to (rightfully) detach itself from the terminal, so I could not obtain logs. And for the screenshots, there is simply no point as no feedback is made available to the user. Screen-recording was an option but I do not want to reveal my Tor Browser and/or my Desktop Environment configma1ma1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42305(Semi-)Automatically merge translation resources across tor browser releases ...2024-03-26T20:31:08Zhenry(Semi-)Automatically merge translation resources across tor browser releases (desktop)/cc @emmapeel @pierov
When I had my time offline the week before last I wrote a script to which takes a `tor-browser` or `firefox-android` translation file (`.dtd`, `.properties`, `.ftl`, or android `.xml`), and a new and an old branch.../cc @emmapeel @pierov
When I had my time offline the week before last I wrote a script to which takes a `tor-browser` or `firefox-android` translation file (`.dtd`, `.properties`, `.ftl`, or android `.xml`), and a new and an old branch name, and merges the versions found in both branches together with a comment added for strings that will be dropped at the next release. Here is the initial draft of the script if you want a quick look: [combine-translation-versions.py](/uploads/83cf1424566cf3b3222e6a60682bcc56/combine-translation-versions.py)
We could use the output as the `en-US` source files for weblate, combining both the strings needed for the next release as well as for the current stable release. The idea being that in tor-browser we can stop trying to maintain all the old strings in the current development branch that are still needed for the current stable release. And we can avoid having to manual clean ups of old strings, like in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42221.
E.g., if we have `tor-browser.ftl` in tor-browser-xxx-13.5 with the content
```
string1 = String 1
new-string = New String
string2 = String 2
```
and in tor-browser-xxx-13.0 with the content
```
old-string = Old String
string1 = String 1
string2 = String 2
```
the script would output
```
string1 = String 1
new-string = New String
string2 = String 2
## Will be unused in Tor Browser 13.5!
old-string = Old String
```
The reason I add the comment is to provide a little notification to weblate translators in the "Source string description" to let them know that a string has a short lifetime. Weblate doesn't support descriptions for `.dtd` though so it won't work for that format.
@emmapeel and @pierov what do you think? And where would we want to run this script?
I guess we basically want to merge the translations files from both the branch used for current nightly and current stable. I'm not sure if this can be automatically pulled from `tor-browser-build` in a convenient way, or whether we would need some manual input.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42303Remove unused "help" button logic in tor dialogs2023-12-19T12:26:19ZhenryRemove unused "help" button logic in tor dialogsThe "help" button for `xul:dialog` was dropped in [bugzilla 1784882](https://bugzilla.mozilla.org/show_bug.cgi?id=1784882), so we can drop our associated logic.The "help" button for `xul:dialog` was dropped in [bugzilla 1784882](https://bugzilla.mozilla.org/show_bug.cgi?id=1784882), so we can drop our associated logic.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42222Fix TorDomainIsolator initialization on Android2023-11-06T20:47:38ZPier Angelo VendrameFix TorDomainIsolator initialization on AndroidIn TBA 13.0aX and 13.0.X (until 13.0.2) the domain isolator is not being initialized incorrectly.
It seems the `TorStartupService` isn't being loaded (even though I'm quite sure it looks like exactly the one we had in Torbutton).
I don...In TBA 13.0aX and 13.0.X (until 13.0.2) the domain isolator is not being initialized incorrectly.
It seems the `TorStartupService` isn't being loaded (even though I'm quite sure it looks like exactly the one we had in Torbutton).
I don't know if it's due to the XPCOM changes that happened between 102 and 115, or if it's just because of the various refactors.
Since we don't have a circuit display, the only way to notice this is going to different sites that show the IP address, and notice that they have the same one, but we'd expect them to be isolated.
Some Tor-friendly ones are:
- https://check.torproject.org/
- https://www.wtfismyip.com/
- https://myip.wtf/ (same as the previous one, but different FP domain for TBB :smile:)
- https://mullvad.net/en/check
When we finally start working on tests we should also have a test that checks circuit FPI.Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42214Fluent migration: security level2024-03-26T20:59:30ZhenryFluent migration: security levelMigrate "securityLevel.properties" to Fluent.Migrate "securityLevel.properties" to Fluent.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42211Fluent migration: new identity2024-03-21T09:57:00ZhenryFluent migration: new identityMigrate "newIdentity.properties" to Fluent.Migrate "newIdentity.properties" to Fluent.henryhenry