The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-03-26T20:57:03Zhttps://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/271After update, don't open the release page on Github. Instead link it in the s...2024-03-26T20:57:03ZruihildtAfter update, don't open the release page on Github. Instead link it in the startpage, like in Tor BrowserUsers are complaining a Github page is opening automatically after update (which I entirely agree is unnecessary and unwelcome).
Could we adopt the same flow as in Tor Browser.
See screenshot:
![image](/uploads/e19a1ed79ffdf358bf738ff...Users are complaining a Github page is opening automatically after update (which I entirely agree is unnecessary and unwelcome).
Could we adopt the same flow as in Tor Browser.
See screenshot:
![image](/uploads/e19a1ed79ffdf358bf738ffb8be9b953/image.png)richardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41087Prepare Mullvad Browser Stable 13.0.122024-03-22T00:07:20ZrichardPrepare Mullvad Browser Stable 13.0.12<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
- [x] Update `rbm.conf`
- [x] `var/torbrowser_version` : update to next version
- [x] `var/torbrowser_build` : update to `$(MULLVAD_BROWSER_BUILD_N)`
- [x] `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
- [x] Update build configs
- [x] Update `projects/firefox/config`
- [x] `browser_build` : update to match `mullvad-browser` tag
- [x] ***(Optional)*** `var/firefox_platform_version` : update to latest `$(ESR_VERSION)` if rebased
- [x] Update `projects/translation/config`:
- [x] run `make list_translation_updates-release` to get updated hashes
- [x] `steps/base-browser/git_hash` : update with `HEAD` commit of project's `base-browser` branch
- [x] `steps/mullvad-browser/git_hash` : update with `HEAD` commit of project's `mullvad-browser` 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 uBlock-origin updates here : https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/
- [x] ***(Optional)*** If new version available, update `ublock-origin` section of `input_files` in `projects/browser/config`
- [x] `URL`
- [x] `sha256sum`
- [x] Check for Mullvad Browser Extension updates here : https://github.com/mullvad/browser-extension/releases
- [x] ***(Optional)*** If new version available, update `mullvad-extension` section of `input_files` in `projects/browser/config`
- [x] `URL`
- [x] `sha256sum`
- [x] Update `ChangeLog-MB.txt`
- [x] 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
- [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)
- [ ] `--no-script`
- [x] `--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
- [x] Copy the output of the script to the beginning of `ChangeLog-MB.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 mullvadbrowser-signtag-release`
- [x] Push tag to `upstream`
- [x] Build the tag:
- Run `make mullvadbrowser-release && make mullvadbrowser-incrementals-release`
- [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 mullvadbrowser-kick-devmole-build`
- [x] Ensure builders have matching builds
</details>
<details>
<summary>Signing</summary>
### release signing
- [x] Assign this issue to the signer, one of:
- boklm
- richard
- [ ] On `$(STAGING_SERVER)`, ensure updated:
- [x] `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)`
- [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/mullvad-browser-update-responses.git`
- [x] `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
- [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.mullvadbrowser`
- **NOTE**: at this point the signed binaries should have been copied to `staticiforme`
- [x] Update `staticiforme.torproject.org`:
- From `screen` session on `staticiforme.torproject.org`:
- [x] Remove old release data from `/srv/dist-master.torproject.org/htdocs/mullvadbrowser`
- [x] Static update components (again) : `static-update-component dist.torproject.org`
</details>
<details>
<summary>Publishing</summary>
### mullvad-browser (GitHub): https://github.com/mullvad/mullvad-browser/
- [x] Assign this issue to someone with mullvad commit access, one of:
- richard
- [x] Push this release's associated `mullvad-browser.git` branch to github
- [x] Push this release's associated tags to github:
- [x] Firefox ESR tag
- **example** : `FIREFOX_102_12_0esr_BUILD1`
- [x] `base-browser` tag
- **example** : `base-browser-102.12.0esr-12.0-1-build1`
- [x] `mullvad-browser` tag
- **example** : `mullvad-browser-102.12.0esr-12.0-1-build1`
- [x] 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`
- [x] Push tag to github
### email
- [x] **(Once branch+tags pushed to GitHub)** Email Mullvad with release information:
- [x] support alias: support@mullvadvpn.net
- [x] 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
- [x] 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/41086Prepare Tor Browser Stable 13.0.122024-03-20T17:10:30ZrichardPrepare Tor Browser Stable 13.0.12<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.
- [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
- [x] ***(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
- [x] ***(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`:
- [x] `fenix_version` : update to match alpha `firefox-android` build tag
- [ ] `browser_branch` : 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-release` 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 non `-alpha` tag (ping dgoulet or ahf if unsure)
- [x] 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.
- [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`
- [x] ***(Optional)*** If new version is available:
- [x] Upload the downloaded `manual_$PIPELINEID.zip` file to `tb-build-02.torproject.org`
- [x] 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
- [ ] 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-release`
- [x] Push tag to `upstream`
- [x] Build the tag:
- Run `make torbrowser-release && make torbrowser-incrementals-release`
- [ ] Tor Project build machine
- [ ] Local developer machine
- [x] Submit build request to Mullvad infrastructure:
- **NOTE** this requires a devmole authentication token
- Run `make torbrowser-kick-devmole-build`
- [x] 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) release candidate builds are now available for testing:
- https://tb-build-02.torproject.org/~$(BUILDER)/builds/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
```
- [x] 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
- [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-release.sh`
- [x] 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
- [x] 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
- [x] 25% rollout when publishing a scheduled update
- [x] 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)
- [ ] Thank any users which have contributed patches
- [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>boklmboklmhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41534Install package libcapture-tiny-perl on tbb-nightlies-master2024-02-20T18:19:26ZboklmInstall package libcapture-tiny-perl on tbb-nightlies-masterAfter tor-browser-build#41067, we need the package
`libcapture-tiny-perl` to be installed on
`tbb-nightlies-master.torproject.org`.
Thanks!After tor-browser-build#41067, we need the package
`libcapture-tiny-perl` to be installed on
`tbb-nightlies-master.torproject.org`.
Thanks!Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41533update meskio's openpgp key2024-02-21T15:35:32Zmeskiomeskio@torproject.orgupdate meskio's openpgp key```
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I have extended the expirate date of my openpgp key. Can it be updated in my account?
The key is the same one already present in the account's database:
pub rsa4096 2013-07-23 [SC] ...```
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I have extended the expirate date of my openpgp key. Can it be updated in my account?
The key is the same one already present in the account's database:
pub rsa4096 2013-07-23 [SC] [expires: 2025-04-14]
07948FFA64160A425BCD27EAC732B1D1C28F4E2F
It can be downloaded from:
https://keys.openpgp.org/vks/v1/by-fingerprint/07948FFA64160A425BCD27EAC732B1D1C28F4E2F
Thank you
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEs7M6f/ZpXzXMAQR+Urj1rJei2oYFAmXTnbsACgkQUrj1rJei
2oYutQ/+NhjAXneUS+IhwMySmgeaU6JS1fhesCQPhPKQ2e4Wo4MuH7A0OLlHk+wK
Adrifi84Kv5UZIK7C2nFwXzIxFaKRNv+dvbe0wAMrX7MtjokEe8WZxDqjFKQHvP1
WHXltMFPv5KBrpyO3EBUxm0GjQmZx7UV3yfp3FV/Flne9vDSKbEYgq3zZlvXjXNI
d3hI00eyuxhPEiw/aT/W0NQSlRI4Tiv4l5ugq6VsdKjeKS09KYUCgO9qAz2iuyA1
rb9oHRwr1TBNc65Ln7pBTgHUWaXqecGIu7DH6VrNQmK+4QKtejp5NuE/1Z6H7XgS
BNsmJWLQUUmHcXdqjQ7tOPtT4hIQoMCKPDjVxSdyEVv6/LMY8BFhLPgtPhSlVsEn
1Rht66GIhIL/qkbnVlktg74TFSpAHjGnoPY6VGo6zZUU0P0GlCSL1S5qHQOF4Tnv
Auj7Hd65uuhBJn7mDukAYWonTAeezPu/MpTaMfy+Yjryc+7zW5CU2VXHFlgxbGuw
e+iZadGsi++ZYgblGBp7Xr/RvG1wux63Y15kASkXK0HvgkmS8g9lm90Ml4vaxHF0
wj48Bvy6VuLepPGZWiL7nWRDGMNH4gwoA8i8ZZAXTdG8pj+x/Xq5GGwmQT6rWR0j
IEic95a5roixoihs6z5f/COWDBTD1VoC+rbq2e6BQAuf4or7FVk=
=0Ffs
-----END PGP SIGNATURE-----
```Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/core/onionmasq/-/issues/88Rebase on latest arti2024-03-21T15:41:20ZetaRebase on latest artiThe fork of arti we're using has drifted a fair deal from upstream, which we should fix.The fork of arti we're using has drifted a fair deal from upstream, which we should fix.etaetahttps://gitlab.torproject.org/tpo/core/onionmasq/-/issues/87Migrate stuff from personal forks2024-03-25T18:17:24ZetaMigrate stuff from personal forksThere are a bunch of forks of things (arti, smoltcp) that are in my personal GitLab account. This should be fixed.There are a bunch of forks of things (arti, smoltcp) that are in my personal GitLab account. This should be fixed.etaeta2024-03-14https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/890.7.3 rejected from mozilla2024-03-28T04:37:33Zmeskiomeskio@torproject.org0.7.3 rejected from mozillaWe got this email:
> Due to issues discovered during the review process, one or more versions of your add-on Snowflake will be disabled on addons.mozilla.org in 14 day(s). Please
> see the reviewer’s comments below for more information.
...We got this email:
> Due to issues discovered during the review process, one or more versions of your add-on Snowflake will be disabled on addons.mozilla.org in 14 day(s). Please
> see the reviewer’s comments below for more information.
>
> ********
> Details:
> - Reproducing the submitted release version based on the provided source code package and instructions failed.
>
> You can access the console output at https://paste.mozilla.org/kOCS6sFe
> Environment used for building: Node 20.10.0, npm 10.2.3 on Ubuntu 22.04 LTS x64 (10GB RAM, 6 CPUs)
>
> Please test your build in a clean environment to make sure it is reproducible. If necessary, update the source code package and/or the instructions to
> reproduce.
> Please read through the instructions at https://extensionworkshop.com/documentation/publish/source-code-submission/ .
>
> Version(s) affected:
> 0.7.3
> ********
>
> Please address the issues raised in the reviewer's notes and inquire about any unclear items. Afterwards, please upload a new version of your add-on at
> https://addons.mozilla.org/en-US/developers/addon/torproject-snowflake/versions.
>
> To respond, please reply to this email or visit https://addons.mozilla.org/en-US/developers/addon/torproject-snowflake/versions. If we do not hear from you
> within 14 day(s) of this notification, these versions will be removed from addons.mozilla.org. Current users of these versions will be unaffected.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40330Collect metrics for binned counts of client polls per country for each rendez...2024-03-12T11:29:00ZCecylia BocovichCollect metrics for binned counts of client polls per country for each rendezvous methodWe now collect metrics on [poll counts for each rendezvous method](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/243). To learn about potential censorship events it would be useful to a...We now collect metrics on [poll counts for each rendezvous method](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/243). To learn about potential censorship events it would be useful to also collect binned polling counts per country by adding a line:
```
client-[method]-ips [CC=NUM,CC=NUM,...,CC=NUM] NL
```
for each rendezvous method.
I think it's safer to still collect poll counts rather than unique IPs for clients to avoid the necessity of storing (even hashed) seen addresses in memory. The main trick is in how we learn the client's IP address to perform a country code lookup in the geoip database. For the domain fronting rendezvous method, we could use the `X-Forwarded-For` header, but SQS does not offer details on the IP that sent the message. One way to do this is to pull the client IP out of the SDP offer. We already have some code for processing ice candidates and [removing local addresses](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/35984c0876273adb810ab3cc558464ba786aafcd/common/util/util.go#L70-L99). Something similar could be done to extract the client IP.mpumpuhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41528Make Lox open invite endpoint only available to telegram bot2024-02-21T13:48:53ZonyinyangMake Lox open invite endpoint only available to telegram botWe have deployed Lox's distributor on `rdsys-frontend-01.torproject.org` and Lox client requests can be made to various Lox server endpoints at `rdsys-frontend-01.torproject.org/lox`. All except one of these requests requires a user to p...We have deployed Lox's distributor on `rdsys-frontend-01.torproject.org` and Lox client requests can be made to various Lox server endpoints at `rdsys-frontend-01.torproject.org/lox`. All except one of these requests requires a user to present a valid Lox credential(s) in order to get the desired response. We would like to limit access to the one endpoint that doesn't require any credentials, `rdsys-frontend-01.torproject.org/lox/invite` to our telegram bot that is running on `polyanthum.torproject.org`. In the future, we will likely use a token to limit access instead, but during the testing/alpha phase, limiting access to polyanthum is probably sufficient.Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/1280Long-running arti service reachability issues2024-02-29T18:14:52Zgabi-250Long-running arti service reachability issues@stefani and @jnewsome report that arti onion services become unreachable after some time. On the client side, the logs suggest the descriptor is not available at the expected HsDirs:
```
Jan 04 14:26:57.777 [info] handle_response_fetch_...@stefani and @jnewsome report that arti onion services become unreachable after some time. On the client side, the logs suggest the descriptor is not available at the expected HsDirs:
```
Jan 04 14:26:57.777 [info] handle_response_fetch_hsdesc_v3(): Received v3 hsdesc (body size 0, status 404 ("Not found"))
```
The obvious suspect is the publisher, but the problem could also be in the IPT manager (e.g. maybe the service is failing to establish its desired number of intro points), or in the way we're computing the HsDir rings (maybe we are publishing the descriptor, but to the wrong HsDirs).gabi-250gabi-250https://gitlab.torproject.org/tpo/tpa/team/-/issues/41527install python3-sqlparse in polyanthum2024-03-11T12:25:55Zmeskiomeskio@torproject.orginstall python3-sqlparse in polyanthumAfter the upgrade to bookworm two weeks ago onbasca stopped working in polyanthum. It looks like is missing a dependency: python3-sqlparse
Can you install it?
I wonder how was removed by the upgrade.After the upgrade to bookworm two weeks ago onbasca stopped working in polyanthum. It looks like is missing a dependency: python3-sqlparse
Can you install it?
I wonder how was removed by the upgrade.Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41526Deploy onionperf files parser on metricsdb-012024-03-07T14:23:37ZHiroDeploy onionperf files parser on metricsdb-01We need to deploy https://gitlab.torproject.org/tpo/network-health/metrics/tor_fusion/ on metricsdb-01.
Basically this thing will run, download onionperf files from collector and parse them. This will just happen once a day around 1am UT...We need to deploy https://gitlab.torproject.org/tpo/network-health/metrics/tor_fusion/ on metricsdb-01.
Basically this thing will run, download onionperf files from collector and parse them. This will just happen once a day around 1am UTC as at midnight is when collector fetches the archives from the various onionperf clients.
It's a little rust app and was thinking to create a group and user like for the metrics-api. But maybe it's a bit overkill and I should just put it in the parser space?HiroHirohttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42415Improve focus styling for forced focus in bridge settings2024-02-14T10:21:05ZhenryImprove focus styling for forced focus in bridge settingsAs part of https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036, I set up a few places where we wanted to move focus to the start of an area by calling `.focus` on an element with `tabindex = -1`. This issue is just ...As part of https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036, I set up a few places where we wanted to move focus to the start of an area by calling `.focus` on an element with `tabindex = -1`. This issue is just to tidy up some of the focus styling of these elements for these rare moments where they have `:focus-visible`.henryhenryhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1279Implement VanguardHsPathBuilder2024-03-20T18:09:26Zgabi-250Implement VanguardHsPathBuilderOr modify the existing `ExitPathBuilder` to provide path selection using vanguards.Or modify the existing `ExitPathBuilder` to provide path selection using vanguards.Arti: Guard discovery researchgabi-250gabi-250https://gitlab.torproject.org/tpo/tpa/team/-/issues/41525gitlab not reachable over ipv6 from (at least) UK ISP Andrews and Arnold2024-03-06T15:07:47ZIan Jacksoniwj@torproject.orggitlab not reachable over ipv6 from (at least) UK ISP Andrews and Arnold```
zealot:~> ping gitlab.torproject.org
PING gitlab.torproject.org(gitlab-02.torproject.org (2a01:4f8:fff0:4f:266:37ff:feb8:3489)) 56 data bytes
```
That's from 2001:8b0:bb7b:4008:c50a:b4d5:6fc1:31f2.
Confirmed by other folks on `#a&a...```
zealot:~> ping gitlab.torproject.org
PING gitlab.torproject.org(gitlab-02.torproject.org (2a01:4f8:fff0:4f:266:37ff:feb8:3489)) 56 data bytes
```
That's from 2001:8b0:bb7b:4008:c50a:b4d5:6fc1:31f2.
Confirmed by other folks on `#a&a` at `irc.aachat.net`. Reports there suggest there might be a problem with Hetzner?
It's reachable from my personal colo, which is with Jump in London.
I don't know if this is a problem at the TPO end, or at the AAISP end. (It's quite inconvenient since it makes git push not work.)Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/1276Add vanguards info to the circuits in hspool::pool::Pool2024-03-20T18:09:25Zgabi-250Add vanguards info to the circuits in hspool::pool::PoolToday the pool contains a `Vec` of client circuits:
```rust
/// The collection of circuits themselves, in no particular order.
circuits: Vec<Arc<ClientCirc>>,
```
To support vanguards, we need to know for each circuit if it's
`STUB` or ...Today the pool contains a `Vec` of client circuits:
```rust
/// The collection of circuits themselves, in no particular order.
circuits: Vec<Arc<ClientCirc>>,
```
To support vanguards, we need to know for each circuit if it's
`STUB` or `STUB+`, and whether it is a vanguards-full or vanguards-lite
circuit. It should also be possible to disable vanguards altogether, so
this extra vanguards info should be optional.
This information will probably need to be returned, along with the `ClientCirc`,
from `CircMgr::launch_hs_unmanaged`. This could be included alongside
`ClientCirc`, or as a field within it (gated behind the `hs-common`
feature), depending on what we decide in #1274.Arti: Guard discovery researchgabi-250gabi-250https://gitlab.torproject.org/tpo/core/arti/-/issues/1275Design the `VanguardMgr` and/or `VanguardPool`2024-03-19T15:07:31Zgabi-250Design the `VanguardMgr` and/or `VanguardPool`TODO: split into multiple issuesTODO: split into multiple issuesArti: Guard discovery researchgabi-250gabi-250https://gitlab.torproject.org/tpo/core/arti/-/issues/1274Use vanguards path selection in CircMgr::launch_hs_unmanaged.2024-03-20T18:09:26Zgabi-250Use vanguards path selection in CircMgr::launch_hs_unmanaged.The path selection will be handled by `VanguardHsPathBuilder`
(a new type similar to, or based on, the existing `ExitPathBuilder`).
See #1279
`CircMgr::launch_hs_unmanaged` will need to take an extra argument
specifying whether to use ...The path selection will be handled by `VanguardHsPathBuilder`
(a new type similar to, or based on, the existing `ExitPathBuilder`).
See #1279
`CircMgr::launch_hs_unmanaged` will need to take an extra argument
specifying whether to use full or lite vanguards when building the circuits.
`CircMgr::launch_hs_unmanaged` will only create STUB circuits.
If full vanguards are enabled, the circuits will be extended
by one hop as needed (outside of `launch_hs_unmanaged`), whenever
a STUB+ circuit is required (based on the `HsCircKind`).
Alternatively, `CircMgr::launch_hs_unmanaged` could
take an argument that specifies whether the circuit to launch
is STUB or STUB+. We will likely also need a corresponding
`TargetCircUsage::HsCircBaseWithVanguards (full|lite)` for it.
Then, based on the `TargetCircUsage`, `TargetCircUsage::build_path`
can dispatch to `VanguardHsPathBuilder::pick_path` (as opposed to
the `ExitPathBuilder::pick_path` currently used for
`TargetCircUsage::HsCircBase).
Since `launch_hs_circuits_as_needed`
preemptively populates the `HsCircPool` with circuits, it will need
to be modified too (to launch both STUB and STUB+ circuits).
Prerequisites: #1275, #1277, #1279Arti: Guard discovery researchgabi-250gabi-250https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42414Show ellipsis when the tor bridge address overflows2024-02-14T10:20:22ZhenryShow ellipsis when the tor bridge address overflowsCurrently the ellipsis doesn't show, as intended in the mockup: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036/designs/lox-added.pngCurrently the ellipsis doesn't show, as intended in the mockup: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036/designs/lox-added.pnghenryhenry