The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-10-09T11:04:32Zhttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40168man page says 'destination' when it means 'destinations'2023-10-09T11:04:32ZRoger Dingledineman page says 'destination' when it means 'destinations'The sbws man page says
```
sbws (1) scanner command requires a configuration file with the "[scan‐
ner]", "[destinations]" "[destination.<name>]" sections.
There must be at least one "[destination.<name>]".
```
but...The sbws man page says
```
sbws (1) scanner command requires a configuration file with the "[scan‐
ner]", "[destinations]" "[destination.<name>]" sections.
There must be at least one "[destination.<name>]".
```
but in both of the cases where it says ```destination.<name>``` I think it means ```destinations.<name>```jugajugahttps://gitlab.torproject.org/tpo/network-health/tor-weather/-/issues/77Dependency Dashboard2023-10-17T16:36:38ZRenovate BotDependency DashboardThis issue lists Renovate updates and detected dependencies. Read the [Dependency Dashboard](https://docs.renovatebot.com/key-concepts/dashboard/) docs to learn more.
## Open
These updates have all been created already. Click a checkbo...This issue lists Renovate updates and detected dependencies. Read the [Dependency Dashboard](https://docs.renovatebot.com/key-concepts/dashboard/) docs to learn more.
## Open
These updates have all been created already. Click a checkbox below to force a retry/rebase of any.
- [ ] <!-- rebase-branch=renovate/flask-migrate-4.x-lockfile -->[fix(deps): update dependency flask-migrate to v4.0.5](!114)
- [ ] <!-- rebase-branch=renovate/flask-sqlalchemy-3.x-lockfile -->[fix(deps): update dependency flask-sqlalchemy to v3.1.1](!113)
## Detected dependencies
<details><summary>gitlabci</summary>
<blockquote>
<details><summary>.gitlab-ci.yml</summary>
</details>
</blockquote>
</details>
<details><summary>poetry</summary>
<blockquote>
<details><summary>pyproject.toml</summary>
- `python-dotenv *`
- `requests *`
- `psycopg2-binary *`
- `flask-assets *`
- `glob2 *`
- `pyscss *`
- `pyjwt *`
- `bcrypt *`
- `cryptography *`
- `flask *`
- `flask-restx *`
- `werkzeug *`
- `flask-sqlalchemy *`
- `flask-login *`
- `flask-migrate ^4.0.4`
- `black *`
- `flake8 *`
- `mypy *`
- `pytest *`
- `pytest-cov *`
- `isort *`
- `bandit *`
- `djlint *`
</details>
</blockquote>
</details>Renovate BotRenovate Bothttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40167Create new release 1.8.02023-10-09T11:02:03ZjugaCreate new release 1.8.0Since we have `minor` changes from last 1.7.0 release.Since we have `minor` changes from last 1.7.0 release.sbws: 1.8.x-finaljugajugahttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41317gitlab is slow(er than usual)2023-09-11T18:09:44Zanarcatgitlab is slow(er than usual)this morning gitlab slowed to a crawl. multiple users reported the site being barely usable, and i didn't even file an incident here at the time because it was so slow, filing this as a post-mortem.this morning gitlab slowed to a crawl. multiple users reported the site being barely usable, and i didn't even file an incident here at the time because it was so slow, filing this as a post-mortem.anarcatanarcathttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41316Please add rhatto@ to network-team@2023-09-11T15:51:00ZAlexander Færøyahf@torproject.orgPlease add rhatto@ to network-team@Please add rhatto@ to the network-team@ email alias so he can get updates on team stuff.Please add rhatto@ to the network-team@ email alias so he can get updates on team stuff.Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/131Moat distributor is sharing offline bridges2023-09-11T14:42:44ZGusMoat distributor is sharing offline bridgesMoat is distributing obfs4 bridges that are currently offline. By checking their fingerprint on Metrics, it appears that these bridges no longer exist.
Reported via Tor forum: https://forum.torproject.org/t/bridges-requested-in-tb-do-...Moat is distributing obfs4 bridges that are currently offline. By checking their fingerprint on Metrics, it appears that these bridges no longer exist.
Reported via Tor forum: https://forum.torproject.org/t/bridges-requested-in-tb-do-not-work-only-the-ones-built-in/9172/2meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/network-health/metrics/onionoo/-/issues/40037Add transport to summary document and implement search filter2023-09-14T16:17:10ZHiroAdd transport to summary document and implement search filterNeeded for: https://gitlab.torproject.org/tpo/network-health/metrics/website/-/merge_requests/57Needed for: https://gitlab.torproject.org/tpo/network-health/metrics/website/-/merge_requests/57HiroHirohttps://gitlab.torproject.org/tpo/network-health/depictor/-/issues/26AuthDirMaxServersPerAddr consensus pseudo-parameter shown in red2023-10-13T20:44:45Ztrinity-1686aAuthDirMaxServersPerAddr consensus pseudo-parameter shown in red`AuthDirMaxServersPerAddr=8` consensus pseudo-parameters is currently shown in red despite all reachable authorities agreeing on it
![image](/uploads/0319914144747af803cc5ac4b085c58a/image.png)
Note that it isn't a true consensus parame...`AuthDirMaxServersPerAddr=8` consensus pseudo-parameters is currently shown in red despite all reachable authorities agreeing on it
![image](/uploads/0319914144747af803cc5ac4b085c58a/image.png)
Note that it isn't a true consensus parameter in the sens that tor never actually look at it, and it's primarily made for operators to not have to guess how many relay they can host on a single IP before being flagged Sybil. That said, since `0.4.8.1-alpha` authorities include that consensus parameter by default in their voteTom Rittertom@ritter.vgTom Rittertom@ritter.vghttps://gitlab.torproject.org/tpo/network-health/metrics/onionoo/-/issues/40036TOR-016 — oonionoo – Potential denial of service on onionoo.torproject.org vi...2023-10-19T17:43:17ZGabagaba@torproject.orgTOR-016 — oonionoo – Potential denial of service on onionoo.torproject.org via search parameterThe oonionoo.torproject.org website suffers from a potential denial of service vulnerability through the StringBuilder.append method.
- Vulnerability ID: TOR-016
- Vulnerability type: CWE-789: Memory Allocation with Excessive Size Value...The oonionoo.torproject.org website suffers from a potential denial of service vulnerability through the StringBuilder.append method.
- Vulnerability ID: TOR-016
- Vulnerability type: CWE-789: Memory Allocation with Excessive Size Value
- Threat level: Low
Technical description:
The onionoo API allows filtering data based on a search parameter. If a double quote occurs in the search string, the
variable doubleQuotedSearchTerm is instantiated with an object from the StringBuilder class. The class is
vulnerable to a denial of service attack because when the append method is called, the capacity of the string buffer is
doubled if the actual buffer is too small. This can quickly cause the JVM to consume all available heap memory space,
though this is difficult to achieve through GET requests (see impact below).
In tpo/network-health/metrics/onionoo/src/main/java/org/torproject/metrics/onionoo/server/ResourceServlet.java:
```
protected static String[] parseSearchParameters(String parameter) {
String[] spaceSeparatedParts = parameter.split(" ");
List<String> searchParameters = new ArrayList<>();
StringBuilder doubleQuotedSearchTerm = null;
for (String spaceSeparatedPart : spaceSeparatedParts) {
if ((StringUtils.countMatches(spaceSeparatedPart, '"')
- StringUtils.countMatches(spaceSeparatedPart, "\\\"")) % 2 == 0) {
if (null == doubleQuotedSearchTerm) {
searchParameters.add(spaceSeparatedPart);
} else {
doubleQuotedSearchTerm.append(' ').append(spaceSeparatedPart);
}
} else {
if (null == doubleQuotedSearchTerm) {
doubleQuotedSearchTerm = new StringBuilder(spaceSeparatedPart);
} else {
doubleQuotedSearchTerm.append(' ').append(spaceSeparatedPart);
searchParameters.add(doubleQuotedSearchTerm.toString());
doubleQuotedSearchTerm = null;
}
}
}
....
}
```
Proof of Concept
```
Payload:
a:"X AAAA BBBBBBBBB "
Flow:
1. doubleQuotedSearchTerm = new StringBuilder('a:"X');
2. append on doubleQuotedSearchTerm with whitespace and AAAA
3. append on doubleQuotedSearchTerm with whitespace and BBBBBBBBB
4. close doubleQuotedSearchTerm and store in list (spaceSeparatedParts)
```
Impact:
Because of the limited GET request URI length, not enough characters can be transferred to consume the available heap memory. Therefore, this vulnerability is rated Low. However, it might be possible to exploit the vulnerability in the future, e.g., if the function is used for a POST request or the standard GET request URI length is increased by a configuration.
Recommendation: Catch the OutOfMemoryError exception thrown by the JVM and then abort the whole parsing process.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/network-health/tor-weather/-/issues/76Dependency Dashboard2023-10-17T16:36:38ZRenovate BotDependency DashboardThis issue lists Renovate updates and detected dependencies. Read the [Dependency Dashboard](https://docs.renovatebot.com/key-concepts/dashboard/) docs to learn more.
## Open
These updates have all been created already. Click a checkbo...This issue lists Renovate updates and detected dependencies. Read the [Dependency Dashboard](https://docs.renovatebot.com/key-concepts/dashboard/) docs to learn more.
## Open
These updates have all been created already. Click a checkbox below to force a retry/rebase of any.
- [ ] <!-- rebase-branch=renovate/pytest-7.x-lockfile -->[chore(deps): update dependency pytest to v7.4.2](!111)
- [ ] <!-- rebase-branch=renovate/black-23.x-lockfile -->[chore(deps): update dependency black to v23.9.1](!112)
## Detected dependencies
<details><summary>gitlabci</summary>
<blockquote>
<details><summary>.gitlab-ci.yml</summary>
</details>
</blockquote>
</details>
<details><summary>poetry</summary>
<blockquote>
<details><summary>pyproject.toml</summary>
- `python-dotenv *`
- `requests *`
- `psycopg2-binary *`
- `flask-assets *`
- `glob2 *`
- `pyscss *`
- `pyjwt *`
- `bcrypt *`
- `cryptography *`
- `flask *`
- `flask-restx *`
- `werkzeug *`
- `flask-sqlalchemy *`
- `flask-login *`
- `flask-migrate ^4.0.4`
- `black *`
- `flake8 *`
- `mypy *`
- `pytest *`
- `pytest-cov *`
- `isort *`
- `bandit *`
- `djlint *`
</details>
</blockquote>
</details>Renovate BotRenovate Bothttps://gitlab.torproject.org/tpo/network-health/metrics/library/-/issues/40021TOR-021 — metrics-lib – Denial of service in DescriptorImpl getRawDescriptorB...2023-10-19T17:42:58ZGabagaba@torproject.orgTOR-021 — metrics-lib – Denial of service in DescriptorImpl getRawDescriptorBytes via descriptor fileThe metrics-lib is vulnerable to a DoS attack if attackers can pass it an arbitrary descriptor file.
The exploitation of this vulnerability leads to a denial of service. Depending on the usage, it can terminate the entire application tha...The metrics-lib is vulnerable to a DoS attack if attackers can pass it an arbitrary descriptor file.
The exploitation of this vulnerability leads to a denial of service. Depending on the usage, it can terminate the entire application that imports the metrics-lib if attackers have control over the contents of a descriptor file.
- Vulnerability type: CWE-789: Memory Allocation with Excessive Size Value
- Threat level: Moderate.
Recommendation: Catch the OutOfMemoryError exception thrown by the JVM and abort the whole parsing process.Georg KoppenGeorg Koppen2023-09-22https://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/40097TOR-017 — website – Outdated Jetty version on metrics.torproject.org2023-10-19T17:43:11ZGeorg KoppenTOR-017 — website – Outdated Jetty version on metrics.torproject.orgTechnical description:
While performing a deep dive into the codebase of the Tor metrics website, we found that it uses an outdated Jetty version from 2015. However, with the Jetty server and codebase of the project, older dependencies ...Technical description:
While performing a deep dive into the codebase of the Tor metrics website, we found that it uses an outdated Jetty version from 2015. However, with the Jetty server and codebase of the project, older dependencies that suffer from publicly known security vulnerabilities are shipped. We then confirmed that the public site https://metrics.torproject.org/ uses a Jetty version from 2015 as shown in the HTTP response below.
**Request**
```
GET / HTTP/1.1
Host: metrics.torproject.org
Content-Length: 2
```
**Response**
```
HTTP/1.1 200 OK
Date: Thu, 27 Jul 2023 16:38:38 GMT
Server: Jetty(9.2.z-SNAPSHOT)
```
A more detailed specification of the probable Jetty version (9.2.21.v20170120) can be found in a public repository. In tpo/network-health/metrics/website/-/blob/master/build.xml:
```
<?xml version="1.0"?>
<project default="usage" name="metrics-web" basedir="."
xmlns:ivy="antlib:org.apache.ivy.ant">
<property name="javadoc-title" value="MetricsWeb API Documentation"/>
<property name="jetty.version" value="-9.2.21.v20170120" />
```
Impact:
Due to limited time, verifying the Jetty server for various known vulnerabilities, such as CVE-2021-28165 was not feasible. However, the impact of the known vulnerabilities can range from pre-auth denial of service to remote code execution.
Recommendation:
Upgrade the Jetty server to the latest version to prevent possible attacks on Tor's infrastructure.HiroHiro2023-09-21https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42079TorConnect: handle switching from Bootstrapped to Configuring state2023-10-03T13:27:40ZhenryTorConnect: handle switching from Bootstrapped to Configuring statehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests/721 is going to enable switching from the "Bootstrapped" state to the "Configuring" state when the underlying tor process exits after bootstrapping has first suc...https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests/721 is going to enable switching from the "Bootstrapped" state to the "Configuring" state when the underlying tor process exits after bootstrapping has first succeeded. The idea is that we can re-bootstrap with the new tor process.
This could probably do with some general testing to see how well we recover in this case.
We also have some UI elements that assumed we would never leave the "Bootstrapped" state once it was reached. We should change them now that this assumption is broken.
/cc @pierov @richardhenryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40950Prepare Mullvad Browser 13.0a52023-10-03T15:01:07ZrichardPrepare Mullvad Browser 13.0a5<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
- [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-alpha` to get updated hashes
- [x] `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
- [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/
- [ ] ***(Optional)*** If new version available, update `ublock-origin` section of `input_files` in `projects/browser/config`
- [ ] `URL`
- [ ] `sha256sum`
- [x] Check for Mullvad Privacy Companion 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`
- [x] Update `ChangeLog-MB.txt`
- [x] Ensure ChangeLog-MB.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
- [ ] Run `tools/fetch-changelogs.py $(TOR_BROWSER_VERSION)` or `tools/fetch-changelogs.py '#$(ISSUE_NUMBER)'`
- 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
- [ ] Copy the output of the script to the beginning of `ChangeLog-MB.txt` and update its output
- [ ] Version
- [ ] Browser Name
- [ ] Release Date
- [ ] Under `All Platforms` include any version updates for:
- NoScript
- uBlock-origin
- Mullvad Browser Extension
- Firefox
- [x] Open MR with above changes
- [x] Build the MR after initial review on at least two of:
- [x] Tor Project build machine
- [ ] Mullvad build machine
- [x] Local developer machine
- [x] Ensure builders have matching builds
- [x] Merge
- [x] Sign+Tag
- **NOTE** this must be done by one of:
- boklm
- dan
- ma1
- pierov
- richard
- [x] Run: `make mullvadbrowser-signtag-alpha`
- [x] Push tag to `origin`
</details>
<details>
<summary>QA</summary>
### send the build
- [x] Email Mullvad QA: support@mullvad.net, rui@mullvad.net
<details>
<summary>email template</summary>
Subject:
New build: Mullvad Browser $(MULLVAD_BROWSER_VERION) (unsigned)
Body:
unsigned builds: https://tb-build-05.torproject.org/~$(BUILDER)/builds/mullvadbrowser/alpha/unsigned/$(MB_BUILD_TAG)
changelog:
...
</details>
- ***(Optional)*** Add additional information:
- [ ] Note any new functionality which needs testing
- [ ] Link to any known issues
</details>
<details>
<summary>Signing</summary>
### signing
- [x] Assign this issue to the signer, one of:
- boklm
- richard
- [x] On `$(STAGING_SERVER)`, ensure updated:
- [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
- `ssh_host_macos_signer` : ssh hostname of macOS signing machine
- [x] `tor-browser-build/tools/signing/set-config.macos-notarization`
- `macos_notarization_user` : the email login for a mullvad notariser Apple Developer account
- [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, run the macOS proxy script:
- `cd tor-browser-build/tools/signing/`
- `./macos-signer-proxy`
- [x] On `$(STAGING_SERVER)` in a separate `screen` session, ensure tor daemon is running with SOCKS5 proxy on the default port 9050
- [x] 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`:
- [ ] Static update components : `static-update-component dist.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.5a7`
- **Message**: `$(ESR_VERSION)esr-based $(MULLVAD_BROWSER_VERSION)`
- **example** : `102.12.0esr-based 12.5a7`
- [x] Push tag to github
### email
- [x] Email Mullvad with release information: support@mullvad.net, rui@mullvad.net
<details>
<summary>email template</summary>
Subject:
New build: Mullvad Browser $(MULLVAD_BROWSER_VERION) (signed)
Body:
signed builds: https://dist.torproject.org/mullvadbrowser/$(MULLVAD_BROWSER_VERSION)
update_response hashes: $(MULLVAD_UPDATE_RESPONSES_HASH)
changelog:
...
</details>
</details>
<details>
<summary>Downstream</summary>
### notify packagers
- [ ] **(Optional, Once Mullvad Updates their Github Releases Page)** 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
<details>
<summary>email template</summary>
Hello!
Mullvad-Browser $(MULLVAD_BROWSER_VERSION) packages are available, so you should all update your respective downstream packages.
Release builds can be found here:
- https://github.com/mullvad/mullvad-browser/releases/tag/$(MULLVAD_BROWSER_VERSION)
</details>
- flathub package maintainer: proletarius101@protonmail.com
- arch package maintainer: bootctl@gmail.com
- nixOS package maintainer: dev@felschr.com
</details>richardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40949Prepare Tor Browser Alpha 13.0a52023-10-03T15:01:10ZrichardPrepare Tor Browser Alpha 13.0a5<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
- [x] ***(Optional)*** `var/firefox_platform_version` : update to latest `$(ESR_VERSION)` if rebased
- [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 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`:
- [ ] `fenix_version` : update to match alpha `firefox-android` build tag
- [x] `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`
- [ ] 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/
- [x] ***(Optional)*** If new 3.0.X version available, update `projects/openssl/config`
- [x] `version` : update to next 3.0.X version
- [x] `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
- [x] ***(Optional)*** Update `projects/tor/config`
- [x] `version` : update to latest `-alpha` tag or release tag if newer (ping dgoulet or ahf if unsure)
- [x] Check for go updates here : https://golang.org/dl
- **NOTE** : Tor Browser Alpha uses the latest Stable major series go version
- [ ] ***(Optional)*** Update `projects/go/config`
- [ ] `version` : update go version
- [ ] `input_files/sha256sum` for `go` : update sha256sum of archive (sha256 sums are displayed on the go download page)
- [x] 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 people.tpo
- [x] Update `projects/manual/config`:
- [x] Change the `version` to `$PIPELINEID`
- [x] Update `sha256sum` in the `input_files` section
- [ ] ***(Optional)*** Update the URL if you have uploaded to a different people.tpo home
- [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 $(TOR_BROWSER_VERSION)` or `tools/fetch-changelogs.py '#$(ISSUE_NUMBER)'`
- 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
- [x] Copy the output of the script to the beginning of `ChangeLog-TBB.txt` and update its output
- [x] Version
- [x] Browser Name
- [x] Release Date
- [x] Under `All Platforms` include any version updates for:
- NoScript
- tor
- OpenSSL
- lyrebird
- Snowflake
- [x] Under `Windows + macOS + Linux` include any version updates for:
- Firefox
- [x] Under `Android` include any version updates for:
- Geckoview
- [ ] Under `Windows + Android` include any version updates for:
- zlib
- [ ] Under `Build System/All Platforms` include any version updates for:
- Go
- [x] Open MR with above changes
- [x] Build the MR after initial review on at least two of:
- [x] Tor Project build machine
- [x] Mullvad build machine
- [x] Local developer machine
- [x] Ensure builders have matching builds
- [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 `origin`
</details>
<details>
<summary>Communications</summary>
### notify stakeholders
- [x] Email tor-qa mailing list: tor-qa@lists.torproject.org
<details>
<summary>email template</summary>
Subject:
Tor Browser $(TOR_BROWSER_VERION) (Android, Windows, macOS, Linux)
Body:
Hello All,
Unsigned Tor Browser $(TOR_BROWSER_VERSION) alpha candidate builds are now available for testing:
- https://tb-build-05.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
</details>
- ***(Optional)*** Additional information:
- [ ] Note any new functionality which needs testing
- [ ] Link to any known issues
- [ ] ***(Optional, only around build/packaging changes)*** Email packagers:
- Recipients:
- Tails dev mailing list: tails-dev@boum.org
- Guardian Project: nathan@guardianproject.info
- torbrowser-launcher: micah@micahflee.com
- 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
- [ ] Email external partners:
- ***(Optional, after ESR migration)*** 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
</details>
<details>
<summary>Signing</summary>
### 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
- `ssh_host_macos_signer` : ssh hostname of macOS signing machine
- [x] `tor-browser-build/tools/signing/set-config.macos-notarization`
- `macos_notarization_user` : the email login for a tor notariser Apple Developer account
- [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, run the macOS proxy script:
- `cd tor-browser-build/tools/signing/`
- `./macos-signer-proxy`
- [x] On `$(STAGING_SERVER)` in a separate `screen` session, ensure tor daemon is running with SOCKS5 proxy on the default port 9050
- [x] 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`:
- [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`
- [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`
- [ ] Static update components (again) : `static-update-component cdn.torproject.org && static-update-component dist.torproject.org`
- [x] Publish APKs to Google Play:
- Log into https://play.google.com/apps/publish
- Select `Tor Browser (Alpha)` app
- Navigate to `Release > Production` and click `Create new release` button:
- Upload the `*.multi.apk` APKs
- 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
- [x] 100% rollout when publishing a security-driven release
- [ ] Update rollout percentage to 100% after confirmed no major issues
</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>
### 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 uploaded
- [x] Merge
- [x] Publish after CI passes and builds are published
### blog: https://gitlab.torproject.org/tpo/web/blog.git
- [x] Duplicate previous Stable or Alpha release blog post as appropriate to new directory under `content/blog/new-release-tor-browser-$(TOR_BROWSER_VERSION)` and update with info on release :
- [ ] 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)
- [ ] Update Tor Browser version numbers
- [ ] Note any ESR rebase
- [ ] Link to any Firefox security updates from ESR upgrade
- [ ] Link to any Android-specific security backports
- [ ] Note any updates to :
- tor
- OpenSSL
- NoScript
- [ ] Convert ChangeLog-TBB.txt to markdown format used here by :
- `tor-browser-build/tools/changelog-format-blog-post`
- [x] Push to origin as new branch, open `Draft:` MR
- [x] Remove `Draft:` from MR once signed-packages are uploaded
- [x] Merge
- [x] Publish after CI passes and website has been updated
### tor-announce mailing list
- [x] Email tor-announce mailing list: tor-announce@lists.torproject.org
<details>
<summary>email template</summary>
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)
</details>
- **(Optional)** Additional information:
- [ ] Link to any known issues
</details>richardrichardhttps://gitlab.torproject.org/tpo/team/-/issues/215Check about this s112 indicator for objective 12023-10-24T13:49:52ZGabagaba@torproject.orgCheck about this s112 indicator for objective 1Check with @gk about this indicator "Time (in hours) from beginning to end of a investigation on a suspected malicious relay." It is used to measure outcome of objective 1.
It seems that there are some factors out of our control that i...Check with @gk about this indicator "Time (in hours) from beginning to end of a investigation on a suspected malicious relay." It is used to measure outcome of objective 1.
It seems that there are some factors out of our control that influence that indicator. Let's see if we can redefine it so it does not take into account the replies from directory authorities. Otherwise we can remove it.
If we remove this indicator, can we have an indicator that we track for the outcomes on objective 1 based on the new metrics in https://gitlab.torproject.org/tpo/network-health/team/-/issues/299 ?Gabagaba@torproject.orgGabagaba@torproject.org2023-10-23https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42076Theme is visible in options, but shouldn't be2023-12-05T22:05:58ZclairehurstTheme is visible in options, but shouldn't be### Summary
Due to anti finger printing, we don't allow the user to change the theme (its always purple, not dark or light). We have a setting to change the theme that doesn't do anything and should be removed.
### Steps to reproduce:
...### Summary
Due to anti finger printing, we don't allow the user to change the theme (its always purple, not dark or light). We have a setting to change the theme that doesn't do anything and should be removed.
### Steps to reproduce:
1. Launch tor browser for android
2. Connect to tor
3. Tap on the ⋮ button in the bottom right, then navigate to > Settings > Customize and notice that there is a Theme option
### What is the current bug behavior?
There is an option to set the theme to Light, Dark, or to follow the device theme (shown in screenshot below)
### What is the expected behavior?
There should not be an option to set the theme, because we don't use it
### Environment
Which operating system are you using? macOS Ventura 13.5.1, apple M2 Max, Pixel 7 pro API 34 (arm 64 emulator)
Which installation method did you use? Git
### Relevant logs and/or screenshots
![Screenshot_2023-09-05_at_4.25.39_PM](/uploads/6a6e64b952649dd74435333e3d2e02a1/Screenshot_2023-09-05_at_4.25.39_PM.png)clairehurstclairehursthttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42075Fix link spacing and underline on new homepage2023-10-03T13:27:42ZdonutsFix link spacing and underline on new homepageIn about:preferences for example, there is a standard gap between the string and link of around 10px. The underline style also looks more noticeable in about:preferences too – i.e. it seems to be offset slightly against the text, and is ...In about:preferences for example, there is a standard gap between the string and link of around 10px. The underline style also looks more noticeable in about:preferences too – i.e. it seems to be offset slightly against the text, and is thicker.
Could we update the link style on the new homepage (i.e. new tab page; about:tor) to match please?
(Also, as mentioned previously – the new homepage should be using system fonts like other internal pages rather than Arial/Helvetica – however this may have been fixed since the last macOS Nightly already)henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42074YEC 2023 Takeover for Android Stable2023-11-27T14:41:42ZnicobYEC 2023 Takeover for Android StableEach year from <span dir="">\~</span>mid-October through the end of December, the Tor Project runs its year-end fundraising campaign (aka "YEC"). This is the time during which we raise the most money per year from individual donors. A ke...Each year from <span dir="">\~</span>mid-October through the end of December, the Tor Project runs its year-end fundraising campaign (aka "YEC"). This is the time during which we raise the most money per year from individual donors. A key strategy in this campaign is a branded takeover of about:tor (desktop + mobile) that includes the year-end campaign "mini brand," new assets, a fundraising message, and a donate button. cc @richard
Key dates:
* **Monday, October 16** - gated YEC takeover of about:tor appears
* **Monday, November 13** - second gated YEC takeover of about:tor appears
**Please note that the current illustration within these designs is a placeholder**, and the final illustration asset will be shared soon when it's finalized. Aside from that, everything here has been approved to begin implementation:
* Figma files for inspection: [23 Year End Campaign](https://www.figma.com/file/f8KvYdzeZPvs4KpJMLJumD/23-Year-End-Campaign?type=design&node-id=27%3A11557&mode=design&t=DzYvge9oyxXoCu6K-1)
* Illustration:[yec-illustration-android.svg](/uploads/093aeed7ba10b9ae7b3d1675d67c9229/yec-illustration-android.svg)
* heart svg for button:[heart.svg](/uploads/181b77f5cd7abad67379bbf4e27df3f9/heart.svg)
* Font: `Roboto`
* Background color: `#1F0333`
* Text color: `#FBFBFE`
* Button background color: `#FFBD4F`
* Button text color: `#1F0333`
* Can we anchor the donate button to the main content area of donate.torproject.org again like last year? @smith please chime in here if there's a specific redirect URL link you're using for metrics
Last year's ticket for reference: [YEC 2022 Takeover for Android Stable](https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41302 "YEC 2022 Takeover for Android Stable")
about:tor android mockup:
![about_tor-android2x.png](/uploads/e6c3555a5d60c503b5ee73d0d49bae43/about_tor-android2x.png){width=298 height=629}
about:tor android LTR mockup:
![about_tor-android-LTR2x.png](/uploads/b811c4ae136bec35bbc0e6a0ecbf321c/about_tor-android-LTR2x.png){width=301 height=636}Year End Campaign 2023Dan BallardDan Ballardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42073Add simplified onion pattern to the new homepage2023-10-03T13:27:43ZdonutsAdd simplified onion pattern to the new homepageSince we never got round to finishing and handing over the wallpaper gallery, let's retain a simplified version of the onion patter on the homepage for the time being instead:
![new-tab-classic](/uploads/fdf07fa8b76f650fbbc52dd392593eb0...Since we never got round to finishing and handing over the wallpaper gallery, let's retain a simplified version of the onion patter on the homepage for the time being instead:
![new-tab-classic](/uploads/fdf07fa8b76f650fbbc52dd392593eb0/new-tab-classic.png)
Like the existing onion pattern, it should repeat horizontally. Here's an SVG exported from Figma:
- [classic-pattern.svg](/uploads/141f3d7139fbfea739f11744f2448814/classic-pattern.svg)henryhenry