The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-01-30T08:35:42Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41539Crypto warning weaknesses2023-01-30T08:35:42ZhenryCrypto warning weaknessesThe "Bug 40209: Implement Basic Crypto Safety" patch (`73640da2c4e719493b45fb6140f7ad2666326d89`) is trying to prevent users using malicious crypto addresses from HTTP websites. It does this under the following condition
1. The website ...The "Bug 40209: Implement Basic Crypto Safety" patch (`73640da2c4e719493b45fb6140f7ad2666326d89`) is trying to prevent users using malicious crypto addresses from HTTP websites. It does this under the following condition
1. The website is HTTP and not `.onion` (so vulnerable to being spoofed).
2. The user [copies or cuts text](https://gitlab.torproject.org/tpo/applications/tor-browser/-/commit/73640da2c4e719493b45fb6140f7ad2666326d89#17431c47080b50e91d17ade0423f534d7467c15d_0_75)
3. And the copied text [looks like a crypto address](https://gitlab.torproject.org/tpo/applications/tor-browser/-/commit/73640da2c4e719493b45fb6140f7ad2666326d89#17431c47080b50e91d17ade0423f534d7467c15d_0_78)
In this case it shows the user a popup warning them about the potential inserted crypto address.
## Weaknesses
I can think of three weaknesses to this approach.
### White space
Currently, [we only trim the copied text](https://gitlab.torproject.org/tpo/applications/tor-browser/-/commit/73640da2c4e719493b45fb6140f7ad2666326d89#17431c47080b50e91d17ade0423f534d7467c15d_0_77) rather than remove all whitespace within as well. This means that you can just insert some whitespace in the address (they could make it look presentational, or use CSS to hide it) and the user won't get a warning.
It is not that usually for text inputs to consume (some) whitespace. And even if it didn't, a user that has already copied the text will probably just remove the whitespace themselves after pasting.
### Drag and drop
No warning is triggered if the user starts dragging the crypto address. Maybe this doesn't come up much, but the website could try and encourage it by just writing "Drag and drop the address below". Or setting `user-select: none` but making the address draggable.
### Copying the address manually
If you set `user-select: none` on the address then there is no way to copy the text. If the user already trusts the HTTP website, then they may just copy out the address by hand. Maybe they wouldn't bother with the length of some addresses though.
## Risk
I'm not sure how high the risk is since we have HTTPS-always now. But we have decided to still keep the crypto warning in place as a protective measure.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40715Prepare alpha release 12.5a22023-06-15T07:29:01ZrichardPrepare alpha release 12.5a2<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`
- `$(RR_VERSION)` : the Mozilla defined Rapid-Release version; Tor Browser for Android is based off of the `$(ESR_VERSION)`, but Mozilla's Firefox for Android is based off of the `$(RR_VERSION)` so we need to keep track of security vulnerabilities to backport from the monthly Rapid-Release train and our frozen ESR train.
- example: `103`
- `$(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`
- `$(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`
- `$(TOR_BROWSER_BRANCH)` : the full name of tor-browser branch
- typically of the form: `tor-browser-$(ESR_VERSION)esr-$(TOR_BROWSER_MAJOR).$(TOR-BROWSER_MINOR)-1`
- `$(TOR_BROWSER_BRANCH_PREV)` : the full name of the previous tor-browser branch (when rebasing)
</details>
<details>
<summary>Android</summary>
### **Security Vulnerabilities Backport** : https://www.mozilla.org/en-US/security/advisories/
- **NOTE** : this work usually first occurs during the Tor Browser Stable release, so for alpha we typically only need to update the various `tor-browser-build` configs to point to the right release tags.
- [x] Create tor-browser issue `Backport Android-specific Firefox $(RR_VERSION) to ESR $(ESR_VERSION)-based Tor Browser`
- [x] Link new backport issue to this release prep issue
- [ ] Go through any `Security Vulnerabilities fixed in Firefox $(RR_VERSION)` (or similar) and create list of CVEs which affect Android that need to be a backported
- Potentially Affected Components:
- `firefox`/`geckoview`
- `application-services`
- `android-components`
- `fenix`
### **application-services** ***(Optional)*** : *TODO: we need to setup a gitlab copy of this repo that we can apply security backports to*
- [ ] Backport any Android-specific security fixes from Firefox rapid-release
- [ ] Sign/Tag commit:
- Tag : `application-services-$(ESR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-$(BUILD_N)`
- Message: `Tagging $(BUILD_N) for $(ESR_VERSION)-based alpha`
- [ ] Push tag to `origin`
### **android-components** ***(Optional)*** : https://gitlab.torproject.org/tpo/applications/android-components.git
- [ ] Backport any Android-specific security fixes from Firefox rapid-release
- [ ] Sign/Tag commit:
- Tag : `android-components-$(ESR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-$(BUILD_N)`
- Message: `Tagging $(BUILD_N) for $(ESR_VERSION)-based alpha)`
- [ ] Push tag to `origin`
### **fenix** ***(Optional)*** : https://gitlab.torproject.org/tpo/applications/fenix.git
- [ ] Backport any Android-specific security fixes from Firefox rapid-release
- [ ] Sign/Tag commit:
- Tag : `tor-browser-$(ESR_VERSION)-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-$(BUILD_N)`
- Message: `Tagging $(BUILD_N) for $(ESR_VERSION)-based alpha)`
- [ ] Push tag to `origin`
</details>
<details>
<summary>Shared</summary>
### tor-browser: https://gitlab.torproject.org/tpo/applications/tor-browser.git
- [ ] ***(Optional)*** Backport any Android-specific security fixes from Firefox rapid-release
- [ ] ***(Optional, Chemspill)*** Backport security-fixes to both `tor-browser` and `base-browser` branches
- [ ] ***(Optional)*** Rebase to `$(ESR_VERSION)`
- [x] Find the Firefox hg tag here : https://hg.mozilla.org/releases/mozilla-esr102/tags
- [x] `$(ESR_TAG)` : `FIREFOX_102_7_0esr_BUILD1`
- [x] Identify the hg patch associated with above hg tag, and find the equivalent `gecko-dev` git commit (search by commit message)
- [x] `gecko-dev` commit : tor-browser@3020951fffa41f2119b1208d8314bdb7969fe608
- [x] Sign/Tag commit :
- Tag : `$(ESR_TAG)`
- Message : `Hg tag $(ESR_TAG)`
- [x] Create new branches with the discovered `gecko-dev` commit as `HEAD` named:
- [x] `base-browser-$(ESR_VERSION)esr-$(TOR_BROWSER_MAJOR).$(TOR-BROWSER_MINOR)-1`
- [x] `tor-browser-$(ESR_VERSION)esr-$(TOR_BROWSER_MAJOR).$(TOR-BROWSER_MINOR)-1`
- [x] Push new branches and esr tag to origin
- [x] Rebase previous `base-browser` patches onto the `gecko-dev` commit
- [x] Rebase previous `tor-browser` patches onto the new `base-browser` branch
- [x] Compare patch-sets (ensure nothing *weird* happened during rebase):
- [x] rangediff: `git range-diff $(ESR_TAG_PREV)..$(TOR_BROWSER_BRANCH_PREV) $(ESR_TAG)..$(TOR_BROWSER_BRANCH)`
- [x] diff of diffs:
- Do the diff between `current_patchset.diff` and `rebased_patchset.diff` with your preferred `$(DIFF_TOOL)` and look at differences on lines that starts with + or -
- [x] `git diff $(ESR_TAG_PREV)..$(TOR_BROWSER_BRANCH_PREV) > current_patchset.diff`
- [x] `git diff $(ESR_TAG)..$(TOR_BROWSER_BRANCH) > rebased_patchset.diff`
- [x] `$(DIFF_TOOL) current_patchset.diff rebased_patchset.diff`
- [x] Open MR for the rebase
- [x] Sign/Tag `base-browser` commit:
- **NOTE** : Currently we are using the `Bug 40926: Implemented the New Identity feature` commit as the final commit of `base-browser` before `tor-browser`
- Tag : `base-browser-$(ESR_VERSION)esr-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-build1`
- Message: `Tagging build1 for $(ESR_VERSION)esr-based alpha`
- [x] Sign/Tag `tor-browser` commit :
- Tag : `tor-browser-$(ESR_VERSION)esr-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-$(FIREFOX_BUILD_N)`
- Message : `Tagging $(FIREFOX_BUILD_N) for $(ESR_VERSION)esr-based alpha`
- [x] Push rebased branches and tags to `origin`
- [x] Update Gitlab Default Branch to new Alpha branch: https://gitlab.torproject.org/tpo/applications/tor-browser/-/settings/repository
</details>
<details>
<summary>Build</summary>
### tor-browser-build: https://gitlab.torproject.org/tpo/applications/tor-browser-build.git
Tor Browser Alpha (and Nightly) are on the `main` branch, while 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] ***(Optional, Desktop)*** `var/torbrowser_incremental_from` : update to previous Desktop version
- [x] **IMPORTANT**: Really *actually* make sure this is the previous Desktop version or else the `make incrementals-*` step will fail
- [ ] ***(Optional)*** Update Desktop-specific build configs
- [x] Update `projects/firefox/config`
- [x] `git_hash` : update the `$(BUILD_N)` section to match `tor-browser` tag
- [x] ***(Optional)*** `var/firefox_platform_version` : update to latest `$(ESR_VERSION)` if rebased
- [x] Update `projects/translation-base-browser/config`
- [x] `git_hash` : update with `HEAD` commit of project's `base-browser` branch
- [x] Update `projects/translation-base-browser-fluent/config`
- [x] `git_hash` : update with `HEAD` commit of project's `basebrowser-newidentityftl` branch
- [ ] ***(Optional)*** Update Android-specific build configs
- [x] ***(Optional)*** Update `projects/geckoview/config`
- [x] `git_hash` : update the `$(BUILD_N)` section to match `tor-browser` tag
- [x] ***(Optional)*** `var/geckoview_version` : update to latest `$(ESR_VERSION)` if rebased
- [x] Update `projects/tba-translations/config`:
- [x] `git_hash` : update with `HEAD` commit of project's `fenix-torbrowserstringsxml` branch
- [x] ***(Optional)*** Update `projects/tor-android-service/config`
- [x] `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`:
- [ ] `git_hash` : update the `$(BUILD_N)` section to match alpha `android-components` tag
- [ ] ***(Optional)*** Update `projects/fenix/config`
- [ ] `git_hash` : update the `$(BUILD_N)` section 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
- [x] ***(Optional)*** If new version available, update `noscript` section of `input_files` in `projects/browser/config`
- [x] `URL`
- [x] `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
- [x] ***(Optional)*** Update `projects/tor/config`
- [ ] `version` : update to latest `-alpha` tag or release tag if newer (ping @dgoulet or @ahf if unsure)
- [x] Check for go updates here : https://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] ***(Optional)*** Update the manual
- [x] Go to https://gitlab.torproject.org/tpo/web/manual/-/jobs/
- [x] Open the latest build stage
- [x] Download the artifacts (they come in a .zip file).
- [x] Rename it to `manual_$PIPELINEID.zip`
- [x] Upload it to people.tpo
- [x] Update `projects/manual/config`
- [x] Change the version to `$PIPELINEID`
- [x] Update the hash in the input_files section
- [x] Update the URL if you have uploaded to a different people.tpo home
- [ ] Update `ChangeLog.txt`
- [ ] Ensure ChangeLog.txt is sync'd between alpha and stable branches
- [ ] Open MR with above changes
- [ ] Begin build on `$(BUILD_SERVER)` (fix any issues which come up and update MR)
- [ ] Sign/Tag commit: `make signtag-alpha`
- [ ] Push tag to origin
</details>
<details>
<summary>Communications</summary>
### notify stakeholders
- [ ] Email tor-qa mailing list: tor-qa@lists.torproject.org
- [ ] Provide links to unsigned builds on `$(BUILD_SERVER)`
- [ ] Note any new functionality which needs testing
- [ ] Link to any known issues
- [ ] Email downstream consumers:
- Recipients:
- [ ] Tails dev mailing list: tails-dev@boum.org
- [ ] Guardian Project: nathan@guardianproject.info
- [ ] torbrowser-launcher: micah@micahflee.com
- [ ] Provide links to unsigned builds on `$(BUILD_SERVER)`
- [ ] 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/Publishing</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
- [ ] `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] apk signing : copy signed `*multi.apk` files to the unsigned build outputs directory
- [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`
- [ ] Update `staticiforme.torproject.org`:
- From `screen` session on `staticiforme.torproject.org`:
- [x] Remove old release data from following places:
- **NOTE** : Skip this step if the current release is Android or Desktop *only*
- [ ] `/srv/cdn-master.torproject.org/htdocs/aus1/torbrowser`
- [ ] `/srv/dist-master.torproject.org/htdocs/torbrowser`
- [ ] Static update components : `static-update-component cdn.torproject.org && static-update-component dist.torproject.org`
- [ ] Enable update responses : `./deploy_update_responses-alpha.sh`
- [ ] 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
- [x] Upload the `*.multi.apk` APKs
- [x] Update Release Name to Tor Browser version number
- [x] Update Release Notes
- Next to 'Release notes', click `Copy from a previous release`
- [x] 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
### 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 :
- [ ] 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`
- [x] Push to origin as new branch, open `Draft:` MR
- [x] Remove `Draft:` from MR once signed-packages are uploaded
- [x] Merge
- [ ] 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>https://gitlab.torproject.org/tpo/community/relays/-/issues/57Document relay community governance processes2024-02-06T12:34:59ZGabagaba@torproject.orgDocument relay community governance processesThis is activity O2.4 for [sponsor 112](https://gitlab.torproject.org/groups/tpo/-/milestones/44#tab-issues):
Document relay community governance processes. In this activity, we will publish public-facing documentation on what enforceme...This is activity O2.4 for [sponsor 112](https://gitlab.torproject.org/groups/tpo/-/milestones/44#tab-issues):
Document relay community governance processes. In this activity, we will publish public-facing documentation on what enforcement mechanisms were considered, why the ones that were selected were chosen, and why the ones that were not implemented but were considered as possible candidates, were eventually rejected. The audience for these documents will be future technology projects that utilize the similar volunteer-run infrastructure and may be able to benefit from the insights Tor obtained during this process.Georg KoppenGeorg Koppen2024-03-04https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41516100 pixels is letterboxed from the bottom of the window after clicking "New I...2023-08-22T20:56:51ZGhost User100 pixels is letterboxed from the bottom of the window after clicking "New Identity"### Environment
I'm using Windows 11 22H2 with 200% scaling on a 4K monitor.
### Steps to reproduce:
1. Freshly open Tor Browser
2. Visit a website and there will be no letterboxing and the browser size will be 1000x900.
3. Press the Ne...### Environment
I'm using Windows 11 22H2 with 200% scaling on a 4K monitor.
### Steps to reproduce:
1. Freshly open Tor Browser
2. Visit a website and there will be no letterboxing and the browser size will be 1000x900.
3. Press the New Identity button.
4. Visit a website and the window will look to be the same size as before but 100 "browser pixels" will be letterboxed from the bottom.
### What is the current bug behavior?
The full amount of the default browser window size is not used after pressing New Identity and is letterboxed.
### What is the expected behavior?
The default browser window size after pressing New Identity should be big enough that there is no letterboxing.ma1ma1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41515Letterboxing can change by a few px unnecessarily when opening find bar.2023-01-05T12:16:53ZhenryLetterboxing can change by a few px unnecessarily when opening find bar.## Steps to reproduce
1. Open a web page.
2. Resize the window so you have some significant letterbox padding at the bottom that can fit the find bar.
3. Open and close the find bar with Ctrl+F and Esc respectively.
## Result
The lett...## Steps to reproduce
1. Open a web page.
2. Resize the window so you have some significant letterbox padding at the bottom that can fit the find bar.
3. Open and close the find bar with Ctrl+F and Esc respectively.
## Result
The letterbox padding jumps up and down by a few pixels during the transition. This is measurable by `window.innerHeight`.
## Expect
The letterbox size should remain the same whilst the find bar is being revealed or closed.
## Cause?
I think this may have something to do with the findbar's CSS `transition` properties. During the transition the findbar is changing in size.ma1ma1https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/15Designing the User Interface of WebTunnel in Tor Browser2023-01-18T00:42:40ZshelikhooDesigning the User Interface of WebTunnel in Tor BrowserWe are currently in need of a way to let users interact with webtunnel bridges in Tor Browser.
Currently to use web tunnel, the user will need to input a custom bridge line.
For user's side we could let WebTunnel interact with users in...We are currently in need of a way to let users interact with webtunnel bridges in Tor Browser.
Currently to use web tunnel, the user will need to input a custom bridge line.
For user's side we could let WebTunnel interact with users in the same way as obfs4 to make it easier for user to understand it.
It will need a small change to allow user select type of bridge to request.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41510The "Restore Defaults" doesn't restore the Security Level preferences2023-04-19T11:34:54ZPier Angelo VendrameThe "Restore Defaults" doesn't restore the Security Level preferencesWhile reviewing !464, I've noticed that the "Restore Defaults" link in about:preferences#privacy doesn't do anything (see also https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests/464#note_2860237).
Initially, I t...While reviewing !464, I've noticed that the "Restore Defaults" link in about:preferences#privacy doesn't do anything (see also https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests/464#note_2860237).
Initially, I thought adding an `is="text-link"` was enough, because some telemetry nonsense looks for that attribute, which we're missing and we get an exception that is visible in the console.
However, adding it doesn't seem to be enough, and we might need some additional investigation.
As a workaround, the button in the panel works, so we might release 12.0 with this problem, and add it to known bugs.
/cc @richard @duncanhttps://gitlab.torproject.org/tpo/core/arti/-/issues/692Client side of onion "introduce" and "rendezvous" handshakes2023-06-13T15:33:16ZNick MathewsonClient side of onion "introduce" and "rendezvous" handshakesThese protocols are described in sections 3.2 and 4 of `rend-spec-v3.txt`. They start with the client having only a descriptor for a targeted onion service. Then:
1. The client constructs a rendezvous circuit and tells the last hop (...These protocols are described in sections 3.2 and 4 of `rend-spec-v3.txt`. They start with the client having only a descriptor for a targeted onion service. Then:
1. The client constructs a rendezvous circuit and tells the last hop (the "rendezvous point") to `ESTABLISH_RENDEZVOUS`. It waits for a `RENDEZVOUS_ESTABLISHED`.
2. The client constructs an introduction circuit to one of the introduction points listed in the descriptor, and tells it `INTRODUCE1`. It waits for a `INTRODUCE_ACK`.
3. The client waits for a `RENDEZVOUS2` message on the rendezvous circuit, and uses it to compute cryptography for a final "virtual" hop on the rendezvous circuit. This circuit is now connected to the onion service.
These handshakes have a fair amount of cryptography going on; in this ticket, we're going to try to implement all of that cryptography. It might make sense to implement the service side of the cryptography at the same time, so we have something to test it against. The message types are implemented in #690.Arti: Onion service supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/688CircMgr: Support for anonymous circuit to target non-exit relay.2023-04-25T15:37:12ZNick MathewsonCircMgr: Support for anonymous circuit to target non-exit relay.For onion services, we will frequently need to build an anonymous circuit to a target non-exit relay. We use these circuits for anonymized directory connections, introduction circuits, and rendezvous circuits.
This will likely involve a...For onion services, we will frequently need to build an anonymous circuit to a target non-exit relay. We use these circuits for anonymized directory connections, introduction circuits, and rendezvous circuits.
This will likely involve a new usage in CircMgr. (Unlike other usages, these circuits cannot generally be shared for anything else.)Arti: Onion service supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/685Encryption/decryption and signature checking for onion descriptors2023-04-25T15:32:35ZNick MathewsonEncryption/decryption and signature checking for onion descriptorsAs a follow-on or related issue to #683, we will neeed to encrypt/decrypt the inner part of an onion service descriptor using the correct keys, and validate signatures throughout.
See `rend-spec-v3.txt` section 2.5.As a follow-on or related issue to #683, we will neeed to encrypt/decrypt the inner part of an onion service descriptor using the correct keys, and validate signatures throughout.
See `rend-spec-v3.txt` section 2.5.Arti: Onion service supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/683Encode and decode onion service descriptors2023-04-25T15:20:28ZNick MathewsonEncode and decode onion service descriptorsOnion service descriptors use the same metaformat as other Tor network documents, and should probably be encoded/decoded behind an optional feature in `tor-netdoc`. The format is documented in `rend-spec-v3.txt` sections 2.4 and 2.5.
W...Onion service descriptors use the same metaformat as other Tor network documents, and should probably be encoded/decoded behind an optional feature in `tor-netdoc`. The format is documented in `rend-spec-v3.txt` sections 2.4 and 2.5.
We should separate encryption/decryption concerns from parsing/encoding concerns: this will probably mean a two-stage process for encoding/decoding.
To get example desriptors for testing, we can run a chutney network that uses onion services, with instrumentation in the C tor to cause it to dump the descriptors it generates.
Subtasks (may not be an exhaustive list):
* [x] #743 netdoc metaformat encoder
* [x] #744 hs descriptor decoder
* [x] #745 hs descriptor encoderArti: Onion service supporthttps://gitlab.torproject.org/tpo/network-health/team/-/issues/276Write a small UI in Python for displaying and sorting relay annotations2023-06-14T16:53:07ZGeorg KoppenWrite a small UI in Python for displaying and sorting relay annotationsWe could think about re-using parts of the [`python-website`](https://gitlab.torproject.org/tpo/network-health/metrics/python-website) project maybe.We could think about re-using parts of the [`python-website`](https://gitlab.torproject.org/tpo/network-health/metrics/python-website) project maybe.https://gitlab.torproject.org/tpo/tpa/team/-/issues/40979document our fastly/CDN setup2022-11-30T19:55:45Zanarcatdocument our fastly/CDN setupso we have a CDN we use here, and it's not really documented. we have fairly good docs on the ~"static-component" system, but nothing on ~Fastly. we didn't even have a tag for it until #40978 was filed (and i made it).
so we should docu...so we have a CDN we use here, and it's not really documented. we have fairly good docs on the ~"static-component" system, but nothing on ~Fastly. we didn't even have a tag for it until #40978 was filed (and i made it).
so we should document:
* [ ] what we use fastly for
* [ ] how it's configured (e.g. `cdn-config-fastly.git`, `./tor-puppet/modules/roles/files/puppetmaster/update-fastly-ips`, static-component yaml file, probably more)
* [ ] what talks to it and why not everything is on there
* [ ] what our limits are
* [ ] contact information
* [ ] password management
basically make a full service audit.anarcatanarcathttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41483Tor Browser says Firefox timed out, confusing users2022-12-07T08:44:31ZHackerNCoderhackerncoder@encryptionin.spaceTor Browser says Firefox timed out, confusing usersIf a connection times out, Tor Browser will display the default Firefox page stating "Firefox can’t establish a connection to the server". At least two people I have talked to have been confused by this, thinking it had something to do w...If a connection times out, Tor Browser will display the default Firefox page stating "Firefox can’t establish a connection to the server". At least two people I have talked to have been confused by this, thinking it had something to do with a separate Firefox installation. Please consider whether to change this.Sponsor 131 - Phase 2 - Privacy Browserhenryhenryhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40966order and ship servers for gnt-dal cluster in new datacenter2023-01-09T22:35:12Zanarcatorder and ship servers for gnt-dal cluster in new datacenteras per [TPA-RFC-43](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-43-cymru-migration-plan)as per [TPA-RFC-43](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-43-cymru-migration-plan)trusted high performance cluster (gnt-dal migration)Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.org2023-01-07https://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40151Figure out why destinations get disabled after deploying #401502023-03-16T16:44:51ZjugaFigure out why destinations get disabled after deploying #40150After deploying #40150 in longclaw's bwauth, it disabled the web servers after 4 days.
We don't know whether there's still some bug in sbws, tor CC or it's due waiting for SS=0.
To try to figure out, we've deployed #40150 with 2 thread...After deploying #40150 in longclaw's bwauth, it disabled the web servers after 4 days.
We don't know whether there's still some bug in sbws, tor CC or it's due waiting for SS=0.
To try to figure out, we've deployed #40150 with 2 threads instead of 3 and we're also going to try to measure the uploads without waiting for SS=0 to arrive.sbws: 1.6.x-finaljugajugahttps://gitlab.torproject.org/tpo/community/outreach/-/issues/40017Tor activities at FOSDEM 20232023-09-30T01:30:48ZGusTor activities at FOSDEM 2023Happening on Brussels / 4 & 5 February 2023
https://fosdem.org/2023/Happening on Brussels / 4 & 5 February 2023
https://fosdem.org/2023/https://gitlab.torproject.org/tpo/community/outreach/-/issues/40016Tor Project proposals for Mozfest 20232023-01-16T01:15:42ZGusTor Project proposals for Mozfest 2023I'm opening this ticket to coordinate the community team proposals for Mozfest.
Event: 8 to 20 June 2023, Amsterdam
CFP: The deadline to submit your proposal for MozFest 2023 is December 16th 2022. https://www.mozillafestival.org/en/pro...I'm opening this ticket to coordinate the community team proposals for Mozfest.
Event: 8 to 20 June 2023, Amsterdam
CFP: The deadline to submit your proposal for MozFest 2023 is December 16th 2022. https://www.mozillafestival.org/en/proposals/2022-12-15https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/133consider security levels for runners2023-06-28T18:44:11Zanarcatconsider security levels for runnersWikimedia foundation have an interesting approach to GitLab runner security:
https://wikitech.wikimedia.org/wiki/GitLab/Gitlab_Runner/Security_Evaluation
Basically, they have three levels:
* nothing: you bring your own runners, that ...Wikimedia foundation have an interesting approach to GitLab runner security:
https://wikitech.wikimedia.org/wiki/GitLab/Gitlab_Runner/Security_Evaluation
Basically, they have three levels:
* nothing: you bring your own runners, that would be the equivalent of everyone *not* under the `tpo/` namespace for us
* members-only: access to shared runners
* special projects: allow-list of select projects which are the only ones with access to hardened runners, and *only* on the protected branch
There's all sorts of hardening on those runners, which include:
* image restrictions: an allow-list of images that are allowed to be used for jobs
* non-root gitlab-runner
* (planned) rootless docker (see #129 for our effort at podman, which could do this as well)https://gitlab.torproject.org/tpo/core/arti/-/issues/646Resolve all `TODO pt-client` issues.2022-11-30T18:25:28ZNick MathewsonResolve all `TODO pt-client` issues.When we started sketching out our 1.1.0 work, we used the comment `TODO pt-client` to indicate something that we need to solve before 1.1.0 can be released.
~~There are still 29 occurrences of this string;~~ we should resolve them all (...When we started sketching out our 1.1.0 work, we used the comment `TODO pt-client` to indicate something that we need to solve before 1.1.0 can be released.
~~There are still 29 occurrences of this string;~~ we should resolve them all (either by fixing the issue or downgrading the `TODO`) before we release.
Once !896 and !897 are merged, there will be 10 occurrences. They are:
* [ ] 1 in `arti`
* [ ] 2 in `tor-ptmgr`
* [ ] 3 in `arti-client`
* [ ] 4 in `tor-chanmgr`Arti 1.1.0: Anticensorship ready