The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-02-15T18:53:21Zhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40757Change projects/browser/windows-installer/torbrowser.nsi to a template file2023-02-15T18:53:21ZboklmChange projects/browser/windows-installer/torbrowser.nsi to a template fileTo avoid having `basebrowser.nsi`, `privacybrowser.nsi`, `torbrowser.nsi` as separate files with mostly the same content, we can create a single template file.To avoid having `basebrowser.nsi`, `privacybrowser.nsi`, `torbrowser.nsi` as separate files with mostly the same content, we can create a single template file.boklmboklmhttps://gitlab.torproject.org/tpo/team/-/issues/132Go through list of tasks to delegate before going on long PTO2023-02-08T22:38:32ZGabagaba@torproject.orgGo through list of tasks to delegate before going on long PTO1. All Hands Meetings -> Erin
2. Sponsors
- [x] 9 - Isa to facilitate coordination meeting
- [x] 28 - check with Itchyonion or Roger to help with the report
- [x] 30 - Nah to facilitate coordination meeting
- [x] 96 - Gus to facilitate c...1. All Hands Meetings -> Erin
2. Sponsors
- [x] 9 - Isa to facilitate coordination meeting
- [x] 28 - check with Itchyonion or Roger to help with the report
- [x] 30 - Nah to facilitate coordination meeting
- [x] 96 - Gus to facilitate coordination meeting
- [x] 101 - Micah to facilitate coordination meeting
- [x] 112 - Geko to facilitate coordination meeting
- [x] 131 - richard to facilitate coordination meeting
- [x] 134 - bekeela to follow up communication with IRI
- [x] 139 - check with bekeela to write report for February
- [x] Zcash -> bekeela & ahf
- [x] Localization to Aymara <-- emmapeel
- [x] Developer portal
- [x] Follow up on code audit quotes from sponsor 61 @micah and @bekeela
@isabela @micah this ticket will list who is coordinating what when I'm gone in February.Gabagaba@torproject.orgGabagaba@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40755libdmg-hfsplus fails to build on debian stable2023-02-10T13:20:12Zboklmlibdmg-hfsplus fails to build on debian stableAfter e75f33486433c9d2a612b333369ac0f961ada38c, building `libdmg-hfsplus` with `./rbm/rbm build --target no_containers libdmg-hfsplus` on debian stable is failing with the error:
```
-- Configuring done
-- Generating done
-- Build files ...After e75f33486433c9d2a612b333369ac0f961ada38c, building `libdmg-hfsplus` with `./rbm/rbm build --target no_containers libdmg-hfsplus` on debian stable is failing with the error:
```
-- Configuring done
-- Generating done
-- Build files have been written to: /var/tmp/build/libdmg-hfsplus-2ee327795680
[1/29] /usr/bin/cc -DHAVE_CRYPT -Iincludes -O3 -DNDEBUG -MD -MT dmg/CMakeFiles/dmg-bin.dir/dmg.c.o -MF dmg/CMakeFiles/dmg-bin.dir/dmg.c.o.d -o dmg/CMakeFiles/dmg-bin.dir/dmg.c.o -c dmg/dmg.c
FAILED: dmg/CMakeFiles/dmg-bin.dir/dmg.c.o
/usr/bin/cc -DHAVE_CRYPT -Iincludes -O3 -DNDEBUG -MD -MT dmg/CMakeFiles/dmg-bin.dir/dmg.c.o -MF dmg/CMakeFiles/dmg-bin.dir/dmg.c.o.d -o dmg/CMakeFiles/dmg-bin.dir/dmg.c.o -c dmg/dmg.c
In file included from dmg/dmg.c:7:
includes/dmg/filevault.h:82:16: error: field 'hmacCTX' has incomplete type
82 | HMAC_CTX hmacCTX;
| ^~~~~~~
[2/29] /usr/bin/cc -Iincludes -O3 -DNDEBUG -MD -MT common/CMakeFiles/common.dir/abstractfile.c.o -MF common/CMakeFiles/common.dir/abstractfile.c.o.d -o common/CMakeFiles/common.dir/abstractfile.c.o -c common/abstractfile.c
ninja: build stopped: subcommand failed.
```boklmboklmhttps://gitlab.torproject.org/tpo/core/arti/-/issues/745hs descriptor encoder2023-04-25T15:35:52ZIan Jacksoniwj@torproject.orghs descriptor encoderWe need something to construct hidden service descriptors. These have multiple phases of construction, which use different private key material. This will need some kind of multi-stage API.
Part of #683We need something to construct hidden service descriptors. These have multiple phases of construction, which use different private key material. This will need some kind of multi-stage API.
Part of #683Arti: Onion service supportgabi-250gabi-250https://gitlab.torproject.org/tpo/network-health/tor-weather/-/issues/19Explain requirements for variables in settings.py2023-02-02T04:39:52ZGeorg KoppenExplain requirements for variables in settings.pyWe have some variables needed in src/settings.py that are pretty straightforward to deal with (like `SMTP_PORT`) but others need some comment/explanation so folks know what they are supposed to so. Two examples that come to mind right no...We have some variables needed in src/settings.py that are pretty straightforward to deal with (like `SMTP_PORT`) but others need some comment/explanation so folks know what they are supposed to so. Two examples that come to mind right now:
1. We should mention that the onionoo job interval specified is in *minutes*.
2. We should give some hint as to whether there are some needs for the `JWT_SECRET`. Could it just be "test1234" or some other text or does it need to be formatted particularly or...?
Apart from those two we might want to think whether other variables would benefit from a comment having in mind someone needing to set this app up who might not know all of the nitty-gritty details involved in it.https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/44UX Review: Mullvad Browser 12.0.42023-03-20T14:17:51ZrichardUX Review: Mullvad Browser 12.0.4Review the 12.0.4 build and ensure we're tracking any discovered UX issues.Review the 12.0.4 build and ensure we're tracking any discovered UX issues.https://gitlab.torproject.org/tpo/tpa/triage-ops/-/issues/10Auto-assign milestone based on base branch2024-02-28T19:05:22ZDavid Gouletdgoulet@torproject.orgAuto-assign milestone based on base branchThis is simple but might not be feasible but @ahf asked me to open this anyway.
Essentially, if the MR opens against `maint-0.4.7` then set the milestone to "0.4.7-post-stable". If it is against `main`, set it to `0.4.8-freeze`.
We cou...This is simple but might not be feasible but @ahf asked me to open this anyway.
Essentially, if the MR opens against `maint-0.4.7` then set the milestone to "0.4.7-post-stable". If it is against `main`, set it to `0.4.8-freeze`.
We could just have a matrix that we update when we release a new stable or milestone move around.
I'm asking this because I keep needing to set the milestone to the new MRs and it is a bit of work that could be automated.Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/740Design a basic RPC interface for experimentation2023-04-25T15:40:49ZNick MathewsonDesign a basic RPC interface for experimentationWe should design (and possibly build) the basics of a socket based API. (Call it IPC or RPC if you like: it would perform a function for arti analogous to Tor's control port.)
If possible we could start development in ~Q1, but ~Q2 seem...We should design (and possibly build) the basics of a socket based API. (Call it IPC or RPC if you like: it would perform a function for arti analogous to Tor's control port.)
If possible we could start development in ~Q1, but ~Q2 seems more likely: This will take a lot of discussion with a lot of people.
See [`ExportedApiSketch.md`](https://gitlab.torproject.org/tpo/core/arti/-/blob/main/doc/dev/ExportedApiSketch.md) for early thoughts, and a set of issues that we need to solve.https://gitlab.torproject.org/tpo/core/arti/-/issues/739Refactor socket-proxying code to a lower level module2023-11-13T15:42:07ZNick MathewsonRefactor socket-proxying code to a lower level moduleWe have code that copies all data between a pair of sockets interactively. Right now it's ~~duplicated in our PT code and~~ in our SOCKS code. Soon, we'll want it for #738. We should refactor this to a lower level crate.
Possibly a `...We have code that copies all data between a pair of sockets interactively. Right now it's ~~duplicated in our PT code and~~ in our SOCKS code. Soon, we'll want it for #738. We should refactor this to a lower level crate.
Possibly a `tor-async-utils` is in order?https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41580Download an external file type popup isn't assigned to the Tor Browser2023-08-22T20:54:51ZPorkepixDownload an external file type popup isn't assigned to the Tor Browser<!--
* Use this issue template for reporting a new UX bug.
-->
### Summary
The "Download an external file type" popup is assigned to the classic Firefox program in Gnome if it's opened besides the Tor Browser.
### Steps to reproduce:
...<!--
* Use this issue template for reporting a new UX bug.
-->
### Summary
The "Download an external file type" popup is assigned to the classic Firefox program in Gnome if it's opened besides the Tor Browser.
### Steps to reproduce:
**How one can reproduce the issue - this is very important.**
1. From a computer with a recent Gnome, download a file with the Tor Browser that would trigger the "Download an external filetype" popup, while having a standard Firefox opened
2. When the popup triggers (which can be delayed from the moment user click on the button in some rare cases such as the usage of local storage and unencryption after), this popup will be assigned to the Firefox icon/program when alt-tabbing rather than the Tor-Browser one.
3. I believe that despite being a Firefox process, the Tor Browser had things modified to don't be grouped up with a classic Firefox, maybe this popup needs the same treatment?
### What is the current bug behavior?
The popup visible below is assigned to the Firefox program rather than the Tor Browser's one.
### What is the expected behavior?
It should correctly be assigned to Tor Browser instead.
## Relevant logs and/or screenshots
![Screenshot_from_2023-01-16_20-10-36](/uploads/76a195a70454ac8bf9edd2267b468272/Screenshot_from_2023-01-16_20-10-36.png)
I don't know what would happen if Firefox wasn't opened, I didn't have the case up to now (and it's unlikely to happen as my Firefox is always opened).
EDIT: Gnome don't let me take a screenshot while I hold the alt button, so I can't really show the problem during the alt-tab.
Also, on this popup, shouldn't there be an icon on the left of the text instead of this little question mark?https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41572Check for userContextId also in the circuit display2023-02-01T15:02:49ZPier Angelo VendrameCheck for userContextId also in the circuit displayThe changes of !494 need also some changes on the circuit display side.
At the moment, it's broken because it cannot find the credentials anymore.The changes of !494 need also some changes on the circuit display side.
At the moment, it's broken because it cannot find the credentials anymore.Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/core/arti/-/issues/728Key management backend2023-10-31T17:05:43ZNick MathewsonKey management backendClients need private keys to handle onion service authorization. These are associated with a single onion service, and possibly (#542) associated with a single request.
Onion services need a private key (which can be offline) for the on...Clients need private keys to handle onion service authorization. These are associated with a single onion service, and possibly (#542) associated with a single request.
Onion services need a private key (which can be offline) for the onion identity, and a set of private signing keys (one for each time period). Additionally, onion services need to manage a set of shorter-term private keys that they use to identify themselves to introduction points.
In general we want:
* the ability to load keys from disk
* the ability to generate keys automatically if they don't exist
* the ability to generate appropriate keys and certificates offline, via CLI
* not too much duplicated code.
We may want:
* encrypted keys on disk (though probably not yet)
* backward compatibility with Tor stored key and certificate formats
It would be very easy to over-engineer all of this!
(Eventually we'll need to deal with relays' and dirauths' keys too.)Arti: Onion service supportgabi-250gabi-250https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41568Disable LaterRun2023-02-15T18:05:45Zcypherpunks1Disable LaterRunDetails: https://bugzilla.mozilla.org/show_bug.cgi?id=1200639
The feature is controlled by `browser.laterrun.enabled`.
It stores the profile creation time in `browser.laterrun.bookkeeping.profileCreationTime`.
It stores the number of ...Details: https://bugzilla.mozilla.org/show_bug.cgi?id=1200639
The feature is controlled by `browser.laterrun.enabled`.
It stores the profile creation time in `browser.laterrun.bookkeeping.profileCreationTime`.
It stores the number of times the browser has been used in `browser.laterrun.bookkeeping.sessionCount`.cypherpunks1cypherpunks1https://gitlab.torproject.org/tpo/core/arti/-/issues/725Implement replay caches for onion services2024-01-11T15:44:15ZNick MathewsonImplement replay caches for onion servicesWe need to implement replay caches at the onion service to prevent replayed INTRODUCE1 or INTRODUCE2 cells.
These can use a HashSet or a bloom filter. See `rend-spec-v3` section 1.8.We need to implement replay caches at the onion service to prevent replayed INTRODUCE1 or INTRODUCE2 cells.
These can use a HashSet or a bloom filter. See `rend-spec-v3` section 1.8.Arti: Onion service supportIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40731Update namecoin patches to apply in tor-browser nightly2023-02-15T18:53:49ZrichardUpdate namecoin patches to apply in tor-browser nightlyeffective_tld_names.dat has been updated so need to update the patch, torbutton is now in `/toolkit/torbutton`effective_tld_names.dat has been updated so need to update the patch, torbutton is now in `/toolkit/torbutton`https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41566Migrate maximizing warning panel out of torbutton to base-browser2023-07-28T13:04:27ZrichardMigrate maximizing warning panel out of torbutton to base-browserMigrate this functionality to a separate patch that lives somewhere near the letterboxing improvement patches in the base-browser section.Migrate this functionality to a separate patch that lives somewhere near the letterboxing improvement patches in the base-browser section.https://gitlab.torproject.org/tpo/core/arti/-/issues/722Support isolation for onion services2023-04-25T16:00:51ZNick MathewsonSupport isolation for onion servicesIn C tor, I think there is no circuit isolation when using onion services, and I _know_ there is no cache isolation. We should figure out how we would like that to work in Arti, and keep in in mind when designing our cache and client AP...In C tor, I think there is no circuit isolation when using onion services, and I _know_ there is no cache isolation. We should figure out how we would like that to work in Arti, and keep in in mind when designing our cache and client APIs here.
The "easy" version of this would be to provide circuit-level isolation, such that if two contexts would not share an exit circuit, they can't share a rendezvous circuit either. Our current design provides that at no effort.
A harder version of this would be to implement isolation for descriptor cache information and introduction point status information. Since we are currently imagining those living outside of `tor-circmgr`, we'd need to make sure that our boxed isolation-type objects can be exported to higher level crates as part of their API.Arti: Onion service supporthttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40730Prepare Tor Browser Stable 12.5.02023-06-26T21:21:01ZrichardPrepare Tor Browser Stable 12.5.0<details>
<summary>Explanation of variables</summary>
- `$(BUILD_SERVER)` : the server the main builder is using to build a tor-browser release
- `$(STAGING_SERVER)` : the server the signer is using to to run the signing process
- `$(...<details>
<summary>Explanation of variables</summary>
- `$(BUILD_SERVER)` : the server the main builder is using to build a tor-browser release
- `$(STAGING_SERVER)` : the server the signer is using to to run the signing process
- `$(ESR_VERSION)` : the Mozilla defined ESR version, used in various places for building tor-browser tags, labels, etc
- example : `91.6.0`
- `$(ESR_TAG)` : the Mozilla defined hg (Mercurial) tag associated with `$(ESR_VERSION)`
- exmaple : `FIREFOX_91_7_0esr_BUILD2`
- `$(ESR_TAG_PREV)` : the Mozilla defined hg (Mercurial) tag associated with the previous ESR version when rebasing (ie, the ESR version we are rebasing from)
- `$(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`
</details>
**NOTE** It is assumed that the `tor-browser` rebase and security backport tasks have been completed
<details>
<summary>Build Configs</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
- **IMPORTANT**: Really *actually* make sure this is the previous Desktop version or else the `make incrementals-*` step will fail
- [ ] 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-release` to get updated hashes
- [x] `steps/base-browser/git_hash` : update with `HEAD` commit of project's `base-browser` branch
- [x] `steps/base-browser-fluent/git_hash` : update with `HEAD` commit of project's `basebrowser-newidentityftl` 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] ***(Optional)*** 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)`
- [ ] ***(Optional)*** Update `projects/android-components/config`:
- [ ] `android_components_build` : update to match android-components tag
- [ ] ***(Optional)*** Update `projects/fenix/config`
- [ ] `fenix_build` : update to match fenix tag
- [ ] ***(Optional)*** `var/fenix_version` : update to latest `$(ESR_VERSION)` if rebased
- [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/
- [ ] ***(Optional)*** If new 1.X.Y version available, update `projects/openssl/config`
- [ ] `version` : update to next 1.X.Y 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://golang.org/dl
- **NOTE** : Tor Browser Stable uses the latest of the *previous* Stable major series go version (apart from the transition phase from Tor Browser Alpha to Stable, in which case Tor Browser Stable may use the latest 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] Update the manual : https://gitlab.torproject.org/tpo/web/manual/-/jobs/
- [ ] Download the `artifacts.zip` file from latest build stage row (download icon button on the right)
- [ ] Rename it to `manual_$PIPELINEID.zip`
- [ ] Upload it to people.tpo
- [ ] Update `projects/manual/config`
- [ ] Change the version to `$PIPELINEID`
- [ ] Update the hash in the input_files section
- [ ] Update the URL if you have uploaded to a different people.tpo home
- [x] Update `ChangeLog.txt`
- [ ] Ensure ChangeLog.txt is sync'd between alpha and stable branches
- [ ] Check the linked issues: ask people to check if any are missing, remove the not fixed ones
- [ ] Run `tools/fetch-changelogs.py $(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.txt` and adjust its output
- If you used the issue number, you will need to write the Tor Browser version manually
- [ ] Include any version updates for:
- [ ] translations
- [ ] OpenSSL
- [ ] NoScript
- [ ] Go
- [ ] zlib
- [ ] Include any ESR rebase for Firefox and GeckoView
- [x] Open MR with above changes
- [x] Begin build on `$(BUILD_SERVER)` (and fix any issues which come up and update MR)
- [x] Merge
- [x] Sign/Tag commit: `make torbrowser-signtag-release`
- [x] Push tag to `origin`
</details>
<details>
<summary>Communications</summary>
### notify stakeholders
<details>
<summary>email template</summary>
Hello All,
Unsigned Tor Browser $(TOR_BROWSER_VERSION) release candidate builds are now available for testing:
- https://tb-build-05.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/maint-12.0/projects/browser/Bundle-Data/Docs/ChangeLog.txt
</details>
- [x] Email tor-qa mailing list: tor-qa@lists.torproject.org
- Additional information:
- [ ] Note any new functionality which needs testing
- [ ] Link to any known issues
- [x] Email downstream consumers:
- 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 upstream stakeholders:
- ***(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 + publishing
- [x] Ensure builders have matching builds
- [x] On `$(STAGING_SERVER)`, ensure updated:
- [ ] `tor-browser-build/tools/signing/set-config`
- `NSS_DB_DIR` : location of the `nssdb7` directory
- [ ] `tor-browser-build/tools/signing/set-config.hosts`
- `ssh_host_builder` : ssh hostname of machine with unsigned builds
- **NOTE** : `tor-browser-build` is expected to be in the `$HOME` directory)
- `ssh_host_linux_signer` : ssh hostname of linux signing machine
- `ssh_host_macos_signer` : ssh hostname of macOS signing machine
- [ ] `tor-browser-build/tools/signing/set-config.macos-notarization`
- `macos_notarization_user` : the email login for a tor notariser Apple Developer account
- [ ] `set-config.update-responses`
- `update_responses_repository_dir` : directory where you cloned `git@gitlab.torproject.org:tpo/applications/tor-browser-update-responses.git`
- [ ] `tor-browser-build/tools/signing/set-config.tbb-version`
- `tbb_version` : tor browser version string, same as `var/torbrowser_version` in `rbm.conf` (examples: `11.5a12`, `11.0.13`)
- `tbb_version_build` : the tor-browser-build build number (if `var/torbrowser_build` in `rbm.conf` is `buildN` then this value is `N`)
- `tbb_version_type` : either `alpha` for alpha releases or `release` for stable releases
- [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.sh`
- **NOTE**: at this point the signed binaries should have been copied to `staticiforme`
- [x] Update `staticiforme.torproject.org`:
- From `screen` session on `staticiforme.torproject.org`:
- [x] Static update components : `static-update-component cdn.torproject.org && static-update-component dist.torproject.org`
- [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 the current release is Android or Desktop *only*
- [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
- [ ] Publish APKs to Google Play:
- Log into https://play.google.com/apps/publish
- Select `Tor Browser` 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
- [x] 25% rollout when publishing a scheduled update
- [ ] 100% rollout when publishing a security-driven release
- [x] Update rollout percentage to 100% after confirmed no major issues
</details>
<details>
<summary>Publishing</summary>
### website: https://gitlab.torproject.org/tpo/web/tpo.git
- [ ] `databags/versions.ini` : Update the downloads versions
- `torbrowser-stable/version` : sort of a catch-all for latest stable version
- `torbrowser-alpha/version` : sort of a catch-all for latest stable version
- `torbrowser-*-stable/version` : platform-specific stable versions
- `torbrowser-*-alpha/version` : platform-specific alpha versions
- `tor-stable`,`tor-alpha` : set by tor devs, do not touch
- [ ] Push to origin as new branch, open 'Draft :' MR
- [ ] Remove `Draft:` from MR once signed-packages are uploaded
- [ ] Merge
- [x] Publish after CI passes and builds are published
### blog: https://gitlab.torproject.org/tpo/web/blog.git
- [ ] Duplicate previous Stable or Alpha release blog post as appropriate to new directory under `content/blog/new-release-tor-browser-$(TOR_BROWSER_VERSION)` and update with info on release :
- [ ] Update Tor Browser version numbers
- [ ] Note any ESR rebase
- [ ] 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.txt to markdown format used here by :
- `tor-browser-build/tools/changelog-format-blog-post`
- [ ] Push to origin as new branch, open `Draft:` MR
- [ ] Remove `Draft:` from MR once signed-packages are uploaded
- [ ] Merge
- [x] Publish after CI passes and website has been updated
### tor-announce mailing list
- [x] Send an email to tor-announce@lists.torproject.org, using the same content as the blog post and subject "Tor Browser $version is released".
</details>richardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41560Turning letterboxing off results in newtab not rendering2023-01-30T08:35:42ZThorinTurning letterboxing off results in newtab not renderingSTR (using latest alpha)
- TB not connected
- flip LB off
- in a new tab load a file:// scheme
- nothing shows
- toggle LB on, change to test tab, it shows
- now you can use that tab regardless of the LB pref, but new tabs will exhibit t...STR (using latest alpha)
- TB not connected
- flip LB off
- in a new tab load a file:// scheme
- nothing shows
- toggle LB on, change to test tab, it shows
- now you can use that tab regardless of the LB pref, but new tabs will exhibit the issue
Related to newtab window "clamping" _I think_ - I'll let you debug it = @ma1
<details><summary>behold my mighty gif making skills</summary><p>
![filescheme](/uploads/f36de91e40f5ae90a4d647e0091b3bd3/filescheme.gif)
</p></details>ma1ma1https://gitlab.torproject.org/tpo/core/arti/-/issues/718arti_client: No easy way to set connect preferences2023-01-18T18:07:07Zmichaelvanstratenarti_client: No easy way to set connect preferences<!--
* Use this issue template for submitting a feature.
-->
### Summary
The current implementation does not allow setting of the `StreamPrefs` without cloning the client.
For example, usually you could pass the `StreamPrefs` to the `c...<!--
* Use this issue template for submitting a feature.
-->
### Summary
The current implementation does not allow setting of the `StreamPrefs` without cloning the client.
For example, usually you could pass the `StreamPrefs` to the `connect_with_prefs` method but in the case of `arti-hyper` the `ArtiHttpConnector`
only ever calls `connect`.
To set the Stream Preferences in this case, you would have to do something like this:
```rust
let redundent_client = TorClient::create_bootstrapped(TorClientConfig::default()).await?;
let stream_prefs = StreamPrefs::new();
stream_prefs.isolate_every_stream();
let client = redundent_client.clone_with_prefs(stream_prefs);
drop(redundent_client);
```
This is an issue because you would want to isolate every stream in the `ArtiHttpConnector` and there is no good way to do that right now.
### What is the expected behavior?
I would suggest that we make the `set_connect_prefs` method on the `TorClient` public [#250](https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/250#note_2771237).