tor-browser-build issueshttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues2023-01-05T12:42:49Zhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/25863Check where the -mwindows flag is needed2023-01-05T12:42:49ZboklmCheck where the -mwindows flag is neededCurrently we are setting the `-mwindows` flag by default in `CFLAGS` and `LDFLAGS` defined in `rbm.conf`, which are currently used (through `var/configure_opt`) in tor, gmp, libevent and go.
We should check where this flag is really nee...Currently we are setting the `-mwindows` flag by default in `CFLAGS` and `LDFLAGS` defined in `rbm.conf`, which are currently used (through `var/configure_opt`) in tor, gmp, libevent and go.
We should check where this flag is really needed, and only set it there.Sponsor 131 - Phase 5 - Ongoing Maintenancehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41114Prepare Mullvad Browser Alpha 13.5a72024-03-27T16:52:24ZrichardPrepare Mullvad Browser Alpha 13.5a7<details>
<summary>Explanation of variables</summary>
- `$(BUILD_SERVER)` : the server the main builder is using to build a mullvad-browser release
- `$(BUILDER)` : whomever is building the release on the $(BUILD_SERVER)
- **example...<details>
<summary>Explanation of variables</summary>
- `$(BUILD_SERVER)` : the server the main builder is using to build a mullvad-browser release
- `$(BUILDER)` : whomever is building the release on the $(BUILD_SERVER)
- **example** : `pierov`
- `$(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 mullvad-browser tags, labels, etc
- **example** : `91.6.0`
- `$(MULLVAD_BROWSER_MAJOR)` : the Mullvad Browser major version
- **example** : `11`
- `$(MULLVAD_BROWSER_MINOR)` : the Mullvad Browser minor version
- **example** : either `0` or `5`; Alpha's is always `(Stable + 5) % 10`
- `$(MULLVAD_BROWSER_VERSION)` : the Mullvad Browser version in the format
- **example** : `12.5a3`, `12.0.3`
- `$(BUILD_N)` : a project's build revision within a its branch; this is separate from the `$(MULLVAD_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`
- `$(MULLVAD_BROWSER_BUILD_N)` : the mullvad-browser build revision for a given Mullvad Browser release; used in tagging git commits
- **example** : `build2`
- **NOTE** : A project's `$(BUILD_N)` and `$(MULLVAD_BROWSER_BUILD_N)` may be the same, but it is possible for them to diverge. For **example** :
- if we have multiple Mullvad Browser releases on a given ESR branch the two will become out of sync as the `$(BUILD_N)` value will increase, while the `$(MULLVAD_BROWSER_BUILD_N)` value may stay at `build1` (but the `$(MULLVAD_BROWSER_VERSION)` will increase)
- if we have build failures unrelated to `mullvad-browser`, the `$(MULLVAD_BROWSER_BUILD_N)` value will increase while the `$(BUILD_N)` will stay the same.
- `$(MULLVAD_BROWSER_VERSION)` : the published Mullvad Browser version
- **example** : `11.5a6`, `11.0.7`
- `$(MB_BUILD_TAG)` : the `tor-browser-build` build tag used to build a given Mullvad Browser version
- **example** : `mb-12.0.7-build1`
</details>
**NOTE** It is assumed that the `tor-browser` alpha rebase and security backport tasks have been completed
**NOTE** This can/is often done in conjunction with the equivalent Tor Browser release prep issue
<details>
<summary>Building</summary>
### tor-browser-build: https://gitlab.torproject.org/tpo/applications/tor-browser-build.git
Mullvad Browser Alpha (and Nightly) are on the `main` branch
- [ ] Update `rbm.conf`
- [ ] `var/torbrowser_version` : update to next version
- [ ] `var/torbrowser_build` : update to `$(MULLVAD_BROWSER_BUILD_N)`
- [ ] `var/torbrowser_incremental_from` : update to previous Desktop version
- **NOTE**: We try to build incrementals for the previous 3 desktop versions except in the case of a watershed update
- **IMPORTANT**: Really *actually* make sure this is the previous Desktop version or else the `make mullvadbrowser-incrementals-*` step will fail
- [ ] Update build configs
- [ ] Update `projects/firefox/config`
- [ ] `browser_build` : update to match `mullvad-browser` tag
- [ ] ***(Optional)*** `var/firefox_platform_version` : update to latest `$(ESR_VERSION)` if rebased
- [ ] Update `projects/translation/config`:
- [ ] run `make list_translation_updates-alpha` to get updated hashes
- [ ] `steps/base-browser/git_hash` : update with `HEAD` commit of project's `base-browser` branch
- [ ] `steps/mullvad-browser/git_hash` : update with `HEAD` commit of project's `mullvad-browser` branch
- [ ] Update common build configs
- [ ] 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`
- [ ] Check for uBlock-origin updates here : https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/
- [ ] ***(Optional)*** If new version available, update `ublock-origin` section of `input_files` in `projects/browser/config`
- [ ] `URL`
- [ ] `sha256sum`
- [ ] Check for Mullvad Browser Extension updates here : https://github.com/mullvad/browser-extension/releases
- [ ] ***(Optional)*** If new version available, update `mullvad-extension` section of `input_files` in `projects/browser/config`
- [ ] `URL`
- [ ] `sha256sum`
- [ ] Update `ChangeLog-MB.txt`
- [ ] Ensure `ChangeLog-MB.txt` is sync'd between alpha and stable branches
- [ ] Check the linked issues: ask people to check if any are missing, remove the not fixed ones
- [ ] Run `./tools/fetch-changelogs.py $(ISSUE_NUMBER) --date $date $updateArgs`
- Make sure you have `requests` installed (e.g., `apt install python3-requests`)
- The first time you run this script you will need to generate an access token; the script will guide you
- `$updateArgs` should be these arguments, depending on what you actually updated:
- [ ] `--firefox` (be sure to include esr at the end if needed, which is usually the case)
- [ ] `--no-script`
- [ ] `--ublock`
- E.g., `./tools/fetch-changelogs.py 41029 --date 'December 19 2023' --firefox 115.6.0esr --no-script 11.4.29 --ublock 1.54.0`
- `--date $date` is optional, if omitted it will be the date on which you run the command
- [ ] Copy the output of the script to the beginning of `ChangeLog-MB.txt` and adjust its output
- [ ] Open MR with above changes, using the template for release preparations
- [ ] Merge
- [ ] Sign+Tag
- **NOTE** this must be done by one of:
- boklm
- dan
- ma1
- pierov
- richard
- [ ] Run: `make mullvadbrowser-signtag-alpha`
- [ ] Push tag to `upstream`
- [ ] Build the tag:
- Run `make mullvadbrowser-alpha && make mullvadbrowser-incrementals-alpha` on:
- [ ] Tor Project build machine
- [ ] Local developer machine
- [ ] Submit build request to Mullvad infrastructure:
- **NOTE** this requires a devmole authentication token
- Run `make mullvadbrowser-kick-devmole-build`
- [ ] Ensure builders have matching builds
</details>
<details>
<summary>Signing</summary>
### release signing
- [ ] Assign this issue to the signer, one of:
- boklm
- richard
- [ ] On `$(STAGING_SERVER)`, ensure updated:
- [ ] `tor-browser-build` is on the right commit: `git tag -v tbb-$(MULLVAD_BROWSER_VERSION)-$(MULLVAD_BROWSER_BUILD_N) && git checkout tbb-$(MULLVAD_BROWSER_VERSION)-$(MULLVAD_BROWSER_BUILD_N)`
- [ ] `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
- [ ] `tor-browser-build/tools/signing/set-config.rcodesign-appstoreconnect`
- `appstoreconnect_api_key_path` : path to json file containing appstoreconnect api key infos
- [ ] `set-config.update-responses`
- `update_responses_repository_dir` : directory where you cloned `git@gitlab.torproject.org:tpo/applications/mullvad-browser-update-responses.git`
- [ ] `tor-browser-build/tools/signing/set-config.tbb-version`
- `tbb_version` : mullvad 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, ensure tor daemon is running with SOCKS5 proxy on the default port 9050
- [ ] On `$(STAGING_SERVER)` in a separate `screen` session, run do-all-signing script:
- `cd tor-browser-build/tools/signing/`
- `./do-all-signing.mullvadbrowser`
- **NOTE**: at this point the signed binaries should have been copied to `staticiforme`
- [ ] Update `staticiforme.torproject.org`:
- From `screen` session on `staticiforme.torproject.org`:
- [ ] Remove old release data from `/srv/dist-master.torproject.org/htdocs/mullvadbrowser`
- [ ] Static update components (again) : `static-update-component dist.torproject.org`
</details>
<details>
<summary>Publishing</summary>
### mullvad-browser (GitHub): https://github.com/mullvad/mullvad-browser/
- [ ] Assign this issue to someone with mullvad commit access, one of:
- richard
- [ ] Push this release's associated `mullvad-browser.git` branch to github
- [ ] Push this release's associated tags to github:
- [ ] Firefox ESR tag
- **example** : `FIREFOX_102_12_0esr_BUILD1`
- [ ] `base-browser` tag
- **example** : `base-browser-102.12.0esr-12.0-1-build1`
- [ ] `mullvad-browser` tag
- **example** : `mullvad-browser-102.12.0esr-12.0-1-build1`
- [ ] Sign+Tag additionally the `mullvad-browser.git` `firefox` commit used in build:
- **Tag**: `$(MULLVAD_BROWSER_VERSION)`
- **example** : `12.5a7`
- **Message**: `$(ESR_VERSION)esr-based $(MULLVAD_BROWSER_VERSION)`
- **example** : `102.12.0esr-based 12.5a7`
- [ ] Push tag to github
### email
- [ ] **(Once branch+tags pushed to GitHub)** Email Mullvad with release information:
- [ ] support alias: support@mullvadvpn.net
- [ ] Rui: rui@mullvad.net
- **Subject**
```
New build: Mullvad Browser $(MULLVAD_BROWSER_VERION) (signed)
```
- **Body**
```
Hello,
Branch+Tags have been pushed to Mullvad's GitHub repo.
- signed builds: https://dist.torproject.org/mullvadbrowser/$(MULLVAD_BROWSER_VERSION)
- update_response hashes: $(MULLVAD_UPDATE_RESPONSES_HASH)
changelog:
...
```
</details>
<details>
<summary>Downstream</summary>
### notify packagers
These steps depend on Mullvad having updated their [GitHub Releases](https://github.com/mullvad/mullvad-browser/releases/) page with the latest release
- [ ] **(Optional)** Email downstream consumers:
- **NOTE**: This is an optional step and only necessary close a major release/transition from alpha to stable, or if there are major packing changes these developers need to be aware of
- [ ] flathub package maintainer: proletarius101@protonmail.com
- [ ] arch package maintainer: bootctl@gmail.com
- [ ] nixOS package maintainer: dev@felschr.com
- **Subject**
```
Mullvad Browser $(MULLVAD_BROWSER_VERSION) released
```
- **Body**
```
Hello!
This is a major alpha release which may require changes in your respective downstream packages once it stabilises.
The latest alpha builds can be found here:
- https://github.com/mullvad/mullvad-browser/releases?q=prerelease%3Atrue
```
</details>https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41113Prepare Tor Browser Alpha 13.5a72024-03-27T16:51:41ZrichardPrepare Tor Browser Alpha 13.5a7<details>
<summary>Explanation of variables</summary>
- `$(BUILD_SERVER)` : the server the main builder is using to build a tor-browser release
- `$(BUILDER)` : whomever is building the release on the $(BUILD_SERVER)
- **example** :...<details>
<summary>Explanation of variables</summary>
- `$(BUILD_SERVER)` : the server the main builder is using to build a tor-browser release
- `$(BUILDER)` : whomever is building the release on the $(BUILD_SERVER)
- **example** : `pierov`
- `$(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`
- `$(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`
- `$(TOR_BROWSER_VERSION)` : the Tor Browser version in the format
- **example** : `12.5a3`, `12.0.3`
- `$(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`
- `$(TBB_BUILD_TAG)` : the `tor-browser-build` build tag used to build a given Tor Browser version
- **example** : `tbb-12.5a7-build1`
</details>
**NOTE** It is assumed that the `tor-browser` stable rebase and security backport tasks have been completed
**NOTE** This can/is often done in conjunction with the equivalent Mullvad Browser release prep issue
<details>
<summary>Building</summary>
### tor-browser-build: https://gitlab.torproject.org/tpo/applications/tor-browser-build.git
Tor Browser Alpha (and Nightly) are on the `main` branch
- [ ] Update `rbm.conf`
- [ ] `var/torbrowser_version` : update to next version
- [ ] `var/torbrowser_build` : update to `$(TOR_BROWSER_BUILD_N)`
- [ ] ***(Desktop Only)***`var/torbrowser_incremental_from` : update to previous Desktop version
- **NOTE**: We try to build incrementals for the previous 3 desktop versions except in the case of a watershed update
- **IMPORTANT**: Really *actually* make sure this is the previous Desktop version or else the `make torbrowser-incrementals-*` step will fail
- [ ] Update Desktop-specific build configs
- [ ] Update `projects/firefox/config`
- [ ] `browser_build` : update to match `tor-browser` tag
- [ ] ***(Optional)*** `var/firefox_platform_version` : update to latest `$(ESR_VERSION)` if rebased
- [ ] Update Android-specific build configs
- [ ] Update `projects/geckoview/config`
- [ ] `browser_build` : update to match `tor-browser` tag
- [ ] ***(Optional)*** `var/geckoview_version` : update to latest `$(ESR_VERSION)` if rebased
- [ ] ***(Optional)*** Update `projects/tor-android-service/config`
- [ ] `git_hash` : update with `HEAD` commit of project's `main` branch
- [ ] ***(Optional)*** Update `projects/application-services/config`:
**NOTE** we don't currently have any of our own patches for this project
- [ ] `git_hash` : update to appropriate git commit associated with `$(ESR_VERSION)`
- [ ] ***(Optional)*** Update `projects/firefox-android/config`:
- [ ] `fenix_version` : update to match alpha `firefox-android` build tag
- [ ] `browser_branch` : update to match alpha `firefox-android` build tag
- [ ] `browser_build` : update to match alpha `firefox-android` build tag
- [ ] Update allowed_addons.json by running (from `tor-browser-build` root):
- `./tools/fetch_allowed_addons.py > projects/browser/allowed_addons.json`
- [ ] Update `projects/translation/config`:
- [ ] run `make list_translation_updates-alpha` to get updated hashes
- [ ] `steps/base-browser/git_hash` : update with `HEAD` commit of project's `base-browser` branch
- [ ] `steps/tor-browser/git_hash` : update with `HEAD` commit of project's `tor-browser` branch
- [ ] `steps/fenix/git_hash` : update with `HEAD` commit of project's `fenix-torbrowserstringsxml` branch
- [ ] Update common build configs
- [ ] 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`
- [ ] Check for OpenSSL updates here : https://www.openssl.org/source/
- [ ] ***(Optional)*** If new 3.0.X version available, update `projects/openssl/config`
- [ ] `version` : update to next 3.0.X version
- [ ] `input_files/sha256sum` : update to sha256 sum of source tarball
- [ ] Check for zlib updates here: https://github.com/madler/zlib/releases
- [ ] **(Optional)** If new tag available, update `projects/zlib/config`
- [ ] `version` : update to next release tag
- [ ] Check for tor updates here : https://gitlab.torproject.org/tpo/core/tor/-/tags
- [ ] ***(Optional)*** Update `projects/tor/config`
- [ ] `version` : update to latest `-alpha` tag or release tag if newer (ping dgoulet or ahf if unsure)
- [ ] Check for go updates here : https://go.dev/dl
- **NOTE** : In general, Tor Browser Alpha uses the latest Stable major series Go version, but there are sometimes exceptions. Check with the anti-censorship team before doing a major version update in case there is incompatibilities.
- [ ] ***(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)
- [ ] Check for manual updates by running (from `tor-browser-build` root): `./tools/fetch-manual.py`
- [ ] ***(Optional)*** If new version is available:
- [ ] Upload the downloaded `manual_$PIPELINEID.zip` file to `tb-build-02.torproject.org`
- [ ] Deploy to `tb-builder`'s `public_html` directory:
- `sudo -u tb-builder cp manual_$PIPELINEID.zip ~tb-builder/public_html/.`
- [ ] Update `projects/manual/config`:
- [ ] Change the `version` to `$PIPELINEID`
- [ ] Update `sha256sum` in the `input_files` section
- [ ] Update `ChangeLog-TBB.txt`
- [ ] Ensure `ChangeLog-TBB.txt` is sync'd between alpha and stable branches
- [ ] Check the linked issues: ask people to check if any are missing, remove the not fixed ones
- [ ] Run `./tools/fetch-changelogs.py $(ISSUE_NUMBER) --date $date $updateArgs`
- Make sure you have `requests` installed (e.g., `apt install python3-requests`)
- The first time you run this script you will need to generate an access token; the script will guide you
- `$updateArgs` should be these arguments, depending on what you actually updated:
- [ ] `--firefox` (be sure to include esr at the end if needed, which is usually the case)
- [ ] `--tor`
- [ ] `--no-script`
- [ ] `--openssl`
- [ ] `--zlib`
- [ ] `--go`
- E.g., `./tools/fetch-changelogs.py 41028 --date 'December 19 2023' --firefox 115.6.0esr --tor 0.4.8.10 --no-script 11.4.29 --zlib 1.3 --go 1.21.5 --openssl 3.0.12`
- `--date $date` is optional, if omitted it will be the date on which you run the command
- [ ] Copy the output of the script to the beginning of `ChangeLog-TBB.txt` and adjust its output
- [ ] Open MR with above changes, using the template for release preparations
- [ ] Merge
- [ ] Sign+Tag
- **NOTE** this must be done by one of:
- boklm
- dan
- ma1
- pierov
- richard
- [ ] Run: `make torbrowser-signtag-alpha`
- [ ] Push tag to `upstream`
- [ ] Build the tag:
- Run `make torbrowser-alpha && make torbrowser-incrementals-alpha`
- [ ] Tor Project build machine
- [ ] Local developer machine
- [ ] Submit build request to Mullvad infrastructure:
- **NOTE** this requires a devmole authentication token
- Run `make torbrowser-kick-devmole-build`
- [ ] Ensure builders have matching builds
</details>
<details>
<summary>Communications</summary>
### notify stakeholders
- [ ] **(Once builds confirmed matching)** Email tor-qa mailing list with release information
- [ ] tor-qa: tor-qa@lists.torproject.org
- **Subject**
```
Tor Browser $(TOR_BROWSER_VERION) (Android, Windows, macOS, Linux)
```
- **Body**
```
Hello,
Unsigned Tor Browser $(TOR_BROWSER_VERSION) alpha candidate builds are now available for testing:
- https://tb-build-02.torproject.org/~$(BUILDER)/builds/torbrowser/alpha/unsigned/$(TOR_BROWSER_VERSION)/
The full changelog can be found here:
- https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/raw/$(TBB_BUILD_TAG)/projects/browser/Bundle-Data/Docs-TBB/ChangeLog.txt
```
- [ ] ***(Optional, only around build/packaging changes)*** Email packagers:
- [ ] Tails dev mailing list: tails-dev@boum.org
- [ ] Guardian Project: nathan@guardianproject.info
- [ ] FreeBSD port: freebsd@sysctl.cz <!-- Gitlab user maxfx -->
- [ ] OpenBSD port: caspar@schutijser.com <!-- Gitlab user cschutijser -->
- [ ] Note any changes which may affect packaging/downstream integration
- [ ] ***(Optional, after ESR migration)*** Email external partners:
- [ ] Cloudflare: ask-research@cloudflare.com
- **NOTE** : We need to provide them with updated user agent string so they can update their internal machinery to prevent Tor Browser users from getting so many CAPTCHAs
- [ ] Startpage: admin@startpage.com
- **NOTE** : Startpage also needs the updated user-agent string for better experience on their onion service sites.
</details>
<details>
<summary>Signing</summary>
### release signing
- **NOTE** : In practice, it's most efficient to have the blog post and website updates ready to merge, since signing doesn't take very long
- [ ] Assign this issue to the signer, one of:
- boklm
- richard
- [ ] On `$(STAGING_SERVER)`, ensure updated:
- [ ] `tor-browser-build` is on the right commit: `git tag -v tbb-$(TOR_BROWSER_VERSION)-$(TOR_BROWSER_BUILD_N) && git checkout tbb-$(TOR_BROWSER_VERSION)-$(TOR_BROWSER_BUILD_N)`
- [ ] `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
- [ ] `tor-browser-build/tools/signing/set-config.rcodesign-appstoreconnect`
- `appstoreconnect_api_key_path` : path to json file containing appstoreconnect api key infos
- [ ] `set-config.update-responses`
- `update_responses_repository_dir` : directory where you cloned `git@gitlab.torproject.org:tpo/applications/tor-browser-update-responses.git`
- [ ] `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, ensure tor daemon is running with SOCKS5 proxy on the default port 9050
- [ ] On `$(STAGING_SERVER)` in a separate `screen` session, run do-all-signing script:
- `cd tor-browser-build/tools/signing/`
- `./do-all-signing.torbrowser`
- **NOTE**: at this point the signed binaries should have been copied to `staticiforme`
- [ ] Update `staticiforme.torproject.org`:
- From `screen` session on `staticiforme.torproject.org`:
- [ ] Static update components : `static-update-component cdn.torproject.org && static-update-component dist.torproject.org`
- [ ] Enable update responses : `sudo -u tb-release ./deploy_update_responses-alpha.sh`
- [ ] Remove old release data from following places:
- **NOTE** : Skip this step if we need to hold on to older versions for some reason (for example, this is an Andoid or Desktop-only release, or if we need to hold back installers in favor of build-to-build updates if there are signing issues, etc)
- [ ] `/srv/cdn-master.torproject.org/htdocs/aus1/torbrowser`
- [ ] `/srv/dist-master.torproject.org/htdocs/torbrowser`
- [ ] Static update components (again) : `static-update-component cdn.torproject.org && static-update-component dist.torproject.org`
</details>
<details>
<summary>Signature verification</summary>
<details>
<summary>Check whether the .exe files got properly signed and timestamped</summary>
```bash
# Point OSSLSIGNCODE to your osslsigncode binary
pushd tor-browser-build/${channel}/signed/$TORBROWSER_VERSION
OSSLSIGNCODE=/path/to/osslsigncode
../../../tools/authenticode_check.sh
popd
```
</details>
<details>
<summary>Check whether the MAR files got properly signed</summary>
```bash
# Point NSSDB to your nssdb containing the mar signing certificate
# Point SIGNMAR to your signmar binary
# Point LD_LIBRARY_PATH to your mar-tools directory
pushd tor-browser-build/${channel}/signed/$TORBROWSER_VERSION
NSSDB=/path/to/nssdb
SIGNMAR=/path/to/mar-tools/signmar
LD_LIBRARY_PATH=/path/to/mar-tools/
../../../tools/marsigning_check.sh
popd
```
</details>
</details>
<details>
<summary>Publishing</summary>
### Google Play: https://play.google.com/apps/publish
- [ ] Publish APKs to Google Play:
- Select `Tor Browser (Alpha)` app
- Navigate to `Release > Production` and click `Create new release` button:
- Upload the `tor-browser-android-*.apk` APKs
- Update Release Name to Tor Browser version number
- Update Release Notes
- Next to 'Release notes', click `Copy from a previous release`
- Edit blog post url to point to most recent blog post
- Save, review, and configure rollout percentage
- [ ] 25% rollout when publishing a scheduled update
- [ ] 100% rollout when publishing a security-driven release
- [ ] Update rollout percentage to 100% after confirmed no major issues
### 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-alpha/version` : sort of a catch-all for latest stable version
- `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 accessible on https://dist.torproject.org
- [ ] Merge
- [ ] Publish after CI passes and builds are published
### blog: https://gitlab.torproject.org/tpo/web/blog.git
- [ ] Run `tools/signing/create-blog-post` which should create the new blog post from a template (edit set-config.blog to set you local blog directory)
- [ ] Note any ESR update
- [ ] Note any updates to dependencies (OpenSSL, zlib, NoScript, tor, etc)
- [ ] Thank any users which have contributed patches
- [ ] **(Optional)** Draft any additional sections for new features which need testing, known issues, etc
- [ ] Push to origin as new branch, open `Draft:` MR
- [ ] Merge once signed-packages are accessible on https://dist.torproject.org
- [ ] Publish after CI passes and website has been updated
### tor-announce mailing list
- [ ] Email tor-announce mailing list: tor-announce@lists.torproject.org
- **Subject**
```
New Release: Tor Browser $(TOR_BROWSER_VERSION) (Android, Windows, macOS, Linux)
```
- **Body**
```
Hi everyone,
Tor Browser $(TOR_BROWSER_VERSION) has now been published for all platforms. For details please see our blog post:
- $(BLOG_POST_URL)
Changelog:
# paste changleog as quote here
```
</details>https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41112Fix indentation of projects/browser/RelativeLink/start-browser2024-03-27T16:54:03ZboklmFix indentation of projects/browser/RelativeLink/start-browserThe file `projects/browser/RelativeLink/start-browser` is currently
indented with a mix of tabs, 8, 4 or 2 spaces.
I think we can change it to 2 spaces everywhere.The file `projects/browser/RelativeLink/start-browser` is currently
indented with a mix of tabs, 8, 4 or 2 spaces.
I think we can change it to 2 spaces everywhere.boklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41111Use Lyrebird to provide WebTunnel PT Client2024-03-27T16:51:06ZshelikhooUse Lyrebird to provide WebTunnel PT ClientA few weeks ago, the anti-censorship team have been made aware of an ongoing effort to reduce android apk size of distributed binaries. We purposed [integrating](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyre...A few weeks ago, the anti-censorship team have been made aware of an ongoing effort to reduce android apk size of distributed binaries. We purposed [integrating](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/40014) WebTunnel client into Lyrebird.
This change has been [completed](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/merge_requests/34), and once Tor browser bundle include this change, WebTunnel Client will no longer require shipping a separate binary and could thus have a reduced binary size.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41110Avoid Fontconfig warning about "ambiguous path"2024-03-27T08:15:02ZRusty BirdAvoid Fontconfig warning about "ambiguous path" $ ./start-tor-browser --verbose
Fontconfig warning: "/home/user/tor-browser/Browser/fontconfig/fonts.conf", line 42: Use of ambiguous path in <dir> element. please add prefix="cwd" if current behavior is desired.
I'll open a mer... $ ./start-tor-browser --verbose
Fontconfig warning: "/home/user/tor-browser/Browser/fontconfig/fonts.conf", line 42: Use of ambiguous path in <dir> element. please add prefix="cwd" if current behavior is desired.
I'll open a merge request that adds `prefix="cwd"`.Rusty BirdRusty Birdhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41106Non matching builds after application-services not being rebuilt in a long time2024-03-19T12:34:54ZboklmNon matching builds after application-services not being rebuilt in a long timeWhile building 13.0.12 we found that some android builds were not
matching. @PieroV found that this is due to application-services not
matching when the build date is very different.While building 13.0.12 we found that some android builds were not
matching. @PieroV found that this is due to application-services not
matching when the build date is very different.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41104Deduplicate projects/browser/ddmg.sh and tools/signing/ddmg.sh2024-03-12T17:47:46ZboklmDeduplicate projects/browser/ddmg.sh and tools/signing/ddmg.sh`projects/browser/ddmg.sh` and `tools/signing/ddmg.sh` are mostly the
same script, so we could try to deduplicate them.`projects/browser/ddmg.sh` and `tools/signing/ddmg.sh` are mostly the
same script, so we could try to deduplicate them.boklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41103Tor Browser 13.0.11 doesn't start on macOS in some cases2024-03-12T19:07:13ZPier Angelo VendrameTor Browser 13.0.11 doesn't start on macOS in some casesReported by some users and by @nina in #41020.
It seems Tor Browser installs as expected, but then it can't be launched.
She tested on a 14.3.1 (Sonoma) M1 Mac.
I tested on 10.15 x86, and it worked.Reported by some users and by @nina in #41020.
It seems Tor Browser installs as expected, but then it can't be launched.
She tested on a 14.3.1 (Sonoma) M1 Mac.
I tested on 10.15 x86, and it worked.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41100Prepare Mullvad Browser Stable 13.0.142024-03-26T17:44:27ZrichardPrepare Mullvad Browser Stable 13.0.14<details>
<summary>Explanation of variables</summary>
- `$(BUILD_SERVER)` : the server the main builder is using to build a mullvad-browser release
- `$(BUILDER)` : whomever is building the release on the $(BUILD_SERVER)
- **example...<details>
<summary>Explanation of variables</summary>
- `$(BUILD_SERVER)` : the server the main builder is using to build a mullvad-browser release
- `$(BUILDER)` : whomever is building the release on the $(BUILD_SERVER)
- **example** : `pierov`
- `$(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 mullvad-browser tags, labels, etc
- **example** : `91.6.0`
- `$(MULLVAD_BROWSER_MAJOR)` : the Mullvad Browser major version
- **example** : `11`
- `$(MULLVAD_BROWSER_MINOR)` : the Mullvad Browser minor version
- **example** : either `0` or `5`; Alpha's is always `(Stable + 5) % 10`
- `$(MULLVAD_BROWSER_VERSION)` : the Mullvad Browser version in the format
- **example** : `12.5a3`, `12.0.3`
- `$(BUILD_N)` : a project's build revision within a its branch; this is separate from the `$(MULLVAD_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`
- `$(MULLVAD_BROWSER_BUILD_N)` : the mullvad-browser build revision for a given Mullvad Browser release; used in tagging git commits
- **example** : `build2`
- **NOTE** : A project's `$(BUILD_N)` and `$(MULLVAD_BROWSER_BUILD_N)` may be the same, but it is possible for them to diverge. For **example** :
- if we have multiple Mullvad Browser releases on a given ESR branch the two will become out of sync as the `$(BUILD_N)` value will increase, while the `$(MULLVAD_BROWSER_BUILD_N)` value may stay at `build1` (but the `$(MULLVAD_BROWSER_VERSION)` will increase)
- if we have build failures unrelated to `mullvad-browser`, the `$(MULLVAD_BROWSER_BUILD_N)` value will increase while the `$(BUILD_N)` will stay the same.
- `$(MULLVAD_BROWSER_VERSION)` : the published Mullvad Browser version
- **example** : `11.5a6`, `11.0.7`
- `$(MB_BUILD_TAG)` : the `tor-browser-build` build tag used to build a given Mullvad Browser version
- **example** : `mb-12.0.7-build1`
</details>
**NOTE** It is assumed that the `tor-browser` stable rebase and security backport tasks have been completed
**NOTE** This can/is often done in conjunction with the equivalent Tor Browser release prep issue
<details>
<summary>Building</summary>
### tor-browser-build: https://gitlab.torproject.org/tpo/applications/tor-browser-build.git
Mullvad Browser Stable lives in the various `maint-$(MULLVAD_BROWSER_MAJOR).$(MULLVAD_BROWSER_MINOR)` (and possibly more specific) branches
- [ ] Update `rbm.conf`
- [ ] `var/torbrowser_version` : update to next version
- [ ] `var/torbrowser_build` : update to `$(MULLVAD_BROWSER_BUILD_N)`
- [ ] `var/torbrowser_incremental_from` : update to previous Desktop version
- **NOTE**: We try to build incrementals for the previous 3 desktop versions except in the case of a watershed update
- **IMPORTANT**: Really *actually* make sure this is the previous Desktop version or else the `make mullvadbrowser-incrementals-*` step will fail
- [ ] Update build configs
- [ ] Update `projects/firefox/config`
- [ ] `browser_build` : update to match `mullvad-browser` tag
- [ ] ***(Optional)*** `var/firefox_platform_version` : update to latest `$(ESR_VERSION)` if rebased
- [ ] Update `projects/translation/config`:
- [ ] run `make list_translation_updates-release` to get updated hashes
- [ ] `steps/base-browser/git_hash` : update with `HEAD` commit of project's `base-browser` branch
- [ ] `steps/mullvad-browser/git_hash` : update with `HEAD` commit of project's `mullvad-browser` branch
- [ ] Update common build configs
- [ ] 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`
- [ ] Check for uBlock-origin updates here : https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/
- [ ] ***(Optional)*** If new version available, update `ublock-origin` section of `input_files` in `projects/browser/config`
- [ ] `URL`
- [ ] `sha256sum`
- [ ] Check for Mullvad Browser Extension updates here : https://github.com/mullvad/browser-extension/releases
- [ ] ***(Optional)*** If new version available, update `mullvad-extension` section of `input_files` in `projects/browser/config`
- [ ] `URL`
- [ ] `sha256sum`
- [ ] Update `ChangeLog-MB.txt`
- [ ] Ensure `ChangeLog-MB.txt` is sync'd between alpha and stable branches
- [ ] Check the linked issues: ask people to check if any are missing, remove the not fixed ones
- [ ] Run `./tools/fetch-changelogs.py $(ISSUE_NUMBER) --date $date $updateArgs`
- Make sure you have `requests` installed (e.g., `apt install python3-requests`)
- The first time you run this script you will need to generate an access token; the script will guide you
- `$updateArgs` should be these arguments, depending on what you actually updated:
- [ ] `--firefox` (be sure to include esr at the end if needed, which is usually the case)
- [ ] `--no-script`
- [ ] `--ublock`
- E.g., `./tools/fetch-changelogs.py 41029 --date 'December 19 2023' --firefox 115.6.0esr --no-script 11.4.29 --ublock 1.54.0`
- `--date $date` is optional, if omitted it will be the date on which you run the command
- [ ] Copy the output of the script to the beginning of `ChangeLog-MB.txt` and adjust its output
- [ ] Open MR with above changes, using the template for release preparations
- [ ] Merge
- [ ] Sign+Tag
- **NOTE** this must be done by one of:
- boklm
- dan
- ma1
- pierov
- richard
- [ ] Run: `make mullvadbrowser-signtag-release`
- [ ] Push tag to `upstream`
- [ ] Build the tag:
- Run `make mullvadbrowser-release && make mullvadbrowser-incrementals-release`
- [ ] Tor Project build machine
- [ ] Local developer machine
- [ ] Submit build request to Mullvad infrastructure:
- **NOTE** this requires a devmole authentication token
- Run `make mullvadbrowser-kick-devmole-build`
- [ ] Ensure builders have matching builds
</details>
<details>
<summary>Signing</summary>
### release signing
- [ ] Assign this issue to the signer, one of:
- boklm
- richard
- [ ] On `$(STAGING_SERVER)`, ensure updated:
- [ ] `tor-browser-build` is on the right commit: `git tag -v tbb-$(MULLVAD_BROWSER_VERSION)-$(MULLVAD_BROWSER_BUILD_N) && git checkout tbb-$(MULLVAD_BROWSER_VERSION)-$(MULLVAD_BROWSER_BUILD_N)`
- [ ] `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
- [ ] `tor-browser-build/tools/signing/set-config.rcodesign-appstoreconnect`
- `appstoreconnect_api_key_path` : path to json file containing appstoreconnect api key infos
- [ ] `set-config.update-responses`
- `update_responses_repository_dir` : directory where you cloned `git@gitlab.torproject.org:tpo/applications/mullvad-browser-update-responses.git`
- [ ] `tor-browser-build/tools/signing/set-config.tbb-version`
- `tbb_version` : mullvad 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, ensure tor daemon is running with SOCKS5 proxy on the default port 9050
- [ ] On `$(STAGING_SERVER)` in a separate `screen` session, run do-all-signing script:
- `cd tor-browser-build/tools/signing/`
- `./do-all-signing.mullvadbrowser`
- **NOTE**: at this point the signed binaries should have been copied to `staticiforme`
- [ ] Update `staticiforme.torproject.org`:
- From `screen` session on `staticiforme.torproject.org`:
- [ ] Remove old release data from `/srv/dist-master.torproject.org/htdocs/mullvadbrowser`
- [ ] Static update components (again) : `static-update-component dist.torproject.org`
</details>
<details>
<summary>Publishing</summary>
### mullvad-browser (GitHub): https://github.com/mullvad/mullvad-browser/
- [ ] Assign this issue to someone with mullvad commit access, one of:
- richard
- [ ] Push this release's associated `mullvad-browser.git` branch to github
- [ ] Push this release's associated tags to github:
- [ ] Firefox ESR tag
- **example** : `FIREFOX_102_12_0esr_BUILD1`
- [ ] `base-browser` tag
- **example** : `base-browser-102.12.0esr-12.0-1-build1`
- [ ] `mullvad-browser` tag
- **example** : `mullvad-browser-102.12.0esr-12.0-1-build1`
- [ ] Sign+Tag additionally the `mullvad-browser.git` `firefox` commit used in build:
- **Tag**: `$(MULLVAD_BROWSER_VERSION)`
- **example** : `12.0.7`
- **Message**: `$(ESR_VERSION)esr-based $(MULLVAD_BROWSER_VERSION)`
- **example** : `102.12.0esr-based 12.0.7`
- [ ] Push tag to github
### email
- [ ] **(Once branch+tags pushed to GitHub)** Email Mullvad with release information:
- [ ] support alias: support@mullvadvpn.net
- [ ] Rui: rui@mullvad.net
- **Subject**
```
New build: Mullvad Browser $(MULLVAD_BROWSER_VERION) (signed)
```
- **Body**
```
Hello,
Branch+Tags have been pushed to Mullvad's GitHub repo.
- signed builds: https://dist.torproject.org/mullvadbrowser/$(MULLVAD_BROWSER_VERSION)
- update_response hashes: $(MULLVAD_UPDATE_RESPONSES_HASH)
changelog:
...
```
</details>
<details>
<summary>Downstream</summary>
### notify packagers
These steps depend on Mullvad having updated their [GitHub Releases](https://github.com/mullvad/mullvad-browser/releases/) page with the latest release
- [ ] Email downstream consumers:
- [ ] flathub package maintainer: proletarius101@protonmail.com
- [ ] arch package maintainer: bootctl@gmail.com
- [ ] nixOS package maintainer: dev@felschr.com
- **Subject**
```
Mullvad Browser $(MULLVAD_BROWSER_VERSION) released
```
- **Body**
```
Hello!
Mullvad-Browser packages are available, so you should update your respective downstream packages.
The latest release builds can be found here:
- https://github.com/mullvad/mullvad-browser/releases?q=prerelease%3Afalse
```
### merge requests
- [ ] homebrew: https://github.com/Homebrew/homebrew-cask/blob/master/Casks/m/mullvad-browser.rb
- **NOTE**: should just need to update `version` and `sha256` to latest
</details>richardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41099Prepare Tor Browser Stable 13.0.142024-03-26T20:24:16ZrichardPrepare Tor Browser Stable 13.0.14<details>
<summary>Explanation of variables</summary>
- `$(BUILD_SERVER)` : the server the main builder is using to build a tor-browser release
- `$(BUILDER)` : whomever is building the release on the $(BUILD_SERVER)
- **example** :...<details>
<summary>Explanation of variables</summary>
- `$(BUILD_SERVER)` : the server the main builder is using to build a tor-browser release
- `$(BUILDER)` : whomever is building the release on the $(BUILD_SERVER)
- **example** : `pierov`
- `$(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`
- `$(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`
- `$(TOR_BROWSER_VERSION)` : the Tor Browser version in the format
- **example** : `12.5a3`, `12.0.3`
- `$(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`
- `$(TBB_BUILD_TAG)` : the `tor-browser-build` build tag used to build a given Tor Browser version
- **example** : `tbb-12.0.7-build1`
</details>
**NOTE** It is assumed that the `tor-browser` stable rebase and security backport tasks have been completed
**NOTE** This can/is often done in conjunction with the equivalent Mullvad Browser release prep issue
<details>
<summary>Building</summary>
### tor-browser-build: https://gitlab.torproject.org/tpo/applications/tor-browser-build.git
Tor Browser Stable lives in the various `maint-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)` (and possibly more specific) branches.
- [ ] Update `rbm.conf`
- [ ] `var/torbrowser_version` : update to next version
- [ ] `var/torbrowser_build` : update to `$(TOR_BROWSER_BUILD_N)`
- [ ] ***(Desktop Only)***`var/torbrowser_incremental_from` : update to previous Desktop version
- **NOTE**: We try to build incrementals for the previous 3 desktop versions except in the case of a watershed update
- **IMPORTANT**: Really *actually* make sure this is the previous Desktop version or else the `make torbrowser-incrementals-*` step will fail
- [ ] Update Desktop-specific build configs
- [ ] Update `projects/firefox/config`
- [ ] `browser_build` : update to match `tor-browser` tag
- [ ] ***(Optional)*** `var/firefox_platform_version` : update to latest `$(ESR_VERSION)` if rebased
- [ ] Update Android-specific build configs
- [ ] Update `projects/geckoview/config`
- [ ] `browser_build` : update to match `tor-browser` tag
- [ ] ***(Optional)*** `var/geckoview_version` : update to latest `$(ESR_VERSION)` if rebased
- [ ] ***(Optional)*** Update `projects/tor-android-service/config`
- [ ] `git_hash` : update with `HEAD` commit of project's `main` branch
- [ ] ***(Optional)*** Update `projects/application-services/config`:
**NOTE** we don't currently have any of our own patches for this project
- [ ] `git_hash` : update to appropriate git commit associated with `$(ESR_VERSION)`
- [ ] ***(Optional)*** Update `projects/firefox-android/config`:
- [ ] `fenix_version` : update to match stable `firefox-android` build tag
- [ ] `browser_branch` : update to match stable `firefox-android` build tag
- [ ] `browser_build` : update to match stable `firefox-android` build tag
variant: Beta
- [ ] Update allowed_addons.json by running (from `tor-browser-build` root):
- `./tools/fetch_allowed_addons.py > projects/browser/allowed_addons.json`
- [ ] Update `projects/translation/config`:
- [ ] run `make list_translation_updates-release` to get updated hashes
- [ ] `steps/base-browser/git_hash` : update with `HEAD` commit of project's `base-browser` branch
- [ ] `steps/tor-browser/git_hash` : update with `HEAD` commit of project's `tor-browser` branch
- [ ] `steps/fenix/git_hash` : update with `HEAD` commit of project's `fenix-torbrowserstringsxml` branch
- [ ] Update common build configs
- [ ] 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`
- [ ] Check for OpenSSL updates here : https://www.openssl.org/source/
- [ ] ***(Optional)*** If new 3.0.X version available, update `projects/openssl/config`
- [ ] `version` : update to next 3.0.X version
- [ ] `input_files/sha256sum` : update to sha256 sum of source tarball
- [ ] Check for zlib updates here: https://github.com/madler/zlib/releases
- [ ] **(Optional)** If new tag available, update `projects/zlib/config`
- [ ] `version` : update to next release tag
- [ ] Check for tor updates here : https://gitlab.torproject.org/tpo/core/tor/-/tags
- [ ] ***(Optional)*** Update `projects/tor/config`
- [ ] `version` : update to latest non `-alpha` tag (ping dgoulet or ahf if unsure)
- [ ] Check for go updates here : https://go.dev/dl
- **NOTE** : In general, Tor Browser Stable uses the latest of the *previous* Stable major series Go version, but there are sometimes exceptions. Check with the anti-censorship team before doing a major version update in case there is incompatibilities.
- [ ] ***(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)
- [ ] Check for manual updates by running (from `tor-browser-build` root): `./tools/fetch-manual.py`
- [ ] ***(Optional)*** If new version is available:
- [ ] Upload the downloaded `manual_$PIPELINEID.zip` file to `tb-build-02.torproject.org`
- [ ] Deploy to `tb-builder`'s `public_html` directory:
- `sudo -u tb-builder cp manual_$PIPELINEID.zip ~tb-builder/public_html/.`
- [ ] Update `projects/manual/config`:
- [ ] Change the `version` to `$PIPELINEID`
- [ ] Update `sha256sum` in the `input_files` section
- [ ] Update `ChangeLog-TBB.txt`
- [ ] Ensure `ChangeLog-TBB.txt` is sync'd between alpha and stable branches
- [ ] Check the linked issues: ask people to check if any are missing, remove the not fixed ones
- [ ] Run `./tools/fetch-changelogs.py $(ISSUE_NUMBER) --date $date $updateArgs`
- Make sure you have `requests` installed (e.g., `apt install python3-requests`)
- The first time you run this script you will need to generate an access token; the script will guide you
- `$updateArgs` should be these arguments, depending on what you actually updated:
- [ ] `--firefox` (be sure to include esr at the end if needed, which is usually the case)
- [ ] `--tor`
- [ ] `--no-script`
- [ ] `--openssl`
- [ ] `--zlib`
- [ ] `--go`
- E.g., `./tools/fetch-changelogs.py 41028 --date 'December 19 2023' --firefox 115.6.0esr --tor 0.4.8.10 --no-script 11.4.29 --zlib 1.3 --go 1.21.5 --openssl 3.0.12`
- `--date $date` is optional, if omitted it will be the date on which you run the command
- [ ] Copy the output of the script to the beginning of `ChangeLog-TBB.txt` and adjust its output
- [ ] Open MR with above changes, using the template for release preparations
- [ ] Merge
- [ ] Sign+Tag
- **NOTE** this must be done by one of:
- boklm
- dan
- ma1
- pierov
- richard
- [ ] Run: `make torbrowser-signtag-release`
- [ ] Push tag to `upstream`
- [ ] Build the tag:
- Run `make torbrowser-release && make torbrowser-incrementals-release`
- [ ] Tor Project build machine
- [ ] Local developer machine
- [ ] Submit build request to Mullvad infrastructure:
- **NOTE** this requires a devmole authentication token
- Run `make torbrowser-kick-devmole-build`
- [ ] Ensure builders have matching builds
</details>
<details>
<summary>Communications</summary>
### notify stakeholders
- [ ] **(Once builds confirmed matching)** Email tor-qa mailing list with release information
- [ ] tor-qa: tor-qa@lists.torproject.org
- **Subject**
```
Tor Browser $(TOR_BROWSER_VERION) (Android, Windows, macOS, Linux)
```
- **Body**
```
Hello,
Unsigned Tor Browser $(TOR_BROWSER_VERSION) release candidate builds are now available for testing:
- https://tb-build-02.torproject.org/~$(BUILDER)/builds/torbrowser/release/unsigned/$(TOR_BROWSER_VERSION)/
The full changelog can be found here:
- https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/raw/$(TBB_BUILD_TAG)/projects/browser/Bundle-Data/Docs-TBB/ChangeLog.txt
```
- [ ] Email packagers:
- [ ] Tails dev mailing list: tails-dev@boum.org
- [ ] Guardian Project: nathan@guardianproject.info
- [ ] FreeBSD port: freebsd@sysctl.cz <!-- Gitlab user maxfx -->
- [ ] OpenBSD port: caspar@schutijser.com <!-- Gitlab user cschutijser -->
- [ ] Note any changes which may affect packaging/downstream integration
</details>
<details>
<summary>Signing</summary>
### release signing
- **NOTE** : In practice, it's most efficient to have the blog post and website updates ready to merge, since signing doesn't take very long
- [ ] Assign this issue to the signer, one of:
- boklm
- richard
- [ ] On `$(STAGING_SERVER)`, ensure updated:
- [ ] `tor-browser-build` is on the right commit: `git tag -v tbb-$(TOR_BROWSER_VERSION)-$(TOR_BROWSER_BUILD_N) && git checkout tbb-$(TOR_BROWSER_VERSION)-$(TOR_BROWSER_BUILD_N)`
- [ ] `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
- [ ] `tor-browser-build/tools/signing/set-config.rcodesign-appstoreconnect`
- `appstoreconnect_api_key_path` : path to json file containing appstoreconnect api key infos
- [ ] `set-config.update-responses`
- `update_responses_repository_dir` : directory where you cloned `git@gitlab.torproject.org:tpo/applications/tor-browser-update-responses.git`
- [ ] `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, ensure tor daemon is running with SOCKS5 proxy on the default port 9050
- [ ] On `$(STAGING_SERVER)` in a separate `screen` session, run do-all-signing script:
- `cd tor-browser-build/tools/signing/`
- `./do-all-signing.torbrowser`
- **NOTE**: at this point the signed binaries should have been copied to `staticiforme`
- [ ] Update `staticiforme.torproject.org`:
- From `screen` session on `staticiforme.torproject.org`:
- [ ] Static update components : `static-update-component cdn.torproject.org && static-update-component dist.torproject.org`
- [ ] Enable update responses : `sudo -u tb-release ./deploy_update_responses-release.sh`
- [ ] Remove old release data from following places:
- **NOTE** : Skip this step if we need to hold on to older versions for some reason (for example, this is an Andoid or Desktop-only release, or if we need to hold back installers in favor of build-to-build updates if there are signing issues, etc)
- [ ] `/srv/cdn-master.torproject.org/htdocs/aus1/torbrowser`
- [ ] `/srv/dist-master.torproject.org/htdocs/torbrowser`
- [ ] Static update components (again) : `static-update-component cdn.torproject.org && static-update-component dist.torproject.org`
</details>
<details>
<summary>Signature verification</summary>
<details>
<summary>Check whether the .exe files got properly signed and timestamped</summary>
```bash
# Point OSSLSIGNCODE to your osslsigncode binary
pushd tor-browser-build/${channel}/signed/$TORBROWSER_VERSION
OSSLSIGNCODE=/path/to/osslsigncode
../../../tools/authenticode_check.sh
popd
```
</details>
<details>
<summary>Check whether the MAR files got properly signed</summary>
```bash
# Point NSSDB to your nssdb containing the mar signing certificate
# Point SIGNMAR to your signmar binary
# Point LD_LIBRARY_PATH to your mar-tools directory
pushd tor-browser-build/${channel}/signed/$TORBROWSER_VERSION
NSSDB=/path/to/nssdb
SIGNMAR=/path/to/mar-tools/signmar
LD_LIBRARY_PATH=/path/to/mar-tools/
../../../tools/marsigning_check.sh
popd
```
</details>
</details>
<details>
<summary>Publishing</summary>
### Google Play: https://play.google.com/apps/publish
- [ ] Publish APKs to Google Play:
- Select `Tor Browser` app
- Navigate to `Release > Production` and click `Create new release` button:
- Upload the `tor-browser-android-*.apk` APKs
- Update Release Name to Tor Browser version number
- Update Release Notes
- Next to 'Release notes', click `Copy from a previous release`
- Edit blog post url to point to most recent blog post
- Save, review, and configure rollout percentage
- [ ] 25% rollout when publishing a scheduled update
- [ ] 100% rollout when publishing a security-driven release
- [ ] Update rollout percentage to 100% after confirmed no major issues
### 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-alpha/version` : sort of a catch-all for latest stable version
- `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 accessible on https://dist.torproject.org
- [ ] Merge
- [ ] Publish after CI passes and builds are published
### blog: https://gitlab.torproject.org/tpo/web/blog.git
- [ ] Run `tools/signing/create-blog-post` which should create the new blog post from a template (edit set-config.blog to set you local blog directory)
- [ ] Note any ESR update
- [ ] Note any updates to dependencies (OpenSSL, zlib, NoScript, tor, etc)
- [ ] Thank any users which have contributed patches
- [ ] Push to origin as new branch, open `Draft:` MR
- [ ] Merge once signed-packages are accessible on https://dist.torproject.org
- [ ] Publish after CI passes and website has been updated
### tor-announce mailing list
- [ ] Email tor-announce mailing list: tor-announce@lists.torproject.org
- **Subject**
```
New Release: Tor Browser $(TOR_BROWSER_VERSION) (Android, Windows, macOS, Linux)
```
- **Body**
```
Hi everyone,
Tor Browser $(TOR_BROWSER_VERSION) has now been published for all platforms. For details please see our blog post:
- $(BLOG_POST_URL)
Changelog:
# paste changleog as quote here
```
</details>richardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41096Set SOURCE_DATE_EPOCH in the default env variables2024-02-29T13:11:09ZPier Angelo VendrameSet SOURCE_DATE_EPOCH in the default env variablesSince we set a timestamp for most projects (to the commit we're using if we're using git), we could use it also to set `SOURCE_DATE_EPOCH` in the default environment (`set_default_env`).
However, it will trigger a complete rebuild of ev...Since we set a timestamp for most projects (to the commit we're using if we're using git), we could use it also to set `SOURCE_DATE_EPOCH` in the default environment (`set_default_env`).
However, it will trigger a complete rebuild of everything, so we could wait until the next ESR toolchain update to do it.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41094Prepare Tor Browser Alpha 13.5a62024-03-28T19:10:12ZPier Angelo VendramePrepare Tor Browser Alpha 13.5a6<details>
<summary>Explanation of variables</summary>
- `$(BUILD_SERVER)` : the server the main builder is using to build a tor-browser release
- `$(BUILDER)` : whomever is building the release on the $(BUILD_SERVER)
- **example** :...<details>
<summary>Explanation of variables</summary>
- `$(BUILD_SERVER)` : the server the main builder is using to build a tor-browser release
- `$(BUILDER)` : whomever is building the release on the $(BUILD_SERVER)
- **example** : `pierov`
- `$(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`
- `$(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`
- `$(TOR_BROWSER_VERSION)` : the Tor Browser version in the format
- **example** : `12.5a3`, `12.0.3`
- `$(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`
- `$(TBB_BUILD_TAG)` : the `tor-browser-build` build tag used to build a given Tor Browser version
- **example** : `tbb-12.5a7-build1`
</details>
**NOTE** It is assumed that the `tor-browser` stable rebase and security backport tasks have been completed
**NOTE** This can/is often done in conjunction with the equivalent Mullvad Browser release prep issue
<details>
<summary>Building</summary>
### tor-browser-build: https://gitlab.torproject.org/tpo/applications/tor-browser-build.git
Tor Browser Alpha (and Nightly) are on the `main` branch
- [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
- **NOTE**: We try to build incrementals for the previous 3 desktop versions except in the case of a watershed update
- **IMPORTANT**: Really *actually* make sure this is the previous Desktop version or else the `make torbrowser-incrementals-*` step will fail
- [x] Update Desktop-specific build configs
- [x] Update `projects/firefox/config`
- [x] `browser_build` : update to match `tor-browser` tag
- [ ] ***(Optional)*** `var/firefox_platform_version` : update to latest `$(ESR_VERSION)` if rebased
- [x] Update Android-specific build configs
- [x] Update `projects/geckoview/config`
- [x] `browser_build` : update to match `tor-browser` tag
- [ ] ***(Optional)*** `var/geckoview_version` : update to latest `$(ESR_VERSION)` if rebased
- [ ] ***(Optional)*** Update `projects/tor-android-service/config`
- [ ] `git_hash` : update with `HEAD` commit of project's `main` branch
- [ ] ***(Optional)*** Update `projects/application-services/config`:
**NOTE** we don't currently have any of our own patches for this project
- [ ] `git_hash` : update to appropriate git commit associated with `$(ESR_VERSION)`
- [x] ***(Optional)*** Update `projects/firefox-android/config`:
- [ ] `fenix_version` : update to match alpha `firefox-android` build tag
- [ ] `browser_branch` : update to match alpha `firefox-android` build tag
- [x] `browser_build` : update to match alpha `firefox-android` build tag
- [x] Update allowed_addons.json by running (from `tor-browser-build` root):
- `./tools/fetch_allowed_addons.py > projects/browser/allowed_addons.json`
- [x] Update `projects/translation/config`:
- [x] run `make list_translation_updates-alpha` to get updated hashes
- [x] `steps/base-browser/git_hash` : update with `HEAD` commit of project's `base-browser` branch
- [x] `steps/tor-browser/git_hash` : update with `HEAD` commit of project's `tor-browser` branch
- [x] `steps/fenix/git_hash` : update with `HEAD` commit of project's `fenix-torbrowserstringsxml` branch
- [x] Update common build configs
- [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://www.openssl.org/source/
- [ ] ***(Optional)*** If new 3.0.X version available, update `projects/openssl/config`
- [ ] `version` : update to next 3.0.X version
- [ ] `input_files/sha256sum` : update to sha256 sum of source tarball
- [x] Check for zlib updates here: https://github.com/madler/zlib/releases
- [ ] **(Optional)** If new tag available, update `projects/zlib/config`
- [ ] `version` : update to next release tag
- [x] Check for tor updates here : https://gitlab.torproject.org/tpo/core/tor/-/tags
- [ ] ***(Optional)*** Update `projects/tor/config`
- [ ] `version` : update to latest `-alpha` tag or release tag if newer (ping dgoulet or ahf if unsure)
- [x] Check for go updates here : https://go.dev/dl
- **NOTE** : In general, Tor Browser Alpha uses the latest Stable major series Go version, but there are sometimes exceptions. Check with the anti-censorship team before doing a major version update in case there is incompatibilities.
- [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] Check for manual updates by running (from `tor-browser-build` root): `./tools/fetch-manual.py`
- [ ] ***(Optional)*** If new version is available:
- [ ] Upload the downloaded `manual_$PIPELINEID.zip` file to `tb-build-02.torproject.org`
- [ ] Deploy to `tb-builder`'s `public_html` directory:
- `sudo -u tb-builder cp manual_$PIPELINEID.zip ~tb-builder/public_html/.`
- [x] Update `projects/manual/config`:
- [x] Change the `version` to `$PIPELINEID`
- [x] Update `sha256sum` in the `input_files` section
- [x] Update `ChangeLog-TBB.txt`
- [x] Ensure `ChangeLog-TBB.txt` is sync'd between alpha and stable branches
- [x] Check the linked issues: ask people to check if any are missing, remove the not fixed ones
- [x] Run `./tools/fetch-changelogs.py $(ISSUE_NUMBER) --date $date $updateArgs`
- Make sure you have `requests` installed (e.g., `apt install python3-requests`)
- The first time you run this script you will need to generate an access token; the script will guide you
- `$updateArgs` should be these arguments, depending on what you actually updated:
- [x] `--firefox` (be sure to include esr at the end if needed, which is usually the case)
- [ ] `--tor`
- [ ] `--no-script`
- [ ] `--openssl`
- [ ] `--zlib`
- [x] `--go`
- E.g., `./tools/fetch-changelogs.py 41028 --date 'December 19 2023' --firefox 115.6.0esr --tor 0.4.8.10 --no-script 11.4.29 --zlib 1.3 --go 1.21.5 --openssl 3.0.12`
- `--date $date` is optional, if omitted it will be the date on which you run the command
- [x] Copy the output of the script to the beginning of `ChangeLog-TBB.txt` and adjust its output
- [x] Open MR with above changes, using the template for release preparations
- [x] Merge
- [x] Sign+Tag
- **NOTE** this must be done by one of:
- boklm
- dan
- ma1
- pierov
- richard
- [x] Run: `make torbrowser-signtag-alpha`
- [x] Push tag to `upstream`
- [x] Build the tag:
- Run `make torbrowser-alpha && make torbrowser-incrementals-alpha`
- [x] Tor Project build machine
- [x] Local developer machine
- [x] Submit build request to Mullvad infrastructure:
- **NOTE** this requires a devmole authentication token
- Run `make torbrowser-kick-devmole-build`
- [ ] Ensure builders have matching builds
</details>
<details>
<summary>Communications</summary>
### notify stakeholders
- [x] **(Once builds confirmed matching)** Email tor-qa mailing list with release information
- [x] tor-qa: tor-qa@lists.torproject.org
- **Subject**
```
Tor Browser $(TOR_BROWSER_VERION) (Android, Windows, macOS, Linux)
```
- **Body**
```
Hello,
Unsigned Tor Browser $(TOR_BROWSER_VERSION) alpha candidate builds are now available for testing:
- https://tb-build-02.torproject.org/~$(BUILDER)/builds/alpha/unsigned/$(TOR_BROWSER_VERSION)/
The full changelog can be found here:
- https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/raw/$(TBB_BUILD_TAG)/projects/browser/Bundle-Data/Docs-TBB/ChangeLog.txt
```
- [ ] ***(Optional, only around build/packaging changes)*** Email packagers:
- [ ] Tails dev mailing list: tails-dev@boum.org
- [ ] Guardian Project: nathan@guardianproject.info
- [ ] FreeBSD port: freebsd@sysctl.cz <!-- Gitlab user maxfx -->
- [ ] OpenBSD port: caspar@schutijser.com <!-- Gitlab user cschutijser -->
- [ ] Note any changes which may affect packaging/downstream integration
- [ ] ***(Optional, after ESR migration)*** Email external partners:
- [ ] Cloudflare: ask-research@cloudflare.com
- **NOTE** : We need to provide them with updated user agent string so they can update their internal machinery to prevent Tor Browser users from getting so many CAPTCHAs
- [ ] Startpage: admin@startpage.com
- **NOTE** : Startpage also needs the updated user-agent string for better experience on their onion service sites.
</details>
<details>
<summary>Signing</summary>
### release signing
- **NOTE** : In practice, it's most efficient to have the blog post and website updates ready to merge, since signing doesn't take very long
- [x] Assign this issue to the signer, one of:
- boklm
- richard
- [x] On `$(STAGING_SERVER)`, ensure updated:
- [x] `tor-browser-build` is on the right commit: `git tag -v tbb-$(TOR_BROWSER_VERSION)-$(TOR_BROWSER_BUILD_N) && git checkout tbb-$(TOR_BROWSER_VERSION)-$(TOR_BROWSER_BUILD_N)`
- [x] `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
- [x] `tor-browser-build/tools/signing/set-config.rcodesign-appstoreconnect`
- `appstoreconnect_api_key_path` : path to json file containing appstoreconnect api key infos
- [x] `set-config.update-responses`
- `update_responses_repository_dir` : directory where you cloned `git@gitlab.torproject.org:tpo/applications/tor-browser-update-responses.git`
- [x] `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
- [x] On `$(STAGING_SERVER)` in a separate `screen` session, ensure tor daemon is running with SOCKS5 proxy on the default port 9050
- [x] On `$(STAGING_SERVER)` in a separate `screen` session, run do-all-signing script:
- `cd tor-browser-build/tools/signing/`
- `./do-all-signing.torbrowser`
- **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`
- [x] Enable update responses : `sudo -u tb-release ./deploy_update_responses-alpha.sh`
- [ ] Remove old release data from following places:
- **NOTE** : Skip this step if we need to hold on to older versions for some reason (for example, this is an Andoid or Desktop-only release, or if we need to hold back installers in favor of build-to-build updates if there are signing issues, etc)
- [x] `/srv/cdn-master.torproject.org/htdocs/aus1/torbrowser`
- [x] `/srv/dist-master.torproject.org/htdocs/torbrowser`
- [x] Static update components (again) : `static-update-component cdn.torproject.org && static-update-component dist.torproject.org`
</details>
<details>
<summary>Signature verification</summary>
<details>
<summary>Check whether the .exe files got properly signed and timestamped</summary>
```bash
# Point OSSLSIGNCODE to your osslsigncode binary
pushd tor-browser-build/${channel}/signed/$TORBROWSER_VERSION
OSSLSIGNCODE=/path/to/osslsigncode
../../../tools/authenticode_check.sh
popd
```
</details>
<details>
<summary>Check whether the MAR files got properly signed</summary>
```bash
# Point NSSDB to your nssdb containing the mar signing certificate
# Point SIGNMAR to your signmar binary
# Point LD_LIBRARY_PATH to your mar-tools directory
pushd tor-browser-build/${channel}/signed/$TORBROWSER_VERSION
NSSDB=/path/to/nssdb
SIGNMAR=/path/to/mar-tools/signmar
LD_LIBRARY_PATH=/path/to/mar-tools/
../../../tools/marsigning_check.sh
popd
```
</details>
</details>
<details>
<summary>Publishing</summary>
### Google Play: https://play.google.com/apps/publish
- [ ] Publish APKs to Google Play:
- Select `Tor Browser (Alpha)` app
- Navigate to `Release > Production` and click `Create new release` button:
- Upload the `tor-browser-android-*.apk` APKs
- Update Release Name to Tor Browser version number
- Update Release Notes
- Next to 'Release notes', click `Copy from a previous release`
- Edit blog post url to point to most recent blog post
- Save, review, and configure rollout percentage
- [ ] 25% rollout when publishing a scheduled update
- [ ] 100% rollout when publishing a security-driven release
- [ ] Update rollout percentage to 100% after confirmed no major issues
### 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-alpha/version` : sort of a catch-all for latest stable version
- `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 accessible on https://dist.torproject.org
- [x] Merge
- [x] Publish after CI passes and builds are published
### blog: https://gitlab.torproject.org/tpo/web/blog.git
- [x] Run `tools/signing/create-blog-post` which should create the new blog post from a template (edit set-config.blog to set you local blog directory)
- [ ] Note any ESR update
- [ ] Note any updates to dependencies (OpenSSL, zlib, NoScript, tor, etc)
- [x] Thank any users which have contributed patches
- [x] **(Optional)** Draft any additional sections for new features which need testing, known issues, etc
- [x] Push to origin as new branch, open `Draft:` MR
- [x] Merge once signed-packages are accessible on https://dist.torproject.org
- [x] Publish after CI passes and website has been updated
### tor-announce mailing list
- [x] Email tor-announce mailing list: tor-announce@lists.torproject.org
- **Subject**
```
New Release: Tor Browser $(TOR_BROWSER_VERSION) (Android, Windows, macOS, Linux)
```
- **Body**
```
Hi everyone,
Tor Browser $(TOR_BROWSER_VERSION) has now been published for all platforms. For details please see our blog post:
- $(BLOG_POST_URL)
Changelog:
# paste changleog as quote here
```
</details>richardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41091Check if we can export the debug symbols also for Android2024-03-05T13:58:33ZPier Angelo VendrameCheck if we can export the debug symbols also for AndroidSometimes we would like to be able to debug Geckoview's native code (e.g., if it crashes).
We will need to force the APK to be debuggable (which we can turn on only if needed), but at least we could avoid to rebuild GeckoView.
I think ...Sometimes we would like to be able to debug Geckoview's native code (e.g., if it crashes).
We will need to force the APK to be debuggable (which we can turn on only if needed), but at least we could avoid to rebuild GeckoView.
I think that a command like this could help:
```bash
find toolkit/library/build mozglue/build security -name '*.so' -exec bash -c 'mkdir -p $(dirname "/var/tmp/dist/geckoview/libraries/{}"); cp -a {} /var/tmp/dist/geckoview/libraries/{}' \;
```
I ran it inside the `obj-$arch...` directory (notice that at the end we have two `obj-...` directories in testbuilds, since we create the fake fat AAR).
These directories come from the fact that they are the ones [Mozilla is adding to lldb's configuration](https://firefox-source-docs.mozilla.org/mobile/android/geckoview/contributor/native-debugging.html#set-up-lldb-to-find-your-symbols).
Notice that I'm doing a full `cp` rather than an `objcopy`: the difference is 0.1GB in uncompressed files, and I haven't tried if symbols without an explicit gnu link work (maybe we'd have to extract the aar and re-create it to add the debug link, and still I'm not sure it will work).
However, the final size of each artifact will grow from around 50MB to almost 500MB!
So, we maybe should we apply it only to testbuilds?https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41090torrc-defaults use "\r\n" as the end-of-line on Linux.2024-03-05T13:53:57Zcypherpunkstorrc-defaults use "\r\n" as the end-of-line on Linux.Version and sha256sum: 6aad967df4376542f4be8a5b0d4e67f5b59bf0c0bbac7a1acf9e24cf6a1a5f3f ./tor-browser-linux-i686-13.0.9.tar.xz
Reproduce step:
1. extract tor-browser-linux-i686-13.0.9.tar.xz
2. run hd ./torrc-defaults | grep -e '^' ...Version and sha256sum: 6aad967df4376542f4be8a5b0d4e67f5b59bf0c0bbac7a1acf9e24cf6a1a5f3f ./tor-browser-linux-i686-13.0.9.tar.xz
Reproduce step:
1. extract tor-browser-linux-i686-13.0.9.tar.xz
2. run hd ./torrc-defaults | grep -e '^' -e '0d'
I think normal text configuration file in Linux should never include the "\r"(0x0d) character.
Is my understanding correct?https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41083Make deb package for Mullvad Browser2024-03-28T10:14:54ZboklmMake deb package for Mullvad BrowserWe should generate a deb package for Mullvad Browser.We should generate a deb package for Mullvad Browser.boklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41071Customize the GTK default font on Linux2024-01-29T18:31:10ZPier Angelo VendrameCustomize the GTK default font on LinuxThe updater is showing in some serif font (I think Stix Math Two, which fontconfig likes a lot because of the version number).
We could customize the GTK default font to Arimo (our current default font in Tor Browser), which should fix ...The updater is showing in some serif font (I think Stix Math Two, which fontconfig likes a lot because of the version number).
We could customize the GTK default font to Arimo (our current default font in Tor Browser), which should fix this behavior.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41069Unify the `start-$browser-browser` and the `$browser` scripts2024-01-25T14:34:45ZPier Angelo VendrameUnify the `start-$browser-browser` and the `$browser` scriptsCurrently, we ship two scripts: one is `start-tor-browser`/`start-mullvad-browser`, the other one is `firefox`/`mullvadbrowser`.
The reason seems to be related to the updater (passing the directory with the `libstdc++6` we ship to `LD_LI...Currently, we ship two scripts: one is `start-tor-browser`/`start-mullvad-browser`, the other one is `firefox`/`mullvadbrowser`.
The reason seems to be related to the updater (passing the directory with the `libstdc++6` we ship to `LD_LIBRARY_PATH` when needed).
However, some users might be launching `firefox` instead of `start-tor-browser` (or even worse, the actual binary - `firefox.real`!).
This is a risk, because they're missing home isolation and especially the fontconfig settings.
Could we do something to unify these scripts instead?
The first course of action would be to test Tor/Mullvad Browser (and the updater) in an old system, to trigger the need to use our libstdc++.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41064Update tools/signing/README and add a tools/signing/machines-setup/README2024-01-18T15:05:06ZboklmUpdate tools/signing/README and add a tools/signing/machines-setup/READMEWe should update `tools/signing/README` for latest changes, and also
point to the issue templates for usage information.
We should also create `tools/signing/machines-setup/README` to document
how the setup of the signing machines is done.We should update `tools/signing/README` for latest changes, and also
point to the issue templates for usage information.
We should also create `tools/signing/machines-setup/README` to document
how the setup of the signing machines is done.boklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41040Add configuration to rbm.conf to select channel and platforms2024-01-09T15:00:50ZboklmAdd configuration to rbm.conf to select channel and platformsCurrently we select the channel and platforms of a release with the make
command we use to start the build. I think we could define this
somewhere in `rbm.conf`, so that we can start the build with something
like `make torbrowser` or `ma...Currently we select the channel and platforms of a release with the make
command we use to start the build. I think we could define this
somewhere in `rbm.conf`, so that we can start the build with something
like `make torbrowser` or `make mullvadbrowser`, automatically selecting
the right channel and platforms to build.
The information about which platforms a release is for can also be used
for #40994.
At the same time we can also rename `var/torbrowser_version`,
`var/torbrowser_build`, `var/torbrowser_incremental_from` to remove the
torbrowser part (since this is used in mullvadbrowser too).