The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-11-23T11:06:30Zhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40680Prepare stable release 11.5.82022-11-23T11:06:30ZrichardPrepare stable release 11.5.8<details>
<summary>Explanation of variables</summary>
- `$(BUILD_SERVER)` : the server the main builder is using to build a tor-browser release
- `$(STAGING_SERVER)` : the server the signer is using to to run the signing process
- `$(...<details>
<summary>Explanation of variables</summary>
- `$(BUILD_SERVER)` : the server the main builder is using to build a tor-browser release
- `$(STAGING_SERVER)` : the server the signer is using to to run the signing process
- `$(TOR_LAUNCHER_VERSION)` : version of `tor-launcher`, used in tags
- example : `0.2.33`
- `$(ESR_VERSION)` : the Mozilla defined ESR version, used in various places for building tor-browser tags, labels, etc
- example : `91.6.0`
- `$(ESR_TAG)` : the Mozilla defined hg (Mercurial) tag associated with `$(ESR_VERSION)`
- exmaple : `FIREFOX_91_7_0esr_BUILD2`
- `$(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)
- `$(RR_VERSION)` : the Mozilla defined 'Rapid Relese' version, used in various places for building geckoview tags, labels, etc
- example : `96.0.3`
- `$(RR_TAG)` : the Mozilla defined hg (Mercurial) tag associated with `$(ESR_VERSION)`
- exmaple : `FIREFOX_96_0_3_RELEASE`
- `$(RR_TAG_PREV)` : the Mozilla defined hg (Mercurial) tag associated with the previous ESR version when rebasing (ie, the ESR version we are rebasing from)
- `$(TOR_BROWSER_MAJOR)` : the Tor Browser major version
- example : `11`
- `$(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; this is separate from the `$(TOR_BROWSER_BUILD_N)` value; 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`
- `$(TOR_BROWSER_BUILD_N)` : the tor-browser build revision for a given Tor Browser release; used in tagging git commits
- example : `build2`
- **NOTE** : A project's `$(BUILD_N)` and `$(TOR_BROWSER_BUILD_N)` may be the same, but it is possible for them to diverge. For example :
- if we have multiple Tor Browser releases on a given ESR branch the two will become out of sync as the `$(BUILD_N)` value will increase, while the `$(TOR_BROWSER_BUILD_N)` value may stay at `build1` (but the `$(TOR_BROWSER_VERSION)` will increase)
- if we have build failures unrelated to `tor-browser`, the `$(TOR_BROWSER_BUILD_N)` value will increase while the `$(BUILD_N)` will stay the same.
- `$(TOR_BROWSER_VERSION)` : the published Tor Browser version
- example : `11.5a6`, `11.0.7`
- `$(TOR_BROWSER_BRANCH)` : the full name of tor-browser branch
- typically of the form: `tor-browser-$(ESR_VERSION)esr-$(TOR_BROWSER_MAJOR).$(TOR-BROWSER_MINOR)-1`
- `$(TOR_BROWSER_BRANCH_PREV)` : the full name of the previous tor-browser branch (when rebasing)
- `$(GECKOVIEW_BRANCH)` : the full name of geckoview branch
- typically of the form: `tor-browser-$(RR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR-BROWSER_MINOR)-1`
- `$(GECKOVIEW_BRANCH_PREV)` : the full name of the previous geckoview branch (when rebasing)
</details>
<details>
<summary>Desktop</summary>
### **torbutton** ***(Optional)***: https://gitlab.torproject.org/tpo/applications/torbutton.git
- [x] ***(Optional)*** Update translations :
- **NOTE** We only update strings in stable if a backported feature depends on new strings
- [x] `./import-translations.sh`
- **NOTE** : if there are no new strings imported then we are done here
- [x] Commit with message `Translation updates`
- **NOTE** : only add files which are already being tracked
- [x] fixup! `tor-browser`'s `Bug 10760 : Integrate TorButton to TorBrowser core` issue to point to updated `torbutton` commit
### **tor-launcher** ***(Optional)***: https://gitlab.torproject.org/tpo/applications/tor-launcher.git
- [x] ***(Optional)*** Update translations:
- **NOTE** We only update strings in stable if a backported feature depends on new strings
- [x] ./localization/import-translations.sh
- [x] Commit with message `Translation updates`
- [x] Update `install.rdf` file with new version
- [x] Sign/Tag commit :
- Tag : `$(TOR_LAUNCHER_VERSION)`
- Message `Tagging $(TOR_LAUNCHER_VERSION)`
- [x] Push `main` and tag to origin
### tor-browser: https://gitlab.torproject.org/tpo/applications/tor-browser.git
- [ ] ***(Optional)*** Rebase to `$(ESR_VERSION)`
- [ ] Find the Firefox hg tag here : https://hg.mozilla.org/releases/mozilla-esr91/tags
- [ ] `$(ESR_TAG)` : `<INSERT_TAG_HERE>`
- [ ] Identify the hg patch associated with above hg tag, and find the equivalent `gecko-dev` git commit (search by commit message)
- [ ] `gecko-dev` commit : `<INSERT_COMMIT_HASH_HERE>`
- [ ] Create new `tor-browser` branch with the discovered `gecko-dev` commit as `HEAD` named `tor-browser-$(ESR_VERSION)esr-$(TOR_BROWSER_MAJOR).$(TOR-BROWSER_MINOR)-1`
- [ ] Sign/Tag commit :
- Tag : `$(ESR_TAG)`
- Message : `Hg tag $(ESR_TAG)`
- [ ] Push new branch and tag to origin
- [ ] Rebase `tor-browser` patches
- [ ] Compare patch-sets (ensure nothing *weird* happened during rebase):
- [ ] rangediff: `git range-diff $(ESR_TAG_PREV)..$(TOR_BROWSER_BRANCH_PREV) $(ESR_TAG)..$(TOR_BROWSER_BRANCH)`
- [ ] diff of diffs:
- Do the diff between `current_patchset.diff` and `rebased_patchset.diff` with your preferred `$(DIFF_TOOL)` and look at differences on lines that starts with + or -
- [ ] `git diff $(ESR_TAG_PREV)..$(TOR_BROWSER_BRANCH_PREV) > current_patchset.diff`
- [ ] `git diff $(ESR_TAG)..$(TOR_BROWSER_BRANCH) > rebased_patchset.diff`
- [ ] `$(DIFF_TOOL) current_patchset.dif rebased_patchset.deff`
- [ ] Open MR for the rebase
- [x] ***(Optional)*** Backport any required Alpha patches to Stable
- [x] cherry-pick patches on top of rebased branch (issues to backport should have `Backport` label and be linked to the associated `Release Prep` issue)
- [x] Close associated `Backport` issues
- [x] Open MR for the backport commits
- [x] Sign/Tag `tor-browser` commit :
- Tag : `tor-browser-$(ESR_VERSION)esr-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-$(FIREFOX_BUILD_N)`
- Message : `Tagging $(FIREFOX_BUILD_N) for $(ESR_VERSION)esr-based (alpha|stable)`
- [x] Push tag to `origin`
</details>
<details>
<summary>Android</summary>
### **geckoview**: https://gitlab.torproject.org/tpo/applications/tor-browser.git
- [x] ***(Optional)*** Rebase to `$(RR_VERSION)`
- [x] Find the Firefox hg tag here : https://hg.mozilla.org/releases/mozilla-release/tags
- [x] `$(RR_TAG)` : `<INSERT_TAG_HERE>`
- [x] Identify the hg patch associated with above hg tag, and find the equivalent `gecko-dev` git commit (search by commit message)
- [x] `gecko-dev` commit : `<INSERT_COMMIT_HASH_HERE>`
- [x] Create new `geckoview` branch with the discovered `gecko-dev` commit as `HEAD` named `geckoview-$(RR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR-BROWSER_MINOR)-1`
- [x] Sign/Tag commit :
- Tag : `$(RR_TAG)`
- Message : `Hg tag $(RR_TAG)`
- [x] Push new branch and tag to origin
- [x] Rebase `geckoview` patches
- [x] Compare patch-sets (ensure nothing *weird* happened during rebase):
- [ ] rangediff: `git range-diff $(RR_TAG_PREV)..$(GECKOVIEW_BRANCH_PREV) $(RR_TAG)..$(GECKOVIEW_BRANCH)`
- [ ] diff of diffs:
- Do the diff between `current_patchset.diff` and `rebased_patchset.diff` with your preferred `$(DIFF_TOOL)` and look at differences on lines that starts with + or -
- [ ] `git diff $(RR_TAG_PREV)..$(GECKOVIEW_BRANCH_PREV) > current_patchset.diff`
- [ ] `git diff $(RR_TAG)..$(GECKOVIEW_BRANCH) > rebased_patchset.diff`
- [ ] `$(DIFF_TOOL) current_patchset.dif rebased_patchset.deff`
- [x] Open MR for the rebase
- [ ] ***(Optional)*** Backport any required patches to Stable
- [ ] cherry-pick patches on top of rebased branch (issues to backport should have `Backport` label and be linked to the associated `Release Prep` issue)
- [ ] Close associated `Backport` issues
- [ ] Open MR for the backport commits
- [ ] Merge + Push
- [x] Sign/Tag `geckoview` commit :
- Tag : `geckoview-$(RR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-$(FIREFOX_BUILD_N)`
- Message : `Tagging $(FIREFOX_BUILD_N) for $(RR_VERSION)-based (alpha|stable)`
- [x] Push tag to `origin`
### **tba-translation** ***(Optional)***: https://gitlab.torproject.org/tpo/translation.git
- **NOTE** We only update strings in stable if a backported feature depends on new strings
- [ ] Fetch latest and identify new `HEAD` of `fenix-torbrowserstringsxml` branch
- [ ] `origin/fenix-torbrowserstringsxml` : `<INSERT COMMIT HASH HERE>`
### **tor-android-service** ***(Optional)***: https://gitlab.torproject.org/tpo/applications/tor-android-service.git
- [ ] Fetch latest and identify new `HEAD` of `main` branch
- [ ] `origin/main` : `<INSERT COMMIT HASH HERE>`
### **application-services** : *TODO: we need to setup a gitlab copy of this repo that we can apply security backports to*
- [ ] ***(Optional)*** Backport any Android-specific security fixes from Firefox rapid-release
- [x] Sign/Tag commit:
- Tag : `application-services-$(ESR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-$(BUILD_N)`
- Message: `Tagging $(BUILD_N) for $(ESR_VERSION)-based (alpha|stable)`
- [ ] Push tag to `origin`
### **android-components** ***(Optional)***: https://gitlab.torproject.org/tpo/applications/android-components.git
- [ ] ***(Optional)*** Rebase to `$(RR_VERSION)`
- [ ] Identify the `mozilla-mobile` git tag to start from by first updating `fenix` and then checking which `android-components` tag is used in `buildSrc/src/main/java/AndroidComponents.kt`
- Alternatively search for commit message like `Update Android-Components`
- [ ] Create new branch from tag named `android-components-$(RR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1`
- [ ] Push new branch to origin
- [ ] Rebase `android-components` patches
- [ ] Perform rangediff to ensure nothing weird happened resolving conflicts
- [ ] Open MR for the rebase
- [ ] Merge + Push
- [x] ***(Optional)*** Backport any required patches to Stable
- [x] cherry-pick patches on top of rebased branch (issues to backport should have `Backport` label and be linked to the associated `Release Prep` issue)
- [x] Close associated `Backport` issues
- [x] Open MR for the backport commits
- [x] Merge + Push
[ ] Sign/Tag commit:
- Tag : `android-components-$(RR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-$(BUILD_N)`
- Message: `Tagging $(BUILD_N) for $(RR_VERSION)-based (alpha|stable)`
- [x] Push tag to origin
### **fenix** ***(Optional)***: https://gitlab.torproject.org/tpo/applications/fenix.git
- [ ] ***(Optional)*** Rebase to `$(RR_VERSION)`
- Upstream git repo : https://github.com/mozilla-mobile/fenix.git
- [ ] Identify the `mozilla-mobile` git tag to start from
- Seem to be in the form `v$(RR_VERSION)` (for example, `v96.3.0`)
- [ ] Create new branch from tag named `tor-browser-$(RR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1`
- **NOTE** : it is weird but we do use `tor-browser` here rather than `fenix`
- [ ] Push new branch to origin
- [ ] Rebase `fenix` patches
- [ ] Perform rangediff to ensure nothing weird happened resolving conflicts
- [ ] Open MR for the rebase
- [ ] Merge + Push
- [ ] ***(Optional)*** Backport any required patches to Stable
- [ ] cherry-pick patches on top of rebased branch (issues to backport should have `Backport` label and be linked to the associated `Release Prep` issue)
- [ ] Close associated `Backport` issues
- [ ] Open MR for the backport commits
- [ ] Merge + Push
- [ ] Sign/Tag commit:
- Tag : `tor-browser-$(RR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-$(BUILD_N)`
- Message: `Tagging $(BUILD_N) for $(RR_VERSION)-based (alpha|stable)`
- [ ] Push tag to origin
</details>
<details>
<summary>Build/Signing/Publishing</summary>
### tor-browser-build: https://gitlab.torproject.org/tpo/applications/tor-browser-build.git
Tor Browser Alpha (and Nightly) are on the `main` branch, while Stable lives in the various `$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-maint` (and possibly more specific) branches
- [x] Update `rbm.conf`
- [x] `var/torbrowser_version` : update to next version
- [x] `var/torbrowser_build` : update to `$(TOR_BROWSER_BUILD_N)`
- [x] ***(Desktop Only)*** `var/torbrowser_incremental_from` : update to previous Desktop version
- [x] **IMPORTANT**: Really *actually* make sure this is the previous Desktop version or else the `make incrementals-*` step will fail
- [x] ***(Desktop Only)*** Update `projects/firefox/config`
- [x] `git_hash` : update the `$(BUILD_N)` section to match `tor-browser` tag
- [ ] ***(Optional)*** `var/firefox_platform_version` : update to latest `$(ESR_VERSION)` if rebased
- [x] ***(Android Only)*** Update `projects/geckoview/config`
- [ ] `git_hash` : update the `$(BUILD_N)` section to match `geckoview` tag
- [x] ***(Optional)*** `var/geckoview_version` : update to latest `$(RR_VERSION)` if rebased
- [x] ***(Android Only, Optional)*** Update `projects/tba-translations/config`:
- [x] `git_hash` : update with `HEAD` commit of project's `fenix-torbrowserstringsxml` branch
- [ ] ***(Android Only, Optional)*** Update `projects/tor-android-service/config`
- [ ] `git_hash` : update with `HEAD` commit of project's `main` branch
- [ ] ***(Android Only, Optional)*** Update `projects/application-services/config`:
**NOTE** we don't have any of our own patches for this project
- [ ] `git_hash` : update to appropriate git commit associated with $(RR_VERSION)
- [x] ***(Android Only, Optional)*** Update `projects/android-components/config`
- [x] `git_hash` : update the `$(BUILD_N)` section to match `android-components` tag
- [ ] ***(Optional)*** `var/android_components_version` : update to latest `$(RR_VERSION)` if rebased
- [ ] ***(Android Only, Optional)*** Update `projects/fenix/config`
- [ ] `git_hash` : update the `$(BUILD_N)` section to match `fenix` tag
- [ ] ***(Optional)*** `var/fenix_version` : update to latest `$(RR_VERSION)` if rebased
- [x] ***(Android Only)*** Update allowed_addons.json by running (from `tor-browser-build` root):
- `./tools/fetch_allowed_addons.py > projects/tor-browser/allowed_addons.json`
- [x] Check for NoScript updates here : https://addons.mozilla.org/en-US/firefox/addon/noscript
- [x] ***(Optional)*** If new version available, update `noscript` section of `input_files` in `projects/tor-browser/config`
- [x] `URL`
- [x] `sha256sum`
- [x] Check for OpenSSL updates here : https://github.com/openssl/openssl/tags
- [x] ***(Optional)*** If new 1.X.Y series tag available, update `projects/openssl/config`
- [x] `version` : update to next 1.X.Y release tag
- [x] `input_files/sha256sum` : update to sha256 sum of source tarball
- [x] Check for tor updates here : https://gitlab.torproject.org/tpo/core/tor/-/tags ; Tor Browser Alpha uses `-alpha` tagged tor, while stable uses the stable series
- [x] ***(Optional)*** Update `projects/tor/config`
- [x] `version` : update to next release tag
- [x] Check for go updates here : https://golang.org/dl
- **NOTE** : Tor Browser Alpha uses the latest Stable go version, while Tor Browser Stable uses the latest of the previous Stable major series version
- [x] ***(Optional)*** Update `projects/go/config`
- [x] `version` : update go version
- [x] `input_files/sha256sum` for `go` : update sha256sum of archive (sha256 sums are displayed on the go download page)
- [x] ***(Optional)*** Update the manual
- [x] Go to https://gitlab.torproject.org/tpo/web/manual/-/jobs/
- [x] Open the latest build stage
- [x] Download the artifacts (they come in a .zip file).
- [x] Rename it to `manual_$PIPELINEID.zip`
- [x] Upload it to people.tpo
- [x] Update `projects/manual/config`
- [x] Change the version to `$PIPELINEID`
- [x] Update the hash in the input_files section
- [ ] Update the URL if you have uploaded to a different people.tpo home
- [x] Update `ChangeLog.txt`
- [x] Ensure ChangeLog.txt is sync'd between alpha and stable branches
- [x] Open MR with above changes
- [x] Begin build on `$(BUILD_SERVER)` (and fix any issues which come up)
- [x] Sign/Tag commit : `make signtag-(alpha|release)`
- [x] Push tag to origin
### notify stakeholders
- [x] Email tor-qa mailing list: tor-qa@lists.torproject.org
- [x] Provide links to unsigned builds on `$(BUILD_SERVER)`
- [ ] Call out any new functionality which needs testing
- [ ] Link to any known issues
- [x] Email Tails dev mailing list: tails-dev@boum.org
- [x] Provide links to unsigned builds on `$(BUILD_SERVER)`
### blog: https://gitlab.torproject.org/tpo/web/blog.git
- [x] Duplicate previous Stable or Alpha release blog post as appropriate to new directory under `content/blog/new-release-tor-browser-$(TOR_BROWSER_VERSION)` and update with info on release :
- [x] Update Tor Browser version numbers
- [x] Note any ESR rebase
- [x] Note any Rapid Release rebase
- [x] Link to any Firefox security updates
- [x] Note any updates to :
- [x] tor
- [x] OpenSSL
- [x] go
- [ ] NoScript
- [x] Convert ChangeLog.txt to markdown format used here by : `tor-browser-build/tools/changelog-format-blog-post`
- [x] Push to origin as new branch, open 'Draft :' MR
- [x] Remove `Draft:` from MR once signed-packages are uploaded
- [x] Merge
- [ ] Publish after CI passes
### website: https://gitlab.torproject.org/tpo/web/tpo.git
- [x] `databags/versions.ini` : Update the downloads versions
- `torbrowser-stable/version` : sort of a catch-all for latest stable version
- `torbrowser-stable/win32` : tor version in the expert bundle
- `torbrowser-*-stable/version` : platform-specific stable versions
- `torbrowser-*-alpha/version` : platform-specific alpha versions
- `tor-stable`,`tor-alpha` : set by tor devs, do not touch
- [x] Push to origin as new branch, open 'Draft :' MR
- [x] Remove `Draft:` from MR once signed-packages are uploaded
- [x] Merge
- [ ] Publish after CI passes
### signing + publishing
- [x] Ensure builders have matching builds
- [x] On `$(STAGING_SERVER)`, ensure updated:
- [x] `tor-browser-build/tools/signing/set-config`
- [x] `NSS_DB_DIR` : location of the `nssdb7` directory
- [x] `tor-browser-build/tools/signing/set-config.hosts`
- [x] `ssh_host_builder` : ssh hostname of machine with unsigned builds
- **NOTE** : `tor-browser-build` is expected to be in the `$HOME` directory)
- [x] `ssh_host_linux_signer` : ssh hostname of linux signing machine
- [x] `ssh_host_macos_signer` : ssh hostname of macOS signing machine
- [x] `tor-browser-build/tools/signing/set-config.macos-notarization`
- [x] `macos_notarization_user` : the email login for a tor notariser Apple Developer account
- [x] `tor-browser-build/tools/signing/set-config.tbb-version`
- [x] `tbb_version` : tor browser version string, same as `var/torbrowser_version` in `rbm.conf` (examples: `11.5a12`, `11.0.13`)
- [x] `tbb_version_build` : the tor-browser-build build number (if `var/torbrowser_build` in `rbm.conf` is `buildN` then this value is `N`)
- [x] `tbb_version_type` : either `alpha` for alpha releases or `release` for stable releases
- [x] On `$(STAGING_SERVER)` in a separate `screen` session, run the macOS proxy script:
- `cd tor-browser-build/tools/signing/`
- `./macos-signer-proxy`
- [x] On `$(STAGING_SERVER)` in a separate `screen` session, ensure tor daemon is running with SOCKS5 proxy on the default port 9050
- [x] ***(Android Only)*** APK Signing: *TODO*
- [x] run do-all-signing script:
- `cd tor-browser-build/tools/signing/`
- `./do-all-signing.sh`
- **NOTE**: at this point the signed binaries should have been copied to `staticiforme`
- [ ] Update `staticiforme.torproject.org`:
- From `screen` session on `staticiforme.torproject.org`:
- [x] Remove old release data from following places:
- **NOTE** : Skip this step if the current release is Android or Desktop *only*
- [x] `/srv/cdn-master.torproject.org/htdocs/aus1/torbrowser`
- [x] `/srv/dist-master.torproject.org/htdocs/torbrowser`
- [x] Static update components : `static-update-component cdn.torproject.org && static-update-component dist.torproject.org`
- [x] Enable update responses :
- [ ] alpha: `./deploy_update_responses-alpha.sh`
- [x] release: `./deploy_update_responses-release.sh`
- [ ] ***(Android Only)*** : Publish APKs to Google Play:
- [ ] Log into https://play.google.com/apps/publish
- [ ] Select `Tor Browser` app
- [ ] Navigate to `Release > Production` and click `Create new release` button
- [ ] Upload the `*.multi.apk` APKs
- [ ] If necessary, update the 'Release Name' (should be automatically populated)
- [ ] Update Release Notes
- [ ] Next to 'Release notes', click `Copy from a previous release`
- [ ] Edit blog post url to point to most recent blog post
- [ ] Save, review, and configure rollout percentage
- [ ] 25% rollout when publishing a scheduled update
- [ ] 100% rollout when publishing a security-driven release
- [ ] Update rollout percentage to 100% after confirmed no major issues
### tor-announce mailing list
- [x] Send an email to tor-announce@lists.torproject.org, using the same content as the blog post and subject "Tor Browser $version is released".
</details>richardrichardhttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40146Graph single relays' upload bandwidth, CIRC_BW SS=0 and STREAM XOFF_RECV events2022-11-23T11:42:36ZjugaGraph single relays' upload bandwidth, CIRC_BW SS=0 and STREAM XOFF_RECV eventsto see how bandwidth increase/decrease and with which amounts to help decide the initial values for #40142 (chunk size, duration and average).to see how bandwidth increase/decrease and with which amounts to help decide the initial values for #40142 (chunk size, duration and average).sbws: 1.6.x-finaljugajugahttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41155Review Mozilla 1751450: Unsigned DLLs used during per-user installation on Wi...2022-11-23T13:39:41ZrichardReview Mozilla 1751450: Unsigned DLLs used during per-user installation on Windows, prevents use of AppLocker## https://bugzilla.mozilla.org/show_bug.cgi?id=1751450
More reasons we should codesign all of shipped dlls and exes on Windows## https://bugzilla.mozilla.org/show_bug.cgi?id=1751450
More reasons we should codesign all of shipped dlls and exes on WindowsSponsor 131 - Phase 4 - Browser Release Managementrichardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser-spec/-/issues/40037FF102 Audit2022-11-23T13:44:36ZrichardFF102 Audit# General
The audit begins at the commit hash where the previous audit ended. Use code_audit.sh for creating the diff and highlighting potentially problematic code. The audit is scoped to a specific language (currently C/C++, Rust, Java...# General
The audit begins at the commit hash where the previous audit ended. Use code_audit.sh for creating the diff and highlighting potentially problematic code. The audit is scoped to a specific language (currently C/C++, Rust, Java/Kotlin, and Javascript).
The output includes the entire patch where the new problematic code was introduced. Search for `XXX MATCH XXX` to find the next potential violation.
`code_audit.sh` contains the list of known problematic APIs. New usage of these functions are documented and analyzed in this audit.
## Firefox: https://github.com/mozilla/gecko-dev.git
- Start: `856b9168439ef597dbd103cd1e2940a8ad110450` ( `FIREFOX_RELEASE_102_BASE` )
- End: `4960b7d420528392cc095c247a662670785b18b9` ( `FIREFOX_RELEASE_103_BASE` )
### Languages:
- [x] java
- [x] cpp
- [x] js
- [x] rust
Nothing of interest (using `code_audit.sh`)
---
## Application Services: https://github.com/mozilla/application-services.git
- Start: `0302b89604bb29adb34fdcd710feabd3dd01992d` ( `v93.5.0` )
- End: `55cbbddfdcb4ec82d2850e0811e8675fea2686c2` ( `v93.7.0` )
### Languages:
- [x] java
- [x] cpp
- [x] js
- [x] rust
Nothing of interest (using `code_audit.sh`)
## Android Components: https://github.com/mozilla-mobile/android-components.git
- Start: `2b414097d4f540948f67f62f57c5ddcb0e2789d9` ( `v102.0.1` )
- End: `cd19f9a6c5e26c4e57dda6e549a5c63ac7c042ea` ( `v102.0.14` )
### Languages:
- [x] java
- [x] cpp
- [x] js
- [x] rust
Nothing of interest (using `code_audit.sh`)
## Fenix: https://github.com/mozilla-mobile/fenix.git
- Start: `cc68c965cbb29eb16244d242d433051327de5f48` ( `v102.0.0-beta.1` )
- End: `2ec252d5f5d09b3eb73840ce585453b7105a7a7d` ( `releases_v102.0.0` )
### Languages:
- [x] java
- [x] cpp
- [x] js
- [x] rust
Nothing of interest (using `code_audit.sh`)
## Ticket Review ##
### 102 https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&resolution=FIXED&target_milestone=102%20Branch&order=priority%2Cbug_severity&limit=0
- https://bugzilla.mozilla.org/show_bug.cgi?id=1767919 : @pierov https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41152
- ~~https://bugzilla.mozilla.org/show_bug.cgi?id=1770881 : @pierov https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41153~~ 102esr is unaffected: the Bugzilla ticket was wrong and then has been fixed
- https://bugzilla.mozilla.org/show_bug.cgi?id=1765167 : @pierov https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41154
- https://bugzilla.mozilla.org/show_bug.cgi?id=1751450 : @richard https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41155
where `$(FIREFOX_VERSION)` is the major Firefox version we are auditing (eg: '91')
Nothing of interest (manual inspection)
**OR** (foreach)**
### foreach PROBLEMATIC_TICKET:
#### $(PROBLEMATIC_TICKET)
- Summary
- Review Result: (SAFE|BAD)
## Regression/Prior Vuln Review ##
Review proxy bypass bugs; check for new vectors to look for:
- https://gitlab.torproject.org/groups/tpo/applications/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Proxy%20Bypass
- Look for new features like these. Especially external app launch vectors
## Export
- [ ] Export Report and save to `tor-browser-spec/audits`Sponsor 131 - Phase 3 - Major ESR 102 Migrationrichardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40526Add boklm to torbutton.gpg2022-11-23T13:57:26ZrichardAdd boklm to torbutton.gpgSeems weird he can sign entire releases but not firefox et al git tags.Seems weird he can sign entire releases but not firefox et al git tags.richardrichardhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25068Make HSIntro consistent with rend_service_descriptor_t.protocols2022-11-23T14:34:13ZteorMake HSIntro consistent with rend_service_descriptor_t.protocolsHSIntro supports protocol versions 3 and 4:
```
The "HSIntro" protocol handles introduction points.
"3" -- supports authentication as of proposal 121 in Tor
0.2.1.6-alpha.
"4" -- support ed25519 authentication keys w...HSIntro supports protocol versions 3 and 4:
```
The "HSIntro" protocol handles introduction points.
"3" -- supports authentication as of proposal 121 in Tor
0.2.1.6-alpha.
"4" -- support ed25519 authentication keys which is defined by the HS v3
protocol as part of proposal 224 in Tor 0.3.0.4-alpha.
```
But rend_service_update_descriptor() says "intro protocols 2 and 3":
```
/* Support intro protocols 2 and 3. */
d->protocols = (1 << 2) + (1 << 3);
```
I think we need to delete "2" here.
And rend_service_descriptor_t says "introduce/rendezvous" 0-3:
```
/** Bitmask: which introduce/rendezvous protocols are supported?
* (We allow bits '0', '1', '2' and '3' to be set.) */
unsigned protocols : REND_PROTOCOL_VERSION_BITMASK_WIDTH;
```
I think we need to delete "/rendezvous" and 0-2 here.
This seems to be a bug in 496fe68 in 0.2.5.3-alpha.https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/107Fedora Bridge setup guide is missing a step2022-11-23T14:53:44Zqub3Fedora Bridge setup guide is missing a stepA couple of weeks ago i tried setting up a tor bridge on Fedora and i couldn't get the bridge to start, the "systemctl enable ... " part wasn't working. After some (a lot ) of googling i figured out, that you have to disable SeLinux, to ...A couple of weeks ago i tried setting up a tor bridge on Fedora and i couldn't get the bridge to start, the "systemctl enable ... " part wasn't working. After some (a lot ) of googling i figured out, that you have to disable SeLinux, to be able to start tor. Seems to me like something that should be included in the documentation.
Keep up the great work =)https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/7Add a README to WebTunnel2022-11-23T14:57:32ZshelikhooAdd a README to WebTunnelWe [want](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/merge_requests/1#note_2832380) to have a README file.We [want](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/merge_requests/1#note_2832380) to have a README file.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetshelikhooshelikhoohttps://gitlab.torproject.org/tpo/onion-services/onion-launchpad/-/issues/39Create a privacy-preserving landing page analytics roadmap for S1232022-11-23T15:08:02ZrayaCreate a privacy-preserving landing page analytics roadmap for S123Following on from the discussion which started in the July 2022 narrative report [ticket](https://gitlab.torproject.org/tpo/onion-services/onion-support/-/issues/130#note_2823857), we need to discuss next steps for implementing a method ...Following on from the discussion which started in the July 2022 narrative report [ticket](https://gitlab.torproject.org/tpo/onion-services/onion-support/-/issues/130#note_2823857), we need to discuss next steps for implementing a method to collect the number of visitors per S123 landing page.
Copy-pasting the 4 steps suggested by @rhatto to plug Clean Insights (which is based on Matomo and built by The Guardian Project):
> 1. Frontend modifications into the existing landing page code to plug [Clean Insights JS SDK](https://gitlab.com/cleaninsights/clean-insights-js-sdk).
> 2. Consider that this will need some [consent UX](https://okthanks.com/blog/2021/5/14/clean-consent-ux).
> 3. Setting up [Clean Insights Infrastructure](https://gitlab.com/cleaninsights/clean-insights-infrastructure) in a new virtual machine (and maintaining that machine).
> 4. Making sure that landing page deployments from the same service always use the same `siteId` (so stats will be gathered no matter how many mirrors exists and where they're hosted).
I made the issue confidential but I don't believe it needs to be!
cc: @rhattoSponsor 123: Tor Secure Access Package for USAGM [First Phase]Silvio RhattoSilvio Rhatto2022-11-30https://gitlab.torproject.org/tpo/core/tor/-/issues/24667OOM needs to consider the DESTROY queued cells2022-11-23T15:46:53ZDavid Gouletdgoulet@torproject.orgOOM needs to consider the DESTROY queued cellsOur OOM is only looking a the circuit queue cells and HS descriptors to free up memory.
We need to teach it to cleanup DESTROY cells in case cleaning up the circuits is not enough.
This isn't that trivial because while cleaning up circ...Our OOM is only looking a the circuit queue cells and HS descriptors to free up memory.
We need to teach it to cleanup DESTROY cells in case cleaning up the circuits is not enough.
This isn't that trivial because while cleaning up circuits in the OOM handler, we will also send DESTROY cells for those thus allocating memory. But also not sending those will affects other relays hanging on dead circuits.
All in all, this is an interesting challenge but there might be something smart to do even if not perfect.
The idea here is to avoid an attack that takes advantage of a bug in tor that can fill up the DESTROY cell queue and our OOM just can't do anything about it.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40220Make sure tracker cookie purging is disabled2022-11-23T16:28:54ZAlex CatarineuMake sure tracker cookie purging is disabledThis was enabled in 84, and uplifted to 83 (https://bugzilla.mozilla.org/show_bug.cgi?id=1675596). We should probably disable that pref, even though in `GeckoView` we may be setting it to `false` already via `ContentBlocking.java`.This was enabled in 84, and uplifted to 83 (https://bugzilla.mozilla.org/show_bug.cgi?id=1675596). We should probably disable that pref, even though in `GeckoView` we may be setting it to `false` already via `ContentBlocking.java`.Tor Browser: 11.0 Issues with previous releasehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/22548Firefox downgrades VP9 videos to VP8 when measured performance is not enough2022-11-23T17:47:44ZcypherpunksFirefox downgrades VP9 videos to VP8 when measured performance is not enoughOn systems where H.264 is not available or no HWA, VP9 is preferred. But in Tor Browser 7.0 all youtube videos degraded to VP8.On systems where H.264 is not available or no HWA, VP9 is preferred. But in Tor Browser 7.0 all youtube videos degraded to VP8.https://gitlab.torproject.org/tpo/core/arti/-/issues/285Review/rework config API2022-11-23T17:50:01ZIan Jacksoniwj@torproject.orgReview/rework config API## Current tickets
Much has been done. The outstanding work appears to be:
* [x] #456 config: sort out default config file location etc.
* [x] #457 Default config file testing, and comment out settings
* [x] #458 Review config taxo...## Current tickets
Much has been done. The outstanding work appears to be:
* [x] #456 config: sort out default config file location etc.
* [x] #457 Default config file testing, and comment out settings
* [x] #458 Review config taxonomy (!581)
### Previous summary
IMO:
We should adopt a coherent and fairly transparent config management system in both `arti_client` and `arti`. Properties that I would like to see:
* `arti_client` contains a config file reader and there is a convenient way to use it with its defaults.
* The config is sufficient transparent that an application can "pass thorugh" Tor-related config from its own configuration scheme without having to write code which knows about individual sections and values.
* `arti`'s config is done by extending `arti_client`'s config in this way.
* However, individual config settings can be set using native Rust types.
I think this means that at the very least `arti_client::TorClientCfg` needs to be constructable from something which is `Deserialize`. And it needs to have a simple enough data model that it is comprehensibly and readily expressible in at least TOML and JSON.
We should investigate at least the crates `config` `figment` `configparser` and perhaps others, and/or consider DIY `serde` impl.
See also #284 in which I argue that the distinction between `TorClientConfigBuilder` and `TorClient` should not be exposed.Arti 1.0.0: Ready for production useIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/604Introduce BridgeConfigBuilder2022-11-23T17:52:27ZIan Jacksoniwj@torproject.orgIntroduce BridgeConfigBuilderIn the future, we will want to be able to offer a builder-style API for bridges, and deserialize them from TOML dictionaries.
So `BridgeConfig` needs to gain `BridgeConfigBuilder`.
`MultilineListBuilder` (and its serde helper) will nee...In the future, we will want to be able to offer a builder-style API for bridges, and deserialize them from TOML dictionaries.
So `BridgeConfig` needs to gain `BridgeConfigBuilder`.
`MultilineListBuilder` (and its serde helper) will need to be generic over the builder type. The conversion helper to/from `Vec` will then have a stronger constraint than `I: Display`.
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/744#note_2842464Arti 1.1.0: Anticensorship readyIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/635Use `Arc<[Arc<BridgeConfig>]>` in configuration, GuardMgr, etc.2022-11-23T17:52:27ZNick MathewsonUse `Arc<[Arc<BridgeConfig>]>` in configuration, GuardMgr, etc.We frequently want to pass around an `Arc<BridgeConfig>`, such as when we are making a `BridgeRelay`, or when we're telling the `BridgeDescProvider` what bridge we want.
But right now, `GuardMgrConfig` (and hence a lot of other stuff) g...We frequently want to pass around an `Arc<BridgeConfig>`, such as when we are making a `BridgeRelay`, or when we're telling the `BridgeDescProvider` what bridge we want.
But right now, `GuardMgrConfig` (and hence a lot of other stuff) give us a `Vec<BridgeConfig>`, which GuardMgr turns into an `Arc<[BridgeConfig]>`. We should introduce another internal `Arc`.
See discussion at https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/847#note_2853577Arti 1.1.0: Anticensorship readyIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/web/team/-/issues/45make a list of licenses and copyright policies used in web repositories2022-11-23T18:03:57ZKezmake a list of licenses and copyright policies used in web repositoriesquoting from the TPA version of this ticket (tpo/tpa/team#40974):
> in this week's all hands, we discussed copyright policy and established we should at least make an inventory of what licenses are used by which team. we should make a t...quoting from the TPA version of this ticket (tpo/tpa/team#40974):
> in this week's all hands, we discussed copyright policy and established we should at least make an inventory of what licenses are used by which team. we should make a tour of our git repositories (an interesting exercise in itself) and figure out which repository is using which license.
>
>if we do find repositories *without* licenses, we should mark that as a bug and set a license. make sure we have a stated policy on inbound=outbound, for example, and, why not, start using CONTRIBUTING and code of conducts and proper READMEs for all repos...
>
>the output of this should possibly be a RFC setting a team-wide policy about copyright assignment as well.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/18603failIfMajorPerformanceCaveat in a WebGL context might aid in fingerprinting2022-11-23T18:25:49ZGeorg KoppenfailIfMajorPerformanceCaveat in a WebGL context might aid in fingerprintinghttps://bugzilla.mozilla.org/show_bug.cgi?id=1164970 implemented `failIfMajorPerformanceCaveat` that makes the context creation fail when layer acceleration is not supported. We should investigate whether our WebGL normalizing is affecte...https://bugzilla.mozilla.org/show_bug.cgi?id=1164970 implemented `failIfMajorPerformanceCaveat` that makes the context creation fail when layer acceleration is not supported. We should investigate whether our WebGL normalizing is affected by this.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/16404Review WebGL2 spec for fingerprinting issues2022-11-23T18:25:49ZMike PerryReview WebGL2 spec for fingerprinting issuesWebGL2 is available in FF38, but is off by default via a pref (webgl.enable-prototype-webgl2). I imagine it is likely it will be finalized by FF45, so we should review the spec by then.
Here's the spec:
https://www.khronos.org/registry/...WebGL2 is available in FF38, but is off by default via a pref (webgl.enable-prototype-webgl2). I imagine it is likely it will be finalized by FF45, so we should review the spec by then.
Here's the spec:
https://www.khronos.org/registry/webgl/specs/latest/2.0/
This URL also proved useful in the past:
https://www.browserleaks.com/webgl
See also legacy/trac#16005 and legacy/trac#13022.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40685Support raw file descriptors for all relevant configuration options2022-11-23T19:26:12ZJeremy Sakladjeremy@saklad5.comSupport raw file descriptors for all relevant configuration options### Summary
Tor currently supports raw file descriptors only for passphrases. However, it would be extremely beneficial for all types of Tor node if file descriptors could be used in place of any file or address.
One of the primary ben...### Summary
Tor currently supports raw file descriptors only for passphrases. However, it would be extremely beneficial for all types of Tor node if file descriptors could be used in place of any file or address.
One of the primary benefits of accepting file descriptors is that it allows Tor to be implemented with socket activation. This was discussed in a much more narrow sense in https://gitlab.torproject.org/tpo/core/tor/-/issues/8908, but that was closed due to focusing entirely on the performance benefit.
If Tor allowed file descriptors more broadly, users could easily connect it to any service management system they want: systemd, yes, but also launchd. This allows for socket activation, which makes a considerable difference when booting the OS, and more importantly it allows networking to be handled at a higher level.
For clients, this can mean that Tor is started in a more efficient manner, and is provided more resources based on connection activity. **For relays and directories, this allows Tor to bind to any port it wants without requiring special privileges**: the OS opens the socket, and Tor merely accepts it. For onion services, this allows dependencies between an onion service and whatever it connects with to be automatically managed, without needing to specify a loopback address or Unix domain socket.
### What is the expected behavior?
Any Tor configuration option that accepts a file path or socket should also accept a file descriptor. This would mainly be used by service profiles (launchd LaunchAgents, systemd service units, etc.) to pass network sockets through the command line.
If only implementing this for specific options is preferred, I feel the following options (in descending utility) should be supported:
1. ORPort
2. DirPort
3. SocksPort
4. HiddenServicePort
5. ControlPort
Note that I am not asking for Tor to natively support a specific service manager: that would be much more difficult to maintain, and far more complicated.
I'd also like to reiterate that this isn't just for socket activation. In fact, relays *couldn't* use it for socket activation: nothing would connect to an ORPort until Tor started advertising it.https://gitlab.torproject.org/tpo/core/tor/-/issues/40719cpuworker: Off by one when calculating the onionskin processing room2022-11-23T19:58:21ZDavid Gouletdgoulet@torproject.orgcpuworker: Off by one when calculating the onionskin processing roomIn `onion_queue.c`, our function `have_room_for_onionskin()` uses the number of CPUs to calculate an average of time we processed an onionskin across all threads. For example:
```
/* How long would it take to process all the NTor ce...In `onion_queue.c`, our function `have_room_for_onionskin()` uses the number of CPUs to calculate an average of time we processed an onionskin across all threads. For example:
```
/* How long would it take to process all the NTor cells in the queue? */
ntor_usec = estimated_usec_for_onionskins(
ol_entries[ONION_HANDSHAKE_TYPE_NTOR],
ONION_HANDSHAKE_TYPE_NTOR) / num_cpus;
```
The `num_cpus` value is taken by calling `get_num_cpus()` which returns the number of core the system has. However, our CPU worker thread pool is configured to always have an extra thread (see `cpuworker.c`):
```
const int n_threads = get_num_cpus(get_options()) + 1;
```
And so we are off by one in terms of number of CPU for our calculation. Meaning that we are **over** estimating our ntor onionskin process time because our divisor is minus off by one from the real number of threads being used for onionskins.
This can lead to triggering the overload signal way too early on relays.Tor: 0.4.7.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org