tor-browser-build issueshttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues2023-01-05T12:37:45Zhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40544Bump Java 8 version to something more recent2023-01-05T12:37:45ZGeorg KoppenBump Java 8 version to something more recentWe take the currently used Java 8 version from a snapshot from 2019. That's pretty old and missing a bunch of security fixes. We should pick up a newer version.We take the currently used Java 8 version from a snapshot from 2019. That's pretty old and missing a bunch of security fixes. We should pick up a newer version.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40543Move reproducible builds documentation into a modularized world2022-12-22T15:49:06ZGeorg KoppenMove reproducible builds documentation into a modularized worldFor lack of a better component I am filing a ticket here for now: where do we document the whole new setup now that tor-browser-build becomes just a project among others? There will be tor-browser-build related documentation changes, sur...For lack of a better component I am filing a ticket here for now: where do we document the whole new setup now that tor-browser-build becomes just a project among others? There will be tor-browser-build related documentation changes, sure. But we'd benefit from a general outline for someone who wanted to get started and use rbm for their project in a modularized world. While I like the idea of having "Reproducible builds at Tor", say, on a wiki page in /applications/team it might not be the right place for that general part.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40542Split up rbm.conf2023-08-26T06:05:20ZGeorg KoppenSplit up rbm.confThe options in `rbm.conf` are either `tor-browser-build` specific or should move to `rbm` or be module-dependent. We should go over them and split things out accordingly.The options in `rbm.conf` are either `tor-browser-build` specific or should move to `rbm` or be module-dependent. We should go over them and split things out accordingly.Sponsor 131 - Phase 5 - Ongoing Maintenanceboklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40541`about:buildconfig` is missing configure options2023-01-05T14:22:16ZGeorg Koppen`about:buildconfig` is missing configure optionsFor some reason we are missing some configure options in `about:buildconfig` when building Tor Browser. On Windows e.g. --disable-stylo and --disable-jemalloc. This got reported on the blog (https://blog.torproject.org/comment/276031#com...For some reason we are missing some configure options in `about:buildconfig` when building Tor Browser. On Windows e.g. --disable-stylo and --disable-jemalloc. This got reported on the blog (https://blog.torproject.org/comment/276031#comment-276031)https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40540Guard against failures during MAR file generation2023-01-05T14:22:07ZGeorg KoppenGuard against failures during MAR file generationWe tried to guard against errors during the MAR file generation by using `set -e` in the respective scripts but that is not working our particularly well as those scripts are using bash errors as features (see: legacy/trac#26216). We sho...We tried to guard against errors during the MAR file generation by using `set -e` in the respective scripts but that is not working our particularly well as those scripts are using bash errors as features (see: legacy/trac#26216). We should think about a better way to achieve what we want.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40539Investigate optimizing APK for Smart App Updating2022-06-23T19:57:53ZMatthew FinkelInvestigate optimizing APK for Smart App UpdatingIn mid-2012, beginning with Jelly Bean (4.1), Google Play began using Smart App Updates [0]
```
Smart App Updates
Smart app updates is a new feature of Google Play that introduces a better way
of delivering app updates to devices. When ...In mid-2012, beginning with Jelly Bean (4.1), Google Play began using Smart App Updates [0]
```
Smart App Updates
Smart app updates is a new feature of Google Play that introduces a better way
of delivering app updates to devices. When developers publish an update, Google
Play now delivers only the bits that have changed to devices, rather than the
entire APK. This makes the updates much lighter-weight in most cases, so they
are faster to download, save the device’s battery, and conserve bandwidth usage
on users’ mobile data plan. On average, a smart app update is about 1/3 the
size of a full APK update.
```
Considering Orfox is now ~30MB, and this may increase with additional locales, we should track the current diff patch size Google Play distributes for incremental updates, and we should investigate if we can tweak our APK so it provides minimal diffs.
Can we (nearly) reproduce their results?
StackOverflow suggests they are using GDIFF [1].
Google was nice enough to publish some more details (4 years later) about how they're now using a newer diff method in some situations [2]:
```
For approximately 98% of app updates from the Play Store, only changes (deltas)
to APK files are downloaded and merged with the existing files, reducing the
size of updates. Google Play has used delta algorithms since 2012, and we
recently rolled out an additional delta algorithm, bsdiff (created by Colin
Percival1), that our experimentation shows can reduce delta size by up to 50%
or more compared to the previous algorithm for some APKs. Bsdiff is
specifically targeted to produce more efficient deltas of native libraries by
taking advantage of the specific ways in which compiled native code changes
between versions. To be most effective, native libraries should be stored
uncompressed (compression interferes with delta algorithms).
```
Unfortunately, we are restricted by our user base and by which platforms Mozilla is targeting. At this point, Mozilla are still targeting SDK 16, which is good for us, but we don't get new optimizations:
```
However, please note, native libraries should only be uncompressed when the
minimum SDK version for an APK is 23 (Marshmallow) or later
```
So we should keep bsdiff optimizations in mind for when Mozilla eventually move to min-sdk 23+.
[0] https://developer.android.com/about/versions/jelly-bean.html
[1] https://stackoverflow.com/questions/12860938/smart-app-updates-on-google-play-store-how-does-it-work/12877791#12877791
[2] https://android-developers.googleblog.com/2016/07/improvements-for-smaller-app-downloads.htmlhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40536Look into fuzzing our tor-browser patches2023-01-05T14:21:59ZGeorg KoppenLook into fuzzing our tor-browser patchesAs part of Sponsor4 and our switch to have specific debug builds which allow us to detect bugs earlier we should look into fuzzing our browser patches.
Mozilla already does fuzzing and we might learn something from them. Also, some of t...As part of Sponsor4 and our switch to have specific debug builds which allow us to detect bugs earlier we should look into fuzzing our browser patches.
Mozilla already does fuzzing and we might learn something from them. Also, some of the things mentioned in https://blog.mozilla.org/security/2012/06/20/7-tips-for-fuzzing-firefox-more-effectively/ might be a good starting point, too.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40535macOS Sierra Finder complains that 'tor' isn't signed2022-08-02T14:23:46ZteormacOS Sierra Finder complains that 'tor' isn't signedI have a macOS user with permissions set to allow apps downloaded from 'App Store and identified developers'.
This user is also a 'Parental Controls' account, which means each executable is checked separately on open.
When I open Tor B...I have a macOS user with permissions set to allow apps downloaded from 'App Store and identified developers'.
This user is also a 'Parental Controls' account, which means each executable is checked separately on open.
When I open Tor Browser, I get a message saying that tor (which on macOS is a shell script) is not signed. This seems to go away after the app is approved via parental controls.
(There might not be anything we can do to fix this issue.)https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40534Prepare stable release 11.5.22022-08-30T16:26:11ZrichardPrepare stable release 11.5.2<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)`
- [x] Find the Firefox hg tag here : https://hg.mozilla.org/releases/mozilla-esr91/tags
- [x] `$(ESR_TAG)` : `FIREFOX_91_13_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 : tor-browser@d85bbabbb0375c44060349e3166c800cb4706a8f
- [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):
- [ ] 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 -
- [x] `git diff $(ESR_TAG_PREV)..$(TOR_BROWSER_BRANCH_PREV) > current_patchset.diff`
- [x] `git diff $(ESR_TAG)..$(TOR_BROWSER_BRANCH) > rebased_patchset.diff`
- [x] `$(DIFF_TOOL) current_patchset.dif rebased_patchset.deff`
- [x] Open MR for the rebase
- [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] 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)`
- [ ] 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
- [ ] 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
### **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
- [ ] 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://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
- [ ] Update `rbm.conf`
- [x] `var/torbrowser_version` : update to next version
- [x] `var/torbrowser_build` : update to `$(TOR_BROWSER_BUILD_N)`
- [x] `var/torbrowser_incremental_from` : update to previous 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
- [ ] ***(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
- [ ] ***(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
- [ ] ***(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
- [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)
- [ ] ***(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`
- [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
- [ ] Note any Rapid Release rebase
- [x] Link to any Firefox security updates
- [x] Note any updates to :
- [x] tor
- [ ] OpenSSL
- [x] go
- [x] 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
- [x] 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`
- [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`
- [x] release: `./deploy_update_responses-release.sh`
- [ ] ***(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
- [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/40533Prepare stable release 11.5.12022-07-26T20:17:03ZrichardPrepare stable release 11.5.1<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`
- `$(FIREFOX_BUILD_N)` : the firefox build revision within a given `tor-browser` branch; this is separate from the `$(TOR_BROWSER_BUILD_N) ` value
- example : `build1`
- `$(GECKOVIEW_BUILD_N)` : like `$(FIREFOX_BUILD_N)` but for geckoview branches
- `$(FENIX_BUILD_N)` : like `$(FIREFOX_BUILD_N)` but for fenix branches
- `$(TOR_BROWSER_BUILD_N)` : the tor-browser build revision for a given Tor Browser release; used in tagging git commits
- example : `build2`
- **NOTE** : `$(FIREFOX_BUILD_N)` and `$(TOR_BROWSER_BUILD_N)` typically are 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 `$(FIREFOX_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 `$(FIREFOX_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
- [ ] *(Optional)* Backport to maintenance branch if present
- [ ] 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
- [ ] Update `install.rdf` file with new version
- [ ] Sign/Tag commit :
- Tag : `$(TOR_LAUNCHER_VERSION)`
- Message `Tagging $(TOR_LAUNCHER_VERSION)`
- [ ] Push `master` and tag to origin
### tor-browser: https://git.torproject.org/tor-browser.git
- [x] ***(Optional)*** Rebase to `$(ESR_VERSION)`
- [x] Find the Firefox hg tag here : https://hg.mozilla.org/releases/mozilla-esr91/tags
- [x] `$(ESR_TAG)` : `FIREFOX_91_12_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 : tor-browser@4b4a2e0e61be073ef3ffebd64cc3d0983467cebb
- [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] Perform rangediff to ensure nothing weird happened resolving conflicts
- `git range-diff $(ESR_TAG_PREV)..$(TOR_BROWSER_BRANCH_PREV) $(ESR_TAG)..$(TOR_BROWSER_BRANCH)`
- [x] Open MR for the rebase
- [ ] ~~_TODO: tag base firefox no-tor browser_~~
- [ ] ***(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 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>Build/Signing/Publishing</summary>
### tor-browser-build: https://git.torproject.org/builders/tor-browser-build.git
Tor Browser Alpha (and Nightly) are on the `master` 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] `var/torbrowser_incremental_from` : update to previous 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 `$(FIREFOX_BUILD_N)` section to match `tor-browser` tag
- [x] ***(Optional)*** `var/firefox_platform_version` : update to latest $(ESR_VERSION) if rebased
- [x] Check for NoScript updates here : https://addons.mozilla.org/en-US/firefox/addon/noscript
- [ ] ***(Optional)*** If 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)*** If new tor version is available, update `projects/tor/config`
- [ ] `version` : update to next release tag
- [x] Check for go updates here : https://golang.org/dl (Tor Browser Alpha uses the latest Stable go version, while Tor Browser Stable uses the latest of the previous Stable major series version (eg: if Tor Browser Alpha is on the go1.17 series, Tor Browser Stable is on the go1.16 series)
- [x] ***(Optional)*** If new go version is available, 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] 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)`
- [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)`
- [x] 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
- [ ] Note any Rapid Release rebase
- [ ] Link to any Firefox security updates
- [x] Note any updates to :
- [ ] tor
- [ ] 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
### 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
### signing + publishing
- [x] Ensure builders have matching builds
- [x] 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] run do-all-signing script:
- `cd tor-browser-build/tools/signing/`
- `./do-all-signing.sh`
- **NOTE**: at this point the signed desktop 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`
- [x] Enable update responses :
- [ ] alpha: `./deploy_update_responses-alpha.sh`
- [x] release: `./deploy_update_responses-release.sh`
### tor-announce mailing list
- [x] ***(Stable release only)*** : 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>Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40532Prepare stable release 11.0.15 (Desktop+Android)2022-07-05T18:45:26ZrichardPrepare stable release 11.0.15 (Desktop+Android)<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`
- `$(FIREFOX_BUILD_N)` : the firefox build revision within a given `tor-browser` branch; this is separate from the `$(TOR_BROWSER_BUILD_N) ` value
- example : `build1`
- `$(GECKOVIEW_BUILD_N)` : like `$(FIREFOX_BUILD_N)` but for geckoview branches
- `$(FENIX_BUILD_N)` : like `$(FIREFOX_BUILD_N)` but for fenix branches
- `$(TOR_BROWSER_BUILD_N)` : the tor-browser build revision for a given Tor Browser release; used in tagging git commits
- example : `build2`
- **NOTE** : `$(FIREFOX_BUILD_N)` and `$(TOR_BROWSER_BUILD_N)` typically are 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 `$(FIREFOX_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 `$(FIREFOX_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
- [ ] *(Optional)* Backport to maintenance branch if present
- [ ] 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
- [ ] Update `install.rdf` file with new version
- [ ] Sign/Tag commit :
- Tag : `$(TOR_LAUNCHER_VERSION)`
- Message `Tagging $(TOR_LAUNCHER_VERSION)`
- [ ] Push `master` 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
- [ ] Perform rangediff to ensure nothing weird happened resolving conflicts
- `git range-diff $(ESR_TAG_PREV)..$(TOR_BROWSER_BRANCH_PREV) $(ESR_TAG)..$(TOR_BROWSER_BRANCH)`
- [ ] Open MR for the rebase
- [ ] _TODO: tag base firefox no-tor browser_
- [ ] ***(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 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
- [ ] Perform rangediff to ensure nothing weird happened resolving conflicts
- `git range-diff $(RR_TAG_PREV)..$(GECKOVIEW_BRANCH_PREV) $(RR_TAG)..$(GECKOVIEW_BRANCH)`
- [ ] 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 : `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
- Seem to be in the form `v$(RR_VERSION)` (for example, `v99.0.3`)
- [ ] 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
### **tor-android-service** ***(Optional)***: https://git.torproject.org/tor-android-service.git
- [ ] Fetch latest and identify new HEAD of `master` branch
- [ ] `origin/master` : `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
- [ ] ***(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://git.torproject.org/builders/tor-browser-build.git
Tor Browser Alpha (and Nightly) are on the `master` 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
- [ ] `var/torbrowser_build` : update to `$(TOR_BROWSER_BUILD_N)`
- [x] `var/torbrowser_incremental_from` : update to previous version
- [x] **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 `$(FIREFOX_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 `$(GECKOVIEW_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 `master` branch
- [ ] ***(Android Only, Optionl)*** Update `projects/fenix/config`
- [ ] `git_hash` : update the `$(FENIX_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 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
- [x] ***(Optional)*** If new tor version is available, update `projects/tor/config`
- [x] `version` : update to next release tag
- [x] Check for go updates here : https://golang.org/dl (Tor Browser Alpha uses the latest Stable go version, while Tor Browser Stable uses the latest of the previous Stable major series version (eg: if Tor Browser Alpha is on the go1.17 series, Tor Browser Stable is on the go1.16 series)
- [ ] ***(Optional)*** If new go version is available, 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] 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)`
- [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
- [ ] 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
- [ ] Convert ChangeLog.txt to markdown format used here by : `tor-browser-build/tools/changelog-format-blog-post`
- [ ] Push to origin as new branch, open 'Draft :' MR
- [ ] Remove draft from MR once signed-packages are uploaded
- [ ] Merge
### 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
### 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)*** : *TODO*
- [x] run do-all-signing script:
- `cd tor-browser-build/tools/signing/`
- `./do-all-signing.sh`
- **NOTE**: at this point the signed desktop 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`
- [x] Enable update responses :
- [ ] alpha: `./deploy_update_responses-alpha.sh`
- [x] release: `./deploy_update_responses-release.sh`
- [x] ***(Android Only)*** : Publish APKs to Google Play
- [ ] Log into https://play.google.com/apps/publish
- Select correct app:
- [ ] Tor Browser
- [x] 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
- [x] Save, review, and configure rollout percentage
- [x] 25% rollout when publishing a scheduled update
- [ ] 100% rollout when publishing a security-driven release
- [x] ***Optional*** Update rollout percentage to 100% after confirmed no major issues
### tor-announce mailing list
- [x] ***(Stable release only)*** : 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/40531Tor Browser requires D-Bus' /etc/machine-id on Arch Linux2023-01-05T14:21:15ZTracTor Browser requires D-Bus' /etc/machine-id on Arch LinuxHello Tor developers,
I have been playing with firejail to harden the Tor Browser on Arch Linux. And I've noticed, that when creating a private /etc folder with only the minimal required files, the file /etc/machine-id is necessary or t...Hello Tor developers,
I have been playing with firejail to harden the Tor Browser on Arch Linux. And I've noticed, that when creating a private /etc folder with only the minimal required files, the file /etc/machine-id is necessary or the Firefox in Tor Browser will segfault.
http://0pointer.de/public/systemd-man/machine-id.html
> The machine ID is usually generated from a random source during system installation and stays constant for all subsequent boots.
This could be a potential issue, when tor browser gets exploited and someone can uniquely identify the host machine with that ID.
Maybe it would be feasible to build Firefox without the D-Bus dependency on Linux to solve this?
Related firejail ticket:
https://github.com/netblue30/firejail/issues/955
Thanks for making Tor!
**Trac**:
**Username**: robotanarchyhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40530Translations update needed in torbutton2022-08-02T13:05:29ZboklmTranslations update needed in torbuttonIn the latest nightly Tor Browser in french, the `about:tor` page shows this error:
```
Erreur d’analyse XML : entité non définie
Emplacement : jar:file:///home/user/nightly/tor-browser_fr/Browser/omni.ja!/chrome/torbutton/content/about...In the latest nightly Tor Browser in french, the `about:tor` page shows this error:
```
Erreur d’analyse XML : entité non définie
Emplacement : jar:file:///home/user/nightly/tor-browser_fr/Browser/omni.ja!/chrome/torbutton/content/aboutTor/aboutTor.xhtml
Numéro de ligne 39, Colonne 31 :
<div class="heading1">&aboutTor.nightly.ready.label;</div>
------------------------------^
```
So it looks like some translations update is needed.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40529Update the Noto fonts2022-07-07T13:07:39ZPier Angelo VendrameUpdate the Noto fontsIn tor-browser#30589 we found a list of fonts that we'd need to support more scripts in Windows's TBB, plus 1 for Linux, and possibly serif fonts in both the platforms (for serif, I'd need to coordinate with l10n team, and see what's the...In tor-browser#30589 we found a list of fonts that we'd need to support more scripts in Windows's TBB, plus 1 for Linux, and possibly serif fonts in both the platforms (for serif, I'd need to coordinate with l10n team, and see what's the increase on the installer size).
In addition to that, I'd like to switch to hinted fonts (as recommended by Google in the readme).
But we have a problem: we are using an old version of Noto fonts, which doesn't contain all the fonts we'd like to use.
After #40186, we started downloading a zip with Noto fonts from GitHub.
I fear we'll have to roll this patch back: the produced archive is still much lighter than the whole git repository... but all the downloads I've done were corrupted eventually (and their hash changed).
I don't know whether this is a problem of my connection, or GitHub's problem.
Cloning with `--depth=1` may help:
```
git clone --depth 1 https://github.com/googlefonts/noto-fonts.git
Cloning into 'noto-fonts'...
remote: Enumerating objects: 13781, done.
remote: Counting objects: 100% (13781/13781), done.
remote: Compressing objects: 100% (9583/9583), done.
remote: Total 13781 (delta 6512), reused 8069 (delta 4186), pack-reused 0
Receiving objects: 100% (13781/13781), 656.28 MiB | 6.13 MiB/s, done.
Resolving deltas: 100% (6512/6512), done.
Updating files: 100% (13004/13004), done.
du -hs noto-fonts
2,6G noto-fonts
```
Which is still less than the 6GB.
However, this was `HEAD`, but according to this [StackOverflow answer](https://stackoverflow.com/questions/31278902/how-to-shallow-clone-a-specific-commit-with-depth-1), there is a trick to do also with other commits.
I don't know if RBM supports it, though.
The other alternatives I see are:
* downloading the fonts using GitHub's raw link (and bundle a list of known `sha256sum`s for that commit - but this possibly needs to be an online container)
* prepare a package and host it somewhere (it could be either a `git archive` output, or a package already filtered to contain only the fonts we want. From what I understood, generally we'd prefer to avoid that, and it's increased work for updates)
* look for other packages, hosted for example on Google fonts
* switch back to unhinted fonts, and download only the fonts that are missing from the zipPier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40528Make Tor Browser work with AppLocker2023-08-29T14:05:37ZGeorg KoppenMake Tor Browser work with AppLockerThere is a Windows mechanism to lock down access to applications, called AppLocker, and Tor Browser is not compatible with some ways of managing access. We need to think about what kind of rule compatibility we want to support:
There ar...There is a Windows mechanism to lock down access to applications, called AppLocker, and Tor Browser is not compatible with some ways of managing access. We need to think about what kind of rule compatibility we want to support:
There are
publisher based rules
path based rules
filehash based rules
and
default rules one can choose
(https://technet.microsoft.com/en-us/library/dd759068.aspx)https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40527Remove https-everywhere from tor-browser alpha desktop2022-06-21T15:17:07ZrichardRemove https-everywhere from tor-browser alpha desktopWith https-only mode enabled ( tor-browser#19850 ) and the new built-in onion aliases feature ( tor-browser#40458 ) we no longer need https-everywhere in tor-browser desktop!
So, we should remove it from our build.With https-only mode enabled ( tor-browser#19850 ) and the new built-in onion aliases feature ( tor-browser#40458 ) we no longer need https-everywhere in tor-browser desktop!
So, we should remove it from our build.richardrichardhttps://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/applications/tor-browser-build/-/issues/40525Update the mozconfig for tor-browser-91.9-11.5-22022-06-10T17:37:11ZPier Angelo VendrameUpdate the mozconfig for tor-browser-91.9-11.5-2We've added some important options that we must add to the mozconfig.
See tor-browser#40917.We've added some important options that we must add to the mozconfig.
See tor-browser#40917.Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40524Error: android-components-99.0.3-11.5-1-build2 is not a signed tag2022-06-11T07:49:06ZboklmError: android-components-99.0.3-11.5-1-build2 is not a signed tagAfter #40516 we have an error when building `android-components`:
```
Error: android-components-99.0.3-11.5-1-build2 is not a signed tag
```
I think we should tag a `-build3` with an other key.
/cc @pierov @richardAfter #40516 we have an error when building `android-components`:
```
Error: android-components-99.0.3-11.5-1-build2 is not a signed tag
```
I think we should tag a `-build3` with an other key.
/cc @pierov @richardhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40523Resume sending emails to tor-announce for Tor Browser stable releases2022-06-10T16:21:29ZboklmResume sending emails to tor-announce for Tor Browser stable releasesIn the past we used to send emails to the tor-announce mailing list for Tor Browser stable releases, but we stopped at some point. Yesterday some people were saying in the #tor irc channel that they are missing those emails.
@richard: i...In the past we used to send emails to the tor-announce mailing list for Tor Browser stable releases, but we stopped at some point. Yesterday some people were saying in the #tor irc channel that they are missing those emails.
@richard: if you are not already, you may need to be added to the list of allowed senders on that mailing list.