The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-01-30T15:02:27Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42264Update strings across bridge settings as per the designs2024-01-30T15:02:27ZdonutsUpdate strings across bridge settings as per the designsSee: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036/designs/lox-not-connected.pngSee: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036/designs/lox-not-connected.pnghenryhenryhttps://gitlab.torproject.org/tpo/web/support/-/issues/355Please add a FAQ to explain users that disabling RFP is very bad2023-11-23T15:32:50ZPier Angelo VendramePlease add a FAQ to explain users that disabling RFP is very badStarting with Tor Browser 13.0, we decided to lock `privacy.resistFingerprinting`.
RFP is a very important setting.
Disabling RFP makes you easily fingerprintable in a lot of ways, including hardware!
Generally speaking, Mozilla is well...Starting with Tor Browser 13.0, we decided to lock `privacy.resistFingerprinting`.
RFP is a very important setting.
Disabling RFP makes you easily fingerprintable in a lot of ways, including hardware!
Generally speaking, Mozilla is well aware of these fingerprinting vectors and continuously add even more.
At the moment, the protection isn't granular, it's all or nothing (and I'm not saying it's bad - quite the opposite - it's the same philosophy of Tor Browser: normalize everything).
Also, when we send patches to Mozilla, we often gate them behind RFP.
Setting RFP to false is like telling that you don't want a bunch of our patches.
RFP has usability issues (e.g., it constantly resets the zoom level, which can be a big accessibility problem).
We're aware of that and it's in our roadmap.
We've received some feedback against our decision after the release, and we still get from time to time.
I think we could have a FAQ about this.ebanamebanam@torproject.orgebanamebanam@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42262Mask icon not centered and should either be removed or centered2024-01-09T13:51:01ZclairehurstMask icon not centered and should either be removed or centered<!--
* Use this issue template for reporting a new bug.
-->
### Summary
**Summarize the bug encountered concisely.**
On the tabs screen, there is a mask icon at the top signalling private tabs. All tabs are private so I would be fine to...<!--
* Use this issue template for reporting a new bug.
-->
### Summary
**Summarize the bug encountered concisely.**
On the tabs screen, there is a mask icon at the top signalling private tabs. All tabs are private so I would be fine to remove it entirely. If we don't want to remove it, it should be centered to look better.
### Steps to reproduce:
**How one can reproduce the issue - this is very important.**
1. Connect to Tor
2. Tap on the tabs icon in the bottom right, it looks like a square with a "0" inside it (or how ever many tabs you have open)![Screenshot_2023-11-13_at_18.19.25](/uploads/fac0b19b976ba4da275b59556632e43b/Screenshot_2023-11-13_at_18.19.25.png)
3. Notice the mask icon not being centered (screenshot shown below)
### What is the current bug behavior?
**What actually happens.**
Mask icon is off center, off to the left
### What is the expected behavior?
**What you want to see instead**
Mask icon either being centered, or removed
### Relevant logs and/or screenshots
![Your_private_tabs_will_be_shown_here.](/uploads/286ccc6b280d3e42eecb8881a89cedd4/Your_private_tabs_will_be_shown_here..png){width=25%}clairehurstclairehursthttps://gitlab.torproject.org/tpo/web/community/-/issues/329webtunnel-from-source instructions close your ORPort without explaining that ...2023-11-15T09:46:36ZRoger Dingledinewebtunnel-from-source instructions close your ORPort without explaining that your bridge will seem downOn https://community.torproject.org/relay/setup/webtunnel/source/ we tell the bridge operator to set ORPort to 127.0.0.1 and set AssumeReachable. This is so their ORPort isn't reachable from the outside world. But at present it will resu...On https://community.torproject.org/relay/setup/webtunnel/source/ we tell the bridge operator to set ORPort to 127.0.0.1 and set AssumeReachable. This is so their ORPort isn't reachable from the outside world. But at present it will result in two surprises for bridge operators:
* They will get "The IPv4 ORPort address 127.0.0.1 does not match the descriptor address <redacted: IP of the relay server>" scary log messages, which make them think something is wrong with their configuration
* In tor metrics, the bridge is shown in "Red" status being "down" since a couple of hours. That's because they don't have the Running flag from the bridge authority.
We should either (A) change the instructions to explain that we're having them do the experimental new closed-ORPort approach, and tell them what side effects to expect; or (B) change the instructions to have an open ORPort for now until we've finished https://gitlab.torproject.org/tpo/core/tor/-/issues/7349
Issue reported by a new webtunnel bridge operator on #tor-relays. Thanks!https://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40191Debian package: solve systemd unit permissions when enabling apparmor2024-02-05T08:25:05ZjugaDebian package: solve systemd unit permissions when enabling apparmorsbws: 1.9.x-finaljugajugahttps://gitlab.torproject.org/tpo/community/policies/-/issues/13Delete the master branch2024-01-24T21:10:23ZSilvio RhattoDelete the master branchThis branch was [phased out](tpo/community/policies#12). Next step is to remove it from GitLab after a while, giving time to people update their refs.This branch was [phased out](tpo/community/policies#12). Next step is to remove it from GitLab after a while, giving time to people update their refs.https://gitlab.torproject.org/tpo/community/l10n-for-markdown/-/issues/1Document how to integrate with the translation repository2024-01-24T21:11:33ZSilvio RhattoDocument how to integrate with the translation repositoryDocument how this project can be used in an integrated workflow with the [translations repository](https://gitlab.torproject.org/tpo/translation), in accordance with the [Localization for developers](https://gitlab.torproject.org/tpo/com...Document how this project can be used in an integrated workflow with the [translations repository](https://gitlab.torproject.org/tpo/translation), in accordance with the [Localization for developers](https://gitlab.torproject.org/tpo/community/l10n/-/wikis/Localization-for-developers) document.https://gitlab.torproject.org/tpo/community/hackweek/-/issues/33Add license2023-11-15T15:08:32ZSilvio RhattoAdd licenseThis project needs a copyright/copyleft license.
This is not a regular Hackweek proposal. Instead, it's is an actual task to improve it's documentation.This project needs a copyright/copyleft license.
This is not a regular Hackweek proposal. Instead, it's is an actual task to improve it's documentation.https://gitlab.torproject.org/tpo/community/hackweek/-/issues/32Improve formatting for past Hackweek documentations2024-02-13T20:06:20ZSilvio RhattoImprove formatting for past Hackweek documentationsWhile working on tpo/community/hackweek#13, Hackweek got a website: https://tpo.pages.torproject.net/community/hackweek/
Now it's way easier to browse and search for past projects, but this also exposes the need to fix formatting at som...While working on tpo/community/hackweek#13, Hackweek got a website: https://tpo.pages.torproject.net/community/hackweek/
Now it's way easier to browse and search for past projects, but this also exposes the need to fix formatting at some pages.
This ticket is about fixing the formatting for the existing docs.
This is not a regular Hackweek proposal. Instead, it's is an actual task to improve it's documentation.https://gitlab.torproject.org/tpo/community/training/-/issues/124Index of presentations in the home slide deck2024-01-24T21:10:16ZSilvio RhattoIndex of presentations in the home slide deckBuild an index of presentations in the [home slides]:
* Listing the ones from the current year, and the outdated ones.
* Linking to all available assets for a given slide (ODP, PDF, HTML etc).
* To be built as part of the CI Pipeline.
...Build an index of presentations in the [home slides]:
* Listing the ones from the current year, and the outdated ones.
* Linking to all available assets for a given slide (ODP, PDF, HTML etc).
* To be built as part of the CI Pipeline.
[home slides]: https://tpo.pages.torproject.net/community/training/https://gitlab.torproject.org/tpo/tpa/status-site/-/issues/37merge "experiment" support upstream2023-11-16T10:37:19Zanarcatmerge "experiment" support upstreamit would be nice if some of our most important divergences were merged upstream.
right now, we have this:
```
anarcat@angela:status.torproject.org$ find layouts/ -type f
layouts/README.md
layouts/partials/custom/meta.html
layouts/part...it would be nice if some of our most important divergences were merged upstream.
right now, we have this:
```
anarcat@angela:status.torproject.org$ find layouts/ -type f
layouts/README.md
layouts/partials/custom/meta.html
layouts/partials/index/noscript.html
layouts/partials/index/components.html
layouts/experiments/small.html
layouts/experiments/single.html
layouts/experiments/single.json
layouts/experiments/experiment.html
```
out of those:
* `layout/experiments/*` doesn't actually override anything upstream: it's all new, so that's relatively safe
* `meta.html` is an expected override (upstream is just a commented out example)
* `noscript.html` is an expected override: we silence the upstream warning about noscript... we *could* upstream this as a toggle, but it seems overkill
* `layouts/partials/index/components.html`, on the other hand, is quite a diff
In !46, I actually tried to merge that file with the latest upstream, to fix broken links in review apps (#36)... the merge wasn't quite trivial, but more importantly, it wasn't obvious we even *had* to merge something in there.
It would be nice to consider upstreaming our changes here. We could find a way to patch the upstream repo to add support for experiments. I think that would involve sending a PR upstream, alongside some docs fixes to document the feature.
What do you think, @gk? Is that something you think could be done?https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42255lock pdfjs.disabled to false in stable2024-01-09T14:37:09ZThorinlock pdfjs.disabled to false in stablein FF116 [1838415](https://bugzilla.mozilla.org/show_bug.cgi?id=1838415) in [Don't spoof explicitly disabled pdfJS](https://phabricator.services.mozilla.com/D180938) RFP no longer ignores the pref `pdfjs.disabled`. The original RFP prote...in FF116 [1838415](https://bugzilla.mozilla.org/show_bug.cgi?id=1838415) in [Don't spoof explicitly disabled pdfJS](https://phabricator.services.mozilla.com/D180938) RFP no longer ignores the pref `pdfjs.disabled`. The original RFP protection was done to help against disk leaks and to provide a uniform fingerprint [1]
Given these two aspects, we should just lock the pref in stable release
[1] There are only two possible values for combined plugins, mimeTypes and pdfViewerEnabledhttps://gitlab.torproject.org/tpo/community/training/-/issues/123Switch from "master" to "main" branch2024-03-05T16:32:50ZSilvio RhattoSwitch from "master" to "main" branch# Tasks
* [ ] Switch the repository from "master" to the "main" branch.
* [ ] Update references on the [Training resources page at the Community Portal][] pointing to the correct branch, like in [this file][].
[Training resources page ...# Tasks
* [ ] Switch the repository from "master" to the "main" branch.
* [ ] Update references on the [Training resources page at the Community Portal][] pointing to the correct branch, like in [this file][].
[Training resources page at the Community Portal]: https://community.torproject.org/training/resources/
[this file]: https://gitlab.torproject.org/tpo/web/community/-/blob/main/databags/community-training-materials.jsonhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41387create an alert if a machine's network interface goes down2023-11-08T15:17:51ZKezcreate an alert if a machine's network interface goes downwe should crate some kind of big, scary, hard to miss alert when one of our machines has a network interface go down. a network interface going down could be a sign of an attack, hardware/software failure, misconfiguration, or other bad ...we should crate some kind of big, scary, hard to miss alert when one of our machines has a network interface go down. a network interface going down could be a sign of an attack, hardware/software failure, misconfiguration, or other bad things. this alert shouldn't disappear when the interface comes back up, and ideally TPA should be able to temporarily disable the alert for planned maintenance.https://gitlab.torproject.org/tpo/applications/rbm/-/issues/40064Using exec on project with no git_url/hg_url is causing warning2023-11-27T16:23:54ZboklmUsing exec on project with no git_url/hg_url is causing warningUsing `exec('something')` in a project which doesn't have a `git_url` or
`hg_url` is causing the following warnings:
```
Use of uninitialized value $res_name in hash element at rbm/lib/RBM.pm line 579.
Use of uninitialized value $res_na...Using `exec('something')` in a project which doesn't have a `git_url` or
`hg_url` is causing the following warnings:
```
Use of uninitialized value $res_name in hash element at rbm/lib/RBM.pm line 579.
Use of uninitialized value $res_name in hash element at rbm/lib/RBM.pm line 580.
```boklmboklmhttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/38Update Lox Distributor Config file to request Lox type2023-11-09T03:49:09ZonyinyangUpdate Lox Distributor Config file to request Lox typeThis should work in tandem with an update to `rdsys` that partitions bridges in to a `lox` type. This will only require an update to the test config file in the lox-distributor repo but this issue is mostly a reminder to update once a `l...This should work in tandem with an update to `rdsys` that partitions bridges in to a `lox` type. This will only require an update to the test config file in the lox-distributor repo but this issue is mostly a reminder to update once a `lox` type exists.onyinyangonyinyanghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42253Remove "New private tab" action and widget2024-02-22T13:38:36ZclairehurstRemove "New private tab" action and widget<!--
* Use this issue template for reporting a new bug.
-->
### Summary
**Summarize the bug encountered concisely.**
After a long press on the icon, there is a "New private tab" button that has a lot of issues surrounding it (often brea...<!--
* Use this issue template for reporting a new bug.
-->
### Summary
**Summarize the bug encountered concisely.**
After a long press on the icon, there is a "New private tab" button that has a lot of issues surrounding it (often breaking the app) and I don't think that we need it. For instance if you tap on it when already connected to tor, you can get the screen in the second screenshot. If you then try to search you get the 3rd screenshot. It also has firefox branding (the eye mask).
### Relevant logs and/or screenshots
![Screenshot_2023-11-06_at_16.24.07](/uploads/2aa2eaf031aac3c14880cbca53686643/Screenshot_2023-11-06_at_16.24.07.png){width=25%}
![Screenshot_2023-11-06_at_16.41.11](/uploads/53a6a6e68f731283a643758305f071d5/Screenshot_2023-11-06_at_16.41.11.png){width=25%}
![Screenshot_2023-11-06_at_16.43.13](/uploads/1e8b83540fa18a73a585a2ef5d9843b4/Screenshot_2023-11-06_at_16.43.13.png){width=25%}clairehurstclairehursthttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41011Remove tor-onion-proxy-library project2023-11-06T23:31:41ZrichardRemove tor-onion-proxy-library projectThis will be deprecated with the remaining ~"Sponsor 96" work.This will be deprecated with the remaining ~"Sponsor 96" work.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41010Create a project to ship tor binaries in an Android-developer friendly way2024-02-05T18:15:26ZrichardCreate a project to ship tor binaries in an Android-developer friendly way`tor-onion-proxy-library` is going away, we need to setup the torrc and populate tor+PTs using the `tor-expert-bundle` project`tor-onion-proxy-library` is going away, we need to setup the torrc and populate tor+PTs using the `tor-expert-bundle` projectSponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/core/arti/-/issues/1098Rethink publisher retry loop2024-01-09T17:28:02Zgabi-250Rethink publisher retry loopThe publisher currently retries any failed uploads using its `PublisherBackoffSchedule`. The retry mechanism involves retrying the failed upload until it succeeds, or until the the timeout specified in `PublisherBackoffSchedule::timeout(...The publisher currently retries any failed uploads using its `PublisherBackoffSchedule`. The retry mechanism involves retrying the failed upload until it succeeds, or until the the timeout specified in `PublisherBackoffSchedule::timeout()` elapses.
However, if the descriptor can't be uploaded after `PublisherBackoffSchedule::timeout()` time units of trying, it will be declared a failure (UploadStatus::Failure), and never retried again. We should consider improving the situation: the publisher shouldn't idle if there are some known, retriable failed uploads. We should have some sort of (almost) infinite retry loop, somewhat like the one sketched out in !1823 (but we shouldn't have two retry loops).
The upload result reporting makes this a bit complicated. The "dirtiness" of each HsDir needs to be updated after the upload, and we can't acquire the lock to do that in the function where the upload happens. This ticket will involve rethinking how we report and update the HsDir statuses.Arti: Onion service supportgabi-250gabi-250