tor-browser-build issueshttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues2022-12-22T11:22:11Zhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40630Update builtin bridges from Circumvention Settings API2022-12-22T11:22:11Zmeskiomeskio@torproject.orgUpdate builtin bridges from Circumvention Settings APIRight now to update the builtin bridges we need to make a Tor Browser release, it would be nice if TB automatically updates them using [Circumvention Settings API](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/doc/m...Right now to update the builtin bridges we need to make a Tor Browser release, it would be nice if TB automatically updates them using [Circumvention Settings API](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/doc/moat.md#circumventionbuiltin).
There are two concerns I have about it:
* Users will not be happy with TB making a call to an external API without giving some consent about it.
* We don't want to make easier for censors to notice you are using Tor because of that.
I think it makes sense to update when we do other connections to moat (Connect Assist, captcha bridges, ...), I assume user has already consent to do a request to the API on those cases and having an extra connection over the domain fronting should not make it more noticeable than it already is. We could store when was the last time we had updated them, and don't update them is they are fresh (maybe 24h is a good freshness).
An extra that would be nice is to ask the user if they want to refresh the builtin bridges when they click on Settings to *Select a Built-In Bridge*. I think we should only ask if bridges hasn't being refreshed for a while (maybe 7days). The confirmation popup could have a check box with 'remember that option' or something like that, so the following times they enable builtin bridges we refresh or not without asking (if the bridges hasn't being refreshed in 7days).Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40629Bump snowflake version to 9ce1de4eee4e2022-10-15T02:40:41ZCecylia BocovichBump snowflake version to 9ce1de4eee4eThis will update snowflake to have some new features, including:
- distributed bridge support
- utlsThis will update snowflake to have some new features, including:
- distributed bridge support
- utlsCecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40628Prepare stable release 11.5.52022-11-08T10:21:10ZrichardPrepare stable release 11.5.5<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://git.torproject.org/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://git.torproject.org/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://git.torproject.org/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://git.torproject.org/tor-browser.git
- [ ] ***(Optional)*** Rebase to `$(RR_VERSION)`
- [x] Find the Firefox hg tag here : https://hg.mozilla.org/releases/mozilla-release/tags
- [x] `$(RR_TAG)` : `FIREFOX_102_4_0esr_BUILD1`
- [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 : df868fe98ed5d25b9d6c2994d77f74929c938e78
- [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):
- [x] rangediff: `git range-diff $(RR_TAG_PREV)..$(GECKOVIEW_BRANCH_PREV) $(RR_TAG)..$(GECKOVIEW_BRANCH)`
- [x] 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 -
- [x] `git diff $(RR_TAG_PREV)..$(GECKOVIEW_BRANCH_PREV) > current_patchset.diff`
- [x] `git diff $(RR_TAG)..$(GECKOVIEW_BRANCH) > rebased_patchset.diff`
- [x] `$(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://git.torproject.org/translation.git
- **NOTE** We only update strings in stable if a backported feature depends on new strings
- [x] Fetch latest and identify new `HEAD` of `fenix-torbrowserstringsxml` branch
- [x] `origin/fenix-torbrowserstringsxml` : `9ed8ec8aef95cd3b4e61e7e77e2113cbd13c4528`
### **tor-android-service** ***(Optional)***: https://git.torproject.org/tor-android-service.git
- [x] Fetch latest and identify new `HEAD` of `main` branch
- [x] `origin/main` : `20738f8d347778a274c9ae782026ecca1c682a4a`
### **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
- [ ] 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
- [ ] ***(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 : `android-components-$(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
### **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
- [x] 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)`
- [x] Push tag to origin
</details>
<details>
<summary>Build/Signing/Publishing</summary>
### tor-browser-build: https://git.torproject.org/builders/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`
- [x] `git_hash` : update the `$(BUILD_N)` section to match `geckoview` tag
- [ ] ***(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)
- [ ] ***(Android Only, Optional)*** Update `projects/android-components/config`
- [ ] `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
- [ ] ***(Optional)*** If new version available, update `noscript` section of `input_files` in `projects/tor-browser/config`
- [ ] `URL`
- [ ] `sha256sum`
- [x] Check for OpenSSL updates here : https://github.com/openssl/openssl/tags
- [ ] ***(Optional)*** If new 1.X.Y series tag available, update `projects/openssl/config`
- [ ] `version` : update to next 1.X.Y release tag
- [ ] `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
- [ ] ***(Optional)*** Update `projects/tor/config`
- [ ] `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
- [x] 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)
- [ ] Sign/Tag commit : `make signtag-(alpha|release)`
- [ ] 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)`
- [x] Call out any new functionality which needs testing
- [x] 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
- [ ] Note any updates to :
- [ ] tor
- [ ] OpenSSL
- [ ] 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
- [x] 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
- [x] Publish after CI passes
### signing + publishing
- [x] Ensure builders have matching builds
- [ ] 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
- [ ] `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`
- [x] 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:
- [x] Log into https://play.google.com/apps/publish
- [x] Select `Tor Browser` app
- [x] Navigate to `Release > Production` and click `Create new release` button
- [x] Upload the `*.multi.apk` APKs
- [x] If necessary, update the 'Release Name' (should be automatically populated)
- [x] Update Release Notes
- [x] Next to 'Release notes', click `Copy from a previous release`
- [x] Edit blog post url to point to most recent blog post
- [x] Save, review, and configure rollout percentage
- [x] 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/applications/tor-browser-build/-/issues/40627Prepare alpha release 12.0a42022-11-02T20:04:05ZrichardPrepare alpha release 12.0a4<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
- `$(ESR_VERSION)` : the Mozilla defined ESR version, used in various places for building tor-browser tags, labels, etc
- example : `91.6.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: `103`
- `$(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)
- `$(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)
</details>
<details>
<summary>Desktop</summary>
### **torbutton** : https://gitlab.torproject.org/tpo/applications/torbutton.git
- [x] Update translations :
- [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
- [ ] ***(Optional)*** Backport to maintenance branch if present and necessary
- [x] fixup! `tor-browser`'s `Bug 10760 : Integrate TorButton to TorBrowser core` issue to point to updated `torbutton` commit
</details>
<details>
<summary>Android</summary>
### **tba-translation** : https://gitlab.torproject.org/tpo/translation.git
- [x] Fetch latest and identify new `HEAD` of `fenix-torbrowserstringsxml` branch
- [x] `origin/fenix-torbrowserstringsxml` : `90a6fff8ca10c6843dc7ef3ba4bff5336299cf6a`
### **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>`
### ***Security Vulnerabilities Backport*** : https://www.mozilla.org/en-US/security/advisories/
- [x] Go through any `Security Vulnerabilities fixed in Firefox $(RR_VERSION)` (or similar) and create list of CVEs which affect Android that need to be a backported
- Potentially Affected Components:
- `firefox`
- `application-services`
- `android-components`
- `fenix`
- [ ] Create issue for each backport in `tor-browser` and merge requests for `cherry-pick`'d fixes in each affected component
- [ ] Link each created backport issue to this release prep issue
### **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
- [ ] 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** : https://gitlab.torproject.org/tpo/applications/android-components.git
- [ ] ***(Optional)*** Backport any Android-specific security fixes from Firefox rapid-release
- [x] Sign/Tag commit:
- Tag : `android-components-$(ESR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-$(BUILD_N)`
- Message: `Tagging $(BUILD_N) for $(ESR_VERSION)-based (alpha|stable)`
- [x] Push tag to `origin`
### **fenix** : https://gitlab.torproject.org/tpo/applications/fenix.git
- [ ] ***(Optional)*** Backport any Android-specific security fixes from Firefox rapid-release
- [x] Sign/Tag commit:
- Tag : `tor-browser-$(ESR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-$(BUILD_N)`
- Message: `Tagging $(BUILD_N) for $(ESR_VERSION)-based (alpha|stable)`
- [x] Push tag to `origin`
</details>
<details>
<summary>Shared</summary>
### tor-browser: https://gitlab.torproject.org/tpo/applications/tor-browser.git
- [ ] ***(Optional)*** Backport any Android-specific security fixes from Firefox rapid-release
- [x] ***(Optional)*** Rebase to `$(ESR_VERSION)`
- [x] Find the Firefox hg tag here : https://hg.mozilla.org/releases/mozilla-esr102/tags
- [x] `$(ESR_TAG)` : `FIREFOX_102_4_0esr_BUILD1`
- [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 : `df868fe98ed5d25b9d6c2994d77f74929c938e78`
- [x] 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`
- [x] Sign/Tag commit :
- Tag : `$(ESR_TAG)`
- Message : `Hg tag $(ESR_TAG)`
- [x] Push new branch and tag to origin
- [x] Rebase `tor-browser` patches
- [x] Compare patch-sets (ensure nothing *weird* happened during rebase):
- [x] rangediff: `git range-diff $(ESR_TAG_PREV)..$(TOR_BROWSER_BRANCH_PREV) $(ESR_TAG)..$(TOR_BROWSER_BRANCH)`
- [x] 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`
- [x] Open MR for the rebase
- [x] Sign/Tag `base-browser` commit:
- **NOTE** : Currently we are using the `Bug 27511: Add new identity button to toolbar` commit as the dividing line between `base-browser` and `tor-browser`
- **NOTE** : If we need to prepare a release without a rebase that includes a patch that needs to be in the `base-browser` section (such as a Mozilla chemspill release) we will create an entirely new branch with a `-2` suffix
- Tag : `base-browser-$(ESR_VERSION)esr-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-build1`
- Message: `Tagging build1 for $(ESR_VERSION)esr-based (alpha|stable)`
- [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`
- [x] Update Gitlab Default Branch to new Alpha branch: https://gitlab.torproject.org/tpo/applications/tor-browser/-/settings/repository
</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] Update `projects/firefox/config`
- [x] `git_hash` : update the `$(BUILD_N)` section to match `tor-browser` tag
- [x] ***(Optional)*** `var/firefox_platform_version` : update to latest `$(ESR_VERSION)` if rebased
- [x] Update `projects/geckoview/config`
- [x] `git_hash` : update the `$(BUILD_N)` section to match `tor-browser` tag
- [x] ***(Optional)*** `var/geckoview_version` : update to latest `$(ESR_VERSION)` if rebased
- [x] Update `projects/translation-base-browser/config`
- [x] `git_hash` : update with `HEAD` commit of project's `base-browser` branch
- [x] Update `projects/tba-translations/config`:
- [x] `git_hash` : update with `HEAD` commit of project's `fenix-torbrowserstringsxml` branch
- [ ] Update `projects/tor-android-service/config`
- [ ] `git_hash` : update with `HEAD` commit of project's `main` branch
- [ ] 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 $(ESR_VERSION)
- [x] Update `projects/android-components/config`:
- [x] `git_hash` : update the `$(BUILD_N)` section to match alpha `android-components` tag
- [x] Update `projects/fenix/config`
- [x] `git_hash` : update the `$(BUILD_N)` section to match `fenix` tag
- [ ] ***(Optional)*** `var/fenix_version` : update to latest `$(ESR_VERSION)` if rebased
- [x] Update allowed_addons.json by running (from `tor-browser-build` root):
- `./tools/fetch_allowed_addons.py > projects/browser/allowed_addons.json`
- [x] Check for NoScript updates here : https://addons.mozilla.org/en-US/firefox/addon/noscript
- [ ] ***(Optional)*** If new version available, update `noscript` section of `input_files` in `projects/browser/config`
- [ ] `URL`
- [ ] `sha256sum`
- [x] Check for OpenSSL updates here : https://github.com/openssl/openssl/tags
- [ ] ***(Optional)*** If new 1.X.Y series tag available, update `projects/openssl/config`
- [ ] `version` : update to next 1.X.Y release tag
- [ ] `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
- [ ] ***(Optional)*** Update `projects/tor/config`
- [ ] `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
- [ ] ***(Optional)*** Update `projects/go/config`
- [ ] `version` : update go version
- [ ] `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
- [ ] Email tor-qa mailing list: tor-qa@lists.torproject.org
- [ ] Provide links to unsigned builds on `$(BUILD_SERVER)`
- [ ] Call out any new functionality which needs testing
- [ ] Link to any known issues
- [ ] Email Tails dev mailing list: tails-dev@boum.org
- [ ] 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
- [ ] Note any Rapid Release rebase
- [x] Link to any Firefox security updates
- [ ] Note any updates to :
- [ ] tor
- [ ] OpenSSL
- [ ] 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
- [ ] Remove `Draft:` from MR once signed-packages are uploaded
- [ ] Merge
- [ ] Publish after CI passes
### website: https://gitlab.torproject.org/tpo/web/tpo.git
- [ ] `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
- [ ] Push to origin as new branch, open 'Draft :' MR
- [ ] Remove `Draft:` from MR once signed-packages are uploaded
- [ ] Merge
- [x] Publish after CI passes
### signing + publishing
- [x] Ensure builders have matching builds
- [ ] 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] 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`
- [x] 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 :
- [x] alpha: `./deploy_update_responses-alpha.sh`
- [ ] release: `./deploy_update_responses-release.sh`
- [x] Publish APKs to Google Play:
- [ ] Log into https://play.google.com/apps/publish
- [ ] Select `Tor Browser (Alpha)` 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)
- [x] Update Release Notes
- [x] Next to 'Release notes', click `Copy from a previous release`
- [x] Edit blog post url to point to most recent blog post
- [x] Save, review, and configure rollout percentage
- [x] 25% rollout when publishing a scheduled update
- [ ] 100% rollout when publishing a security-driven release
- [x] 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/applications/tor-browser-build/-/issues/40626Define the replacements for generic families on Linux2022-10-18T12:23:52ZPier Angelo VendrameDefine the replacements for generic families on LinuxFontConfig does not know much about our fonts, and falls back to the font version, when it cannot find any other criterion to decide which font to use (see tor-browser#41043).
So, we want to make sure that at least `sans-serif`, `serif`...FontConfig does not know much about our fonts, and falls back to the font version, when it cannot find any other criterion to decide which font to use (see tor-browser#41043).
So, we want to make sure that at least `sans-serif`, `serif` and `monospace` are the fonts we want (currently, Arimo, Tinos and Cousine).
This is needed for example for tor-browser#41116: we have patched system fonts, but Firefox does not double check their values with the font replacement system, and queries FontConfig for the font to use directly.
I think that patching the `fonts.conf` is the correct solution for this use-case.Sponsor 131 - Phase 3 - Major ESR 102 MigrationPier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40625Consider building with _FORTIFY_SOURCE=32023-01-05T13:54:04ZintrigeriConsider building with _FORTIFY_SOURCE=3According to https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level, `_FORTIFY_SOURCE=3` improves memory management protections. It requires glibc 2.34. It's been supported in Clang "for some time" and support was...According to https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level, `_FORTIFY_SOURCE=3` improves memory management protections. It requires glibc 2.34. It's been supported in Clang "for some time" and support was added to GCC 12.Sponsor 131 - Phase 5 - Ongoing Maintenancehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40624Change placeholder bridge addresses to make snowflake and meek work with Reac...2023-05-02T02:18:50ZDavid Fifielddcf@torproject.orgChange placeholder bridge addresses to make snowflake and meek work with ReachableAddresses/FascistFirewallChange the addresses in bridge lines to use port 80 so that tor will consider the bridge lines usable.
A torrc Bridge line requires an IP:port address as part of the syntax. The IP:port address is required, even for transports that are ...Change the addresses in bridge lines to use port 80 so that tor will consider the bridge lines usable.
A torrc Bridge line requires an IP:port address as part of the syntax. The IP:port address is required, even for transports that are not based on making a single connection to a single endpoint; for that reason, Snowflake and meek use "placeholder" addresses, currently 192.0.2.3:1 and 192.0.2.2:2 respectively. However, this causes a problem with ReachableAddresses/FascistFirewall (i.e. the "This computer goes through a firewall that only allows connections to certain ports" setting). tor doesn't know that these transports do not actually connect to the placeholder addresses; all it sees is that port 1 and port 2 are not on the permitted list, so it considers the bridge unusable (tpo/core/tor#19487):
```
[NOTICE] Bridge at '192.0.2.2:2' isn't reachable by our firewall policy. Asking bridge authority instead.
```
The anti-censorship team proposes to set the port of placeholder addresses to 80, so that Snowflake and meek will be usable even when ReachableAddresses/FascistFirewall is set.
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40159#note_2834570
> We currently assign placeholder addresses using the format
>
> > 192.0.2.<var>t</var>:<var>n</var>
>
> where <var>t</var> indicates the transport (1=flashproxy, 2=meek, 3=snowflake) and <var>n</var> is a counter if there are multiple bridge lines for single transport (currently that doesn't happen, but in the past we had :1 for meek-google, :2 for meek-amazon, :3 for meek-azure; and tpo/anti-censorship/pluggable-transports/snowflake#28651 will add a second snowflake bridge).
>
> If we switch to a hardcoded port of 80, there will not be separate places to encode <var>t</var> and <var>n</var>. But we could encode them both into one byte, using 4 bits for <var>t</var> and 4 bits for <var>n</var>:
>
> > 192.0.2.(16(<var>n</var>ā1)+<var>t</var>):80
The team discussed this at the 2022-09-08 meeting.
http://meetbot.debian.net/tor-meeting/2022/tor-meeting.2022-09-08-15.58.log.html#l-66
```
16:26:30 <meskio> "A new format for placeholder addresses in PT bridge lines"
16:26:37 <dcf1> okay, quick note about placeholder addresses
16:27:12 <dcf1> we have been using placeholder addresses with incrementing port numbers :1, :2, :3, etc., because tor requires all PT bridges to have different IP:port, or it gets them confused
16:27:56 <dcf1> this causes a problem when tor is configured with ReachableAddresses or FascistFirewall, because tor thinks the PT is going to try to actually make a TCP connection to those placeholder addresses
16:28:22 <dcf1> and it says "port 1 is not one of the ports permitted by FascistFirewall, therefore I will not attempt this bridge connection"
16:28:35 <dcf1> imo it's a bug in core tor, but it's WONTFIX for years now
16:29:15 <meskio> it might not get fixed until arti
16:29:23 <dcf1> so the proposal is to move this counter into the IP address and always use port 80 for placeholder addresses, to make them more likely to work with ReachableAddresses and FascistFirewall
16:30:49 <dcf1> Way back in flash proxy, which also needed a placeholder address, I tried to make the placeholder look as different from an actual usable IP address as possible, to reduce confusion
16:31:20 <dcf1> since then, the placeholders have been slowly morphing to look more and more like real IP addresses :)
16:31:38 <dcf1> the progression was something like:
16:31:57 <dcf1> 0.0.0.0:0 <- no good, tor uses the all-zero address as a sentinel internally
16:32:09 <dcf1> 0.0.0.1:1 <- no good, 0.0.0.X is used by SOCKS
16:32:35 <dcf1> 0.0.1.0:1 <- we used this for a while, but it ran into problems with 0/8 being considered "internal" by tor
16:32:59 <dcf1> 192.0.2.1:1 <- what we use now, using a special non-routable IP range reserved for documentation
16:33:13 <dcf1> 192.0.2.1:80 <- new proposal
...
16:39:19 <dcf1> okay well I will propose a merge request with the 192.0.2.(16(nā1)+t):80 format, it's good enough for our needs for now
```Sponsor 131 - Phase 3 - Major ESR 102 Migrationrichardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40623ChangeLog.txt symlink points to old projects/tor-browser2022-09-10T02:48:42ZDavid Fifielddcf@torproject.orgChangeLog.txt symlink points to old projects/tor-browser#40500 (c52bc0e57555bcb0d49ead1f409eb679268a49a5) renamed projects/tor-browser to projects/browser, which broke the ChangeLog.txt symlink.
```
tor-browser-build$ file ChangeLog.txt
ChangeLog.txt: broken symbolic link to projects/tor-br...#40500 (c52bc0e57555bcb0d49ead1f409eb679268a49a5) renamed projects/tor-browser to projects/browser, which broke the ChangeLog.txt symlink.
```
tor-browser-build$ file ChangeLog.txt
ChangeLog.txt: broken symbolic link to projects/tor-browser/Bundle-Data/Docs/ChangeLog.txt
```https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40622Update obfs4proxy to 0.0.14 in Tor Browser2022-11-09T09:52:55ZboklmUpdate obfs4proxy to 0.0.14 in Tor BrowserThere is a new obfs4proxy version including a security fix (tpo/anti-censorship/pluggable-transports/obfs4#40008), so we should update it in Tor Browser.There is a new obfs4proxy version including a security fix (tpo/anti-censorship/pluggable-transports/obfs4#40008), so we should update it in Tor Browser.boklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40621Update namecoin patches for linted TorButton2022-09-09T11:31:12ZPier Angelo VendrameUpdate namecoin patches for linted TorButtonWe have recently linted torbutton (torbutton!91), and now namecoin patches fail to apply, and this makes the nightly builds for Linux (and maybe Windows?) fail.
/cc @JeremyRandWe have recently linted torbutton (torbutton!91), and now namecoin patches fail to apply, and this makes the nightly builds for Linux (and maybe Windows?) fail.
/cc @JeremyRandSponsor 131 - Phase 3 - Major ESR 102 Migrationhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40619Make sure translations are taken from gitlab.tpo and not git.tpo2022-10-18T12:22:16ZemmapeelMake sure translations are taken from gitlab.tpo and not git.tpoWeblate has a good integration with gitlab, and we want to stop relying on gitolite/git.torproject.org for translations.
Please make sure your build scripts use the translations from git@gitlab.torproject.org:tpo/translation.git and not...Weblate has a good integration with gitlab, and we want to stop relying on gitolite/git.torproject.org for translations.
Please make sure your build scripts use the translations from git@gitlab.torproject.org:tpo/translation.git and not https://git.torproject.org/translation.git
Thanks!Sponsor 9 - Phase 6 - Usability and Community Intervention on Support for Democracy and Human RightsPier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40618Add support for android-only and desktop-only releases in do-all-signing2023-11-01T19:17:53ZboklmAdd support for android-only and desktop-only releases in do-all-signingIn `tools/signing/set-config.tbb-version` we should add some option to say if a release is desktop-only, or android-only, and make `do-all-signing` only run the steps relevant for desktop or android in those cases.In `tools/signing/set-config.tbb-version` we should add some option to say if a release is desktop-only, or android-only, and make `do-all-signing` only run the steps relevant for desktop or android in those cases.Sponsor 131 - Phase 4 - Browser Release Managementboklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40617Backport fix for CVE-2022-38474: Recording notification not shown when microp...2022-08-31T21:19:15ZrichardBackport fix for CVE-2022-38474: Recording notification not shown when microphone was recording on Android (Bug 1719511)Fixed in https://bugzilla.mozilla.org/show_bug.cgi?id=1719511Fixed in https://bugzilla.mozilla.org/show_bug.cgi?id=1719511richardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40616Backport fix for CVE-2022-36317: Long URL would hang Firefox for Android (Bug...2022-08-31T21:19:04ZrichardBackport fix for CVE-2022-36317: Long URL would hang Firefox for Android (Bug 1759951)Fixed in https://bugzilla.mozilla.org/show_bug.cgi?id=1759951Fixed in https://bugzilla.mozilla.org/show_bug.cgi?id=1759951richardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40615Consider adding a readme to the fonts directory2023-10-03T15:38:05ZPier Angelo VendrameConsider adding a readme to the fonts directoryWe could add a readme.txt to the font directory, in which we explain users that they aren't supposed to add fonts on their own, sum up the risk, and link some FAQ page.We could add a readme.txt to the font directory, in which we explain users that they aren't supposed to add fonts on their own, sum up the risk, and link some FAQ page.Sponsor 131 - Phase 2 - Privacy Browserhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40614Update release templates with feedback from ma12022-08-30T17:41:11ZrichardUpdate release templates with feedback from ma1@ma1 went through the release prep process for 11.5.3 and had some feedback. We should update the templates to be more clear and make explicit the implicit.@ma1 went through the release prep process for 11.5.3 and had some feedback. We should update the templates to be more clear and make explicit the implicit.richardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40613Prepare stable release (Android Only) 11.5.32022-08-30T16:48:56ZrichardPrepare stable release (Android Only) 11.5.3<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://git.torproject.org/torbutton.git
- [ ] ***(Optional)*** Update translations :
- **NOTE** : mandatory if we have added new string dependencies
- [ ] `./import-translations.sh`
- [ ] Commit with message `Translation updates`
- **NOTE** : only add files which are already being tracked
- [ ] fixup! `tor-browser`'s `Bug 10760 : Integrate TorButton to TorBrowser core` issue to point to updated `torbutton` commit
### **tor-launcher** ***(Optional)***: https://git.torproject.org/tor-launcher.git
- [ ] ***(Optional)*** Update translations:
- **NOTE** : mandatory if we have added new string dependencies
- [ ] ./localization/import-translations.sh
- [ ] Commit with message `Translation updates`
- [ ] Update `install.rdf` file with new version
- [ ] Sign/Tag commit :
- Tag : `$(TOR_LAUNCHER_VERSION)`
- Message `Tagging $(TOR_LAUNCHER_VERSION)`
- [ ] Push `main` and tag to origin
### tor-browser: https://git.torproject.org/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
- [ ] ***(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
- [ ] 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)`
- [ ] Push tag to `origin`
</details>
<details>
<summary>Android</summary>
### **geckoview**: https://git.torproject.org/tor-browser.git
- [ ] ***(Optional)*** Rebase to `$(RR_VERSION)`
- [ ] Find the Firefox hg tag here : https://hg.mozilla.org/releases/mozilla-release/tags
- [ ] `$(RR_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 `geckoview` branch with the discovered `gecko-dev` commit as `HEAD` named `geckoview-$(RR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR-BROWSER_MINOR)-1`
- [ ] Sign/Tag commit :
- Tag : `$(RR_TAG)`
- Message : `Hg tag $(RR_TAG)`
- [ ] Push new branch and tag to origin
- [ ] Rebase `geckoview` patches
- [ ] 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`
- [ ] 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
- [ ] 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)`
- [ ] Push tag to `origin`
### **tba-translation** ***(Optional)***: https://git.torproject.org/translation.git
- [ ] Fetch latest and identify new `HEAD` of `fenix-torbrowserstringsxml` branch
- [ ] `origin/fenix-torbrowserstringsxml` :`<INSERT COMMIT HASH HERE>`
### **android-components** ***(Optional)***: https://gitlab.torproject.org/tpo/applications/android-components.git
- [ ] ***(Optional)*** Rebase to `$(RR_VERSION)`
- Upstream git repo : https://github.com/mozilla-mobile/android-components.git
- [ ] 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
- [ ] ***(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 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
### **tor-android-service** ***(Optional)***: https://git.torproject.org/tor-android-service.git
- [ ] Fetch latest and identify new `HEAD` of `main` branch
- [ ] `origin/main` : `<INSERT COMMIT HASH HERE>`
### **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
- [x] 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)`
- [x] Push tag to origin
</details>
<details>
<summary>Build/Signing/Publishing</summary>
### tor-browser-build: https://git.torproject.org/builders/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)`
- [ ] `var/torbrowser_incremental_from` : update to previous version
- [ ] **IMPORTANT**: Really *actually* make sure this is the previous Desktop version or else the `make incrementals-*` step will fail
- [ ] Update `projects/firefox/config`
- [ ] `git_hash` : update the `$(BUILD_N)` section to match `tor-browser` tag
- [ ] ***(Optional)*** `var/firefox_platform_version` : update to latest `$(ESR_VERSION)` if rebased
- [ ] ***(Android Only)*** Update `projects/geckoview/config`
- [ ] `git_hash` : update the `$(BUILD_N)` section to match `geckoview` tag
- [ ] ***(Optional)*** `var/geckoview_version` : update to latest `$(RR_VERSION)` if rebased
- [ ] ***(Android Only, Optional)*** Update `projects/tba-translations/config`:
- [ ] `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
- [x] ***(Android Only, Optional)*** Update `projects/fenix/config`
- [x] `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, Optional)*** Update `projects/android-components/config`
- [x] `git_hash` : update the `$(BUILD_N)` section to match `android-components` tag
- [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
- [ ] ***(Optional)*** If new version available, update `noscript` section of `input_files` in `projects/tor-browser/config`
- [ ] `URL`
- [ ] `sha256sum`
- [x] Check for OpenSSL updates here : https://github.com/openssl/openssl/tags
- [ ] ***(Optional)*** If new 1.X.Y series tag available, update `projects/openssl/config`
- [ ] `version` : update to next 1.X.Y release tag
- [ ] `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
- [ ] ***(Optional)*** Update `projects/tor/config`
- [ ] `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
- [ ] ***(Optional)*** Update `projects/go/config`
- [ ] `version` : update go version
- [ ] `input_files/sha256sum` for `go` : update sha256sum of archive (sha256 sums are displayed on the go download page)
- [ ] ***(Optional)*** Update the manual
- [ ] Go to https://gitlab.torproject.org/tpo/web/manual/-/jobs/
- [ ] Open the latest build stage
- [ ] Download the artifacts (they come in a .zip file).
- [ ] Rename it to `manual_$PIPELINEID.zip`
- [ ] Upload it to people.tpo
- [ ] Update `projects/manual/config`
- [ ] Change the version to `$PIPELINEID`
- [ ] 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`
- [ ] 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
- [ ] Email tor-qa mailing list: tor-qa@lists.torproject.org
- [ ] Provide links to unsigned builds on `$(BUILD_SERVER)`
- [ ] Call out any new functionality which needs testing
- [ ] Link to any known issues
- [ ] Email Tails dev mailing list: tails-dev@boum.org
- [ ] 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 :
- [ ] Update Tor Browser version numbers
- [ ] Note any ESR rebase
- [ ] Note any Rapid Release rebase
- [ ] Link to any Firefox security updates
- [ ] Note any updates to :
- [ ] tor
- [ ] OpenSSL
- [ ] 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
- [x] 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
- [x] Publish after CI passes
### signing + publishing
- [x] Ensure builders have matching builds
- [ ] On `$(STAGING_SERVER)`, ensure updated:
- [ ] `tor-browser-build/tools/signing/set-config`
- [ ] `NSS_DB_DIR` : location of the `nssdb7` directory
- [ ] `tor-browser-build/tools/signing/set-config.hosts`
- [ ] `ssh_host_builder` : ssh hostname of machine with unsigned builds
- **NOTE** : `tor-browser-build` is expected to be in the `$HOME` directory)
- [ ] `ssh_host_linux_signer` : ssh hostname of linux signing machine
- [ ] `ssh_host_macos_signer` : ssh hostname of macOS signing machine
- [ ] `tor-browser-build/tools/signing/set-config.macos-notarization`
- [ ] `macos_notarization_user` : the email login for a tor notariser Apple Developer account
- [ ] `tor-browser-build/tools/signing/set-config.tbb-version`
- [ ] `tbb_version` : tor browser version string, same as `var/torbrowser_version` in `rbm.conf` (examples: `11.5a12`, `11.0.13`)
- [ ] `tbb_version_build` : the tor-browser-build build number (if `var/torbrowser_build` in `rbm.conf` is `buildN` then this value is `N`)
- [ ] `tbb_version_type` : either `alpha` for alpha releases or `release` for stable releases
- [ ] On `$(STAGING_SERVER)` in a separate `screen` session, run the macOS proxy script:
- `cd tor-browser-build/tools/signing/`
- `./macos-signer-proxy`
- [ ] 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*
- [ ] 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`
- [x] Update `staticiforme.torproject.org`:
- From `screen` session on `staticiforme.torproject.org`:
- [x] Static update components : `static-update-component cdn.torproject.org && static-update-component dist.torproject.org`
- [ ] Enable update responses :
- [ ] alpha: `./deploy_update_responses-alpha.sh`
- [ ] release: `./deploy_update_responses-release.sh`
- [x] ***(Android Only)*** : Publish APKs to Google Play:
- [x] Log into https://play.google.com/apps/publish
- Select correct app:
- [x] Tor Browser
- [ ] Tor Browser Alpha
- [x] Navigate to `Release > Production` and click `Create new release` button
- [x] Upload the `*.multi.apk` APKs
- [x] If necessary, update the 'Release Name' (should be automatically populated)
- [x] Update Release Notes
- [x] Next to 'Release notes', click `Copy from a previous release`
- [x] Edit blog post url to point to most recent blog post
- [ ] Save, review, and configure rollout percentage
- [x] 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/applications/tor-browser-build/-/issues/40620Review Mozilla 1734331: Upgrade toolchains to macosx-sdk 11.02022-09-02T17:01:53ZrichardReview Mozilla 1734331: Upgrade toolchains to macosx-sdk 11.0## https://bugzilla.mozilla.org/show_bug.cgi?id=1734331
Not a security issue for of an FYI, but it seems like we will also need to upgrade to the 11.0 sdk for macOS arm builds## https://bugzilla.mozilla.org/show_bug.cgi?id=1734331
Not a security issue for of an FYI, but it seems like we will also need to upgrade to the 11.0 sdk for macOS arm buildsSponsor 131 - Phase 3 - Major ESR 102 Migrationboklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40612Migrate Release Prep template to Release Prep - Stable2022-08-19T17:46:24ZrichardMigrate Release Prep template to Release Prep - StableAfter #40607 is merged we should update the existing template and migrate it to `Release Prep - Stable` and purge the various 'if stable vs if alpha' logic from it.After #40607 is merged we should update the existing template and migrate it to `Release Prep - Stable` and purge the various 'if stable vs if alpha' logic from it.richardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40611Audit license and copyright info2023-08-25T23:13:34ZrichardAudit license and copyright infoHTTPS-Everywhere has been removed from Desktop, so we should stop including their copyright and any licensing information we have bundled. We also need to update the base-browser target to not include unneeded licensing (tor, PTs, etc)HTTPS-Everywhere has been removed from Desktop, so we should stop including their copyright and any licensing information we have bundled. We also need to update the base-browser target to not include unneeded licensing (tor, PTs, etc)Sponsor 131 - Phase 3 - Major ESR 102 Migration