The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-03-28T15:26:58Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42192Correctly round new windows when bookmarks toolbar is set to "Only Show on Ne...2024-03-28T15:26:58ZdonutsCorrectly round new windows when bookmarks toolbar is set to "Only Show on New Tab"This has happened at least twice to me, but I have no idea how to reproduce it.
On first launch, the viewport in Tor Browser 13.0 is 900px high and unletterboxed. After a period of several days, an additional 30px appears to get added t...This has happened at least twice to me, but I have no idea how to reproduce it.
On first launch, the viewport in Tor Browser 13.0 is 900px high and unletterboxed. After a period of several days, an additional 30px appears to get added to the height of the overall window, increasing the viewport to 930px and triggering letterboxing.
Note: this is not due to changes in the height of the browser chrome eating into the viewport (e.g. the bookmarks bar being on or off), as the height of the entire window has increased by 30px.
Tor Browser will then reliably reopen itself at the new dimensions even when quit and relaunched. Wiping the TorBrowser-Data file from macOS' Application Support folder seems to reset the browser back to its original dimensions, however.
<details><summary>Show screenshot</summary>
![letterboxing-error](/uploads/a23e2bbbad31b4a4d0ac2d6a33f1c445/letterboxing-error.png)
</details>ma1ma1https://gitlab.torproject.org/tpo/tpa/team/-/issues/41363Review and upload new sbws Debian release 1.8.1-12023-10-23T14:48:31ZjugaReview and upload new sbws Debian release 1.8.1-1Code at https://salsa.debian.org/juxor-guest/sbws
For tpo/network-health/sbws#40187
Thanks @lavamind !Code at https://salsa.debian.org/juxor-guest/sbws
For tpo/network-health/sbws#40187
Thanks @lavamind !Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40875From coverity: possible memory leak. (CID 1547857)2023-10-30T16:52:23ZNick MathewsonFrom coverity: possible memory leak. (CID 1547857)```
*** CID 1547857: Resource leaks (RESOURCE_LEAK)
/src/core/or/connection_edge.c: 4239 in connection_exit_begin_resolve()
4233 case DOS_STREAM_DEFENSE_NONE:
4234 break;
4235 case DOS_STREAM_DEFENSE_REFUSE_ST...```
*** CID 1547857: Resource leaks (RESOURCE_LEAK)
/src/core/or/connection_edge.c: 4239 in connection_exit_begin_resolve()
4233 case DOS_STREAM_DEFENSE_NONE:
4234 break;
4235 case DOS_STREAM_DEFENSE_REFUSE_STREAM:
4236 dns_send_resolved_error_cell(dummy_conn, RESOLVED_TYPE_ERROR_TRANSIENT);
4237 return 0;
4238 case DOS_STREAM_DEFENSE_CLOSE_CIRCUIT:
>>> CID 1547857: Resource leaks (RESOURCE_LEAK)
>>> Variable "dummy_conn" going out of scope leaks the storage it points to.
4239 return -END_CIRC_REASON_RESOURCELIMIT;
4240 }
4241
4242 /* send it off to the gethostbyname farm */
4243 switch (dns_resolve(dummy_conn)) {
4244 case -1: /* Impossible to resolve; a resolved cell was sent. */
```trinity-1686atrinity-1686ahttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40189Replace links to gitweb.tpo to gitlab.tpo2023-11-27T13:19:52ZjugaReplace links to gitweb.tpo to gitlab.tposbws: 1.9.x-finaljugajugahttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41362gitlab artifacts runner failure2023-10-31T13:33:18ZIan Jacksoniwj@torproject.orggitlab artifacts runner failureThanks for switching from docker to podman. Things are much much better now. So much better that it seems worth reporting this failure, even though as far as I'm aware it only happened once:
https://gitlab.torproject.org/nickm/arti/-/...Thanks for switching from docker to podman. Things are much much better now. So much better that it seems worth reporting this failure, even though as far as I'm aware it only happened once:
https://gitlab.torproject.org/nickm/arti/-/jobs/391016
> ERROR: Downloading artifacts from coordinator... error couldn't execute GET against https://gitlab.torproject.org/api/v4/jobs/391013/artifacts?direct_download=true: Get "https://gitlab.torproject.org/api/v4/jobs/391013/artifacts?direct_download=true": dial tcp: lookup gitlab.torproject.org on 8.8.4.4:53: dial udp 8.8.4.4:53: connect: network is unreachable id=391013 token=64_vXqrz
Was there a known outage about 16h ago? FTR in !1663 we changed the way we handle artifacts so that they aren't done by the `after_script` any more. So while I'm not confident that this isn't a bug in our CI setup, I don't think it's *that* bug.
CC @trinity-1686aJérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/web/donate-static/-/issues/130Amendments to donate.tpo for YEC 20232023-10-19T19:23:12ZnicobAmendments to donate.tpo for YEC 2023Hi @lavamind, I just noticed two things on the donate page, could you update these when you have the chance? thank you!
* Can you update the meta image that populates for share links? right now its still using an image from last year's ...Hi @lavamind, I just noticed two things on the donate page, could you update these when you have the chance? thank you!
* Can you update the meta image that populates for share links? right now its still using an image from last year's campaign.
* [meta-web-yec-2023.png](/uploads/0142f6c09d8f9c39404798f637e21435/meta-web-yec-2023.png)
* The t-shirt, t-shirt pack, and hoodie images on the donate page look like they are only at 70% max width, can we change it to 100% so the images are larger within the containers?Year End Campaign 2023Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40987Prepare Mullvad Browser Stable 13.0.42023-11-24T16:35:23ZrichardPrepare Mullvad Browser Stable 13.0.4<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
<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
- **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
- [ ] `steps/base-browser-fluent/git_hash` : update with `HEAD` commit of project's `basebrowser-newidentityftl` 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 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] Open MR with above changes
- [x] Merge
- [x] Sign/Tag commit: `make mullvadbrowser-signtag-release`
- [x] Push tag to `origin`
- [x] Begin build on `$(BUILD_SERVER)` (fix any issues in subsequent MRs)
- [ ] **TODO** Submit build-tag to Mullvad build infra
- [x] Ensure builders have matching builds
</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/release/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] On `$(STAGING_SERVER)`, ensure updated:
- [ ] `tor-browser-build/tools/signing/set-config.hosts`
- `ssh_host_builder` : ssh hostname of machine with unsigned builds
- **NOTE** : `tor-browser-build` is expected to be in the `$HOME` directory)
- `ssh_host_linux_signer` : ssh hostname of linux signing machine
- `ssh_host_macos_signer` : ssh hostname of macOS signing machine
- [ ] `tor-browser-build/tools/signing/set-config.macos-notarization`
- `macos_notarization_user` : the email login for a mullvad notariser Apple Developer account
- [ ] `set-config.update-responses`
- `update_responses_repository_dir` : directory where you cloned `git@gitlab.torproject.org:tpo/applications/mullvad-browser-update-responses.git`
- [ ] `tor-browser-build/tools/signing/set-config.tbb-version`
- `tbb_version` : mullvad browser version string, same as `var/torbrowser_version` in `rbm.conf` (examples: `11.5a12`, `11.0.13`)
- `tbb_version_build` : the tor-browser-build build number (if `var/torbrowser_build` in `rbm.conf` is `buildN` then this value is `N`)
- `tbb_version_type` : either `alpha` for alpha releases or `release` for stable releases
- [ ] On `$(STAGING_SERVER)` in a separate `screen` session, 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`:
- [x] 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>
### 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>
### mullvad-browser (github): https://github.com/mullvad/mullvad-browser/
- [ ] 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
</details>
<details>
<summary>Downstream</summary>
### notify packagers
- [x] **(Once Mullvad Updates their Github Releases Page)** Email downstream consumers:
<details>
<summary>email template</summary>
...
...
</details>
- [ ] flathub package maintainer: proletarius101@protonmail.com
- [ ] arch package maintainer: bootctl@gmail.com
- [ ] nixOS package maintainer: dev@felschr.com
### merge requests
- [x] homebrew: https://github.com/Homebrew/homebrew-cask/blob/master/Casks/mullvad-browser.rb
- **NOTE**: should just need to update the version to latest
</details>richardrichardhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41361backup server (bungei) volume filled up2023-11-21T21:41:33ZJérôme Charaouilavamind@torproject.orgbackup server (bungei) volume filled upBacula backups have started failing today, amid warnings about free space on the server.
@anarcat investigated and found out that `archive-01` that has grown seemingly out of control:
> yep, so archive-01's /srv/archive.torproject.org/...Bacula backups have started failing today, amid warnings about free space on the server.
@anarcat investigated and found out that `archive-01` that has grown seemingly out of control:
> yep, so archive-01's /srv/archive.torproject.org/htdocs/tor-package-archive/torbrowser is 5TB
Space reservation was reduced from 0.5 to 0.01 percent which should give enough room for the upcoming backup to succeed.
Next steps:
- [x] reduce reserved space
- [x] grow logical volume
- [x] unlock mounts
- [x] make sure the archive-01 job completes
- [x] make sure all backups have ran in the last 24h (ie. make nagios green again)
- [x] open a ticket for or just make a plan for the next time
- [x] document this in the backup pager playbookanarcatanarcathttps://gitlab.torproject.org/tpo/core/arti/-/issues/1071API and CLI for obtaining K_hsid2023-12-14T16:29:27ZIan Jacksoniwj@torproject.orgAPI and CLI for obtaining K_hsid~~Probably this should be logged at level DEBUG at least. Without this, we'll not really be able to do an ad-hoc test since we won't know what `.onion` to try to connect to.~~
We log a newly-generated K_hsid since !1689, but there shou...~~Probably this should be logged at level DEBUG at least. Without this, we'll not really be able to do an ad-hoc test since we won't know what `.onion` to try to connect to.~~
We log a newly-generated K_hsid since !1689, but there should be:
1. An API that lets you get the K_hsid from a running hidden service (if it knows it, which it might not...)
2. A CLI operation that does the aboveArti: Onion service supportgabi-250gabi-250https://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/33Implement reasonable handling for bridge blocking2023-11-29T16:30:32ZonyinyangImplement reasonable handling for bridge blockingCurrently the Lox distributor does not handle blocked bridges at all. This is due to two main issues. The first is that we do not yet have a well-established method for determining that a bridge is indeed blocked. The second is that when...Currently the Lox distributor does not handle blocked bridges at all. This is due to two main issues. The first is that we do not yet have a well-established method for determining that a bridge is indeed blocked. The second is that when bridges are blocked, they are blocked in some locations and not others and we have not yet come to consensus on how this should be handled by Lox.
For our alpha deployment however, we should have some kind of alpha solution.
For now, we will assume some `target` country and search for whether or not that country appears in the `blocked_in` list that Lox will receive for each resource from rdsys. If the `target` country is in the list, the bridge will be marked as blocked.onyinyangonyinyanghttps://gitlab.torproject.org/tpo/community/policies/-/issues/11Core contributors are not getting invited to Tor meetings anymore by default2024-03-25T19:45:30ZGeorg KoppenCore contributors are not getting invited to Tor meetings anymore by defaultWe learned that our Tor meeting invitation policy is not reflecting our membership document anymore. There it says (among other things):
```
Core Contributorship has the following privileges...
* Standing invitation to the periodic Tor...We learned that our Tor meeting invitation policy is not reflecting our membership document anymore. There it says (among other things):
```
Core Contributorship has the following privileges...
* Standing invitation to the periodic Tor Meetings.
```
But that's not the case anymore.
/cc @isabelaGeorg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/40103Missing data for bridge users in China (and other countries)2024-03-25T17:26:23ZGabagaba@torproject.orgMissing data for bridge users in China (and other countries)There are gaps in the data for bridge users in China
https://metrics.torproject.org/userstats-bridge-combined.html?start=2023-07-19&end=2023-10-17&country=cn
Is there any way we can restore that data? Not sure what the problem is speci...There are gaps in the data for bridge users in China
https://metrics.torproject.org/userstats-bridge-combined.html?start=2023-07-19&end=2023-10-17&country=cn
Is there any way we can restore that data? Not sure what the problem is specifically here.
cc @gusHiroHirohttps://gitlab.torproject.org/tpo/core/arti/-/issues/1068arti binary: Example config file should be referred to from help output2023-11-13T14:54:16ZIan Jacksoniwj@torproject.orgarti binary: Example config file should be referred to from help output```
-c, --config <FILE>
Specify which config file(s) to read. Defaults to
[File("/home/rustcargo/.config/arti/arti.toml"),
Dir("/home/rustcargo/.config/arti/arti.d/")]
```
This should mention the ...```
-c, --config <FILE>
Specify which config file(s) to read. Defaults to
[File("/home/rustcargo/.config/arti/arti.toml"),
Dir("/home/rustcargo/.config/arti/arti.d/")]
```
This should mention the example config file!Arti: Feature parity with the C implementationIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40188New Debian backports release 1.8.12023-11-02T18:18:45ZjugaNew Debian backports release 1.8.1jugajugahttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40187New Debian release 1.8.12023-11-02T18:19:29ZjugaNew Debian release 1.8.1jugajugahttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40186Document how to enable/start systemd timers, create https server for testing ...2023-11-02T18:20:11ZjugaDocument how to enable/start systemd timers, create https server for testing network and configure directory authoritiesBecause all these questions came up in the last weeks.Because all these questions came up in the last weeks.sbws: 1.8.x-finaljugajugahttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40185New release 1.8.12023-11-02T18:19:51ZjugaNew release 1.8.1sbws: 1.8.x-finaljugajugahttps://gitlab.torproject.org/tpo/network-health/team/-/issues/333New round of contacting operators for DNS issues and badexiting problematic r...2023-11-22T07:51:53ZGeorg KoppenNew round of contacting operators for DNS issues and badexiting problematic relays (10/16/2023)We got another report this week:
```
Relay 0ED4CA8A8E6CE2D28D6D23B20815AE3982646FCB failed DNS check 5/5 times
Relay 81EDFBC8F6F5C7CF0ADD5F8E08BC8FABA04089C6 failed DNS check 3/3 times
Relay E0C90700FE1F81044A086591DCB14F02797AC14B faile...We got another report this week:
```
Relay 0ED4CA8A8E6CE2D28D6D23B20815AE3982646FCB failed DNS check 5/5 times
Relay 81EDFBC8F6F5C7CF0ADD5F8E08BC8FABA04089C6 failed DNS check 3/3 times
Relay E0C90700FE1F81044A086591DCB14F02797AC14B failed DNS check 5/5 times
Relay E7B36F63F74E9DE6A773F2F2966034ED5633DE80 failed DNS check 5/5 times
```
`E0C90700FE1F81044A086591DCB14F02797AC14B` got dealt with in #332, looking at the others now, though.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1067Implement client part of prop340: packed and fragmented relay messages2024-03-14T19:43:15ZJim NewsomeImplement client part of prop340: packed and fragmented relay messages[prop340]
Draft implementation plan:
* [x] Finish [ntorv3 (prop332)](https://spec.torproject.org/proposals/332-ntor-v3-with-extra-data.html). #1084
* [ ] Implement negotiation for [prop340] itself. EDIT: spec for negotiation may be in...[prop340]
Draft implementation plan:
* [x] Finish [ntorv3 (prop332)](https://spec.torproject.org/proposals/332-ntor-v3-with-extra-data.html). #1084
* [ ] Implement negotiation for [prop340] itself. EDIT: spec for negotiation may be in flux, since current version in prop340 doesn't align with prop346; see https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/170. (Q: maybe also behind an "experimental" compile-time feature?)
* [ ] add new consensus and config parameter "UseRelayMessage", as specified in prop340
* [ ] add new subprotocol variant "RelayCell"
* [ ] add new ntorv3 extension types 3 and 4 "Relay Cell Protocol Request" and "Response"
* [ ] when enabled, and creating a circuit with a relay supporting ntorv3 (`Relay=4`) and the new cell format (`RelayCell=1`) (Q: or select only such relays?), request version 1 of in ntorv3 "Relay Cell Protocol Request"
* [ ] when enabled, and relay has advertised support, switch to prop340 cell format. (initially log an "unimplemented" error just to verify we get this far in integration testing and destroy the circuit)
* [ ] Implement the [prop340] new cell format. (e.g. omitting stream ID instead of setting it to 0 etc)
* [x] Refactor `StreamId` to always be nonzero, replacing usage with `Option<StreamId>`. https://gitlab.torproject.org/tpo/core/arti/-/issues/1080
* [ ] Refactor to decouple cells from messages (#763+ and #775+)
* [ ] Implement packing
* [ ] Implement fragmentation
[prop340]: <https://spec.torproject.org/proposals/340-packed-and-fragmented.html>Jim NewsomeJim Newsomehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40986Prepare Tor Browser Alpha 13.5a22023-12-04T12:00:09ZrichardPrepare Tor Browser Alpha 13.5a2<details>
<summary>Explanation of variables</summary>
- `$(BUILD_SERVER)` : the server the main builder is using to build a tor-browser release
- `$(BUILDER)` : whomever is building the release on the $(BUILD_SERVER)
- **example** :...<details>
<summary>Explanation of variables</summary>
- `$(BUILD_SERVER)` : the server the main builder is using to build a tor-browser release
- `$(BUILDER)` : whomever is building the release on the $(BUILD_SERVER)
- **example** : `pierov`
- `$(STAGING_SERVER)` : the server the signer is using to to run the signing process
- `$(ESR_VERSION)` : the Mozilla defined ESR version, used in various places for building tor-browser tags, labels, etc
- **example** : `91.6.0`
- `$(TOR_BROWSER_MAJOR)` : the Tor Browser major version
- **example** : `11`
- `$(TOR_BROWSER_MINOR)` : the Tor Browser minor version
- **example** : either `0` or `5`; Alpha's is always `(Stable + 5) % 10`
- `$(TOR_BROWSER_VERSION)` : the Tor Browser version in the format
- **example** : `12.5a3`, `12.0.3`
- `$(BUILD_N)` : a project's build revision within a its branch; this is separate from the `$(TOR_BROWSER_BUILD_N)` value; many of the Firefox-related projects have a `$(BUILD_N)` suffix and may differ between projects even when they contribute to the same build.
- **example** : `build1`
- `$(TOR_BROWSER_BUILD_N)` : the tor-browser build revision for a given Tor Browser release; used in tagging git commits
- **example** : `build2`
- **NOTE** : A project's `$(BUILD_N)` and `$(TOR_BROWSER_BUILD_N)` may be the same, but it is possible for them to diverge. For example :
- if we have multiple Tor Browser releases on a given ESR branch the two will become out of sync as the `$(BUILD_N)` value will increase, while the `$(TOR_BROWSER_BUILD_N)` value may stay at `build1` (but the `$(TOR_BROWSER_VERSION)` will increase)
- if we have build failures unrelated to `tor-browser`, the `$(TOR_BROWSER_BUILD_N)` value will increase while the `$(BUILD_N)` will stay the same.
- `$(TOR_BROWSER_VERSION)` : the published Tor Browser version
- **example** : `11.5a6`, `11.0.7`
- `$(TBB_BUILD_TAG)` : the `tor-browser-build` build tag used to build a given Tor Browser version
- **example** : `tbb-12.5a7-build1`
</details>
**NOTE** It is assumed that the `tor-browser` stable rebase and security backport tasks have been completed
**NOTE** This can/is often done in conjunction with the equivalent Mullvad Browser release prep issue
<details>
<summary>Building</summary>
### tor-browser-build: https://gitlab.torproject.org/tpo/applications/tor-browser-build.git
Tor Browser Alpha (and Nightly) are on the `main` branch
- [x] Update `rbm.conf`
- [x] `var/torbrowser_version` : update to next version
- [x] `var/torbrowser_build` : update to `$(TOR_BROWSER_BUILD_N)`
- [x] ***(Desktop Only)***`var/torbrowser_incremental_from` : update to previous Desktop version
- **NOTE**: We try to build incrementals for the previous 3 desktop versions except in the case of a watershed update
- **IMPORTANT**: Really *actually* make sure this is the previous Desktop version or else the `make torbrowser-incrementals-*` step will fail
- [x] Update Desktop-specific build configs
- [x] Update `projects/firefox/config`
- [x] `browser_build` : update to match `tor-browser` tag
- [ ] ***(Optional)*** `var/firefox_platform_version` : update to latest `$(ESR_VERSION)` if rebased
- [x] Update `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
- [ ] ***(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`
- [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
- [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
- [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:
- [ ] 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
- [x] Under `Windows + Android` include any version updates for:
- zlib
- [x] 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
- [ ] 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
- [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] run do-all-signing script:
- `cd tor-browser-build/tools/signing/`
- `./do-all-signing.torbrowser`
- **NOTE**: at this point the signed binaries should have been copied to `staticiforme`
- [x] Update `staticiforme.torproject.org`:
- From `screen` session on `staticiforme.torproject.org`:
- [x] Static update components : `static-update-component cdn.torproject.org && static-update-component dist.torproject.org`
- [x] Enable update responses : `sudo -u tb-release ./deploy_update_responses-alpha.sh`
- [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`
- [ ] 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 `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
- [ ] 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>richardrichard