The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-01-25T10:23:09Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42293Updater is disabled when tor-browser is run by torbrowser-launcher flatpak2024-01-25T10:23:09ZboklmUpdater is disabled when tor-browser is run by torbrowser-launcher flatpakIt looks like Tor Browser updater is disabled when run from the Flatpak
version of torbrowser-launcher:
- https://github.com/torproject/torbrowser-launcher/issues/721#issuecomment-1824742227
- https://searchfox.org/mozilla-central/source...It looks like Tor Browser updater is disabled when run from the Flatpak
version of torbrowser-launcher:
- https://github.com/torproject/torbrowser-launcher/issues/721#issuecomment-1824742227
- https://searchfox.org/mozilla-central/source/toolkit/mozapps/update/AppUpdater.sys.mjs#404
This is probably what we want when we'll have a Tor Browser Flatpak, but
not for the torbrowser-launcher Flatpak.boklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42172browser.startup.homepage and TOR_DEFAULT_HOMEPAGE are ignored for the new win...2023-11-27T08:34:38ZRusty Birdbrowser.startup.homepage and TOR_DEFAULT_HOMEPAGE are ignored for the new window opened by New Identity### Summary
In 13.0, the `browser.startup.homepage` pref (and hence also the `TOR_DEFAULT_HOMEPAGE` environment variable, which populates the pref) is no longer used for the initial new window that is opened by `New Identity`. This new ...### Summary
In 13.0, the `browser.startup.homepage` pref (and hence also the `TOR_DEFAULT_HOMEPAGE` environment variable, which populates the pref) is no longer used for the initial new window that is opened by `New Identity`. This new window uses `about:tor` instead.
### Steps to reproduce:
1. Run `TOR_DEFAULT_HOMEPAGE='https://example.com/' ./start-tor-browser`
2. Connect
3. Trigger `New Identity`
### Environment
Linux (x86_64)https://gitlab.torproject.org/tpo/core/tor/-/issues/40860Sort introduction points before encoding?2023-09-18T13:31:13ZNick MathewsonSort introduction points before encoding?It might be a good idea to make sure that when we encode introduction points, we do so in a standard order so that we don't leak any information. Right now, introduction points are selected in `pick_needed_intro_points()` and encoded in...It might be a good idea to make sure that when we encode introduction points, we do so in a standard order so that we don't leak any information. Right now, introduction points are selected in `pick_needed_intro_points()` and encoded in `get_inner_encrypted_layer_plaintext()`.
This probably needs a specification change too. See also arti#1039.Tor: 0.4.7.x-post-stablehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40858Failing to initialize sendme_inc when building the descriptor structure cause...2023-09-21T13:03:40Zhyunsoo.kim676Failing to initialize sendme_inc when building the descriptor structure causes hidden service performance and availability issuesI believe I have found a bug with quite a serious impact in the TOR relay code, and my PI suggested that I report it.
The bug affects TOR 0.4.7.13 and 0.4.8.5 (at least).
Line numbers that are referenced are based on release-0.4.7
...I believe I have found a bug with quite a serious impact in the TOR relay code, and my PI suggested that I report it.
The bug affects TOR 0.4.7.13 and 0.4.8.5 (at least).
Line numbers that are referenced are based on release-0.4.7
The details are below.
Bug:
Failing to initialize sendme_inc when building the descriptor structure causes hidden service performance and availability issues.
Details:
In hs_service.c, in the function build_service_desc_encrypted, the hidden service initializes the encrypted structure of the descriptor structure (of type hs_service_descriptor_t). In this function, the variables sendme_inc and flow_control_pv are not initialized, although they should be.
At first glance, there’s no impact, as these fields of the descriptor structure are not used when encoding the descriptor before sending it to the client. Instead, when encoding the descriptor, the correct sendme_inc and protocol version values from the consensus are used (see hs_descriptor.c line 778), so that the client receives correct values, hence there’s no impact on the sendme mechanism.
However, there’s another place where one of these fields, senme_inc, IS used by the hidden service. In the function hs_service_new_consensus_params(), in line hs_service.c line 3716, the code checks to see where sendme values have changed in the new consensus. The value of current_sendme_inc is a fixed 31. But the value of desc->desc->encrypted_data.sendme_inc is erroneously 0 (as it has never been initialized). This causes the condition to always return true. The impact of this is that all introduction points from both descriptors are immediately expired any time a new consensus is received.
Impact analysis:
According to our analysis, expiry of ALL introduction points, from both descriptors, all at once, causes an availability issue. Every time a consensus is received (roughly every hour on average), the service is not available for up to two minutes, as the descriptor cache of the clients is valid for two minutes. Until the clients load a new descriptor, the service is not available.
In addition, the expiry of introduction points may lead to unnecessary hidden service descriptor uploads, which may affect the performance of both TOR clients and relays.
Fix:
We suggest the following fix.
In hs_service.c, in line 1768, add the line:
encrypted->sendme_inc=congestion_control_sendme_inc();
We have downloaded the source code and built it with the fix, and it seems to solve the problem.Tor: 0.4.7.x-post-stableMike PerryMike Perryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42099Blind cross-origin requests to .tor.onion domains2024-03-11T12:28:48ZPier Angelo VendrameBlind cross-origin requests to .tor.onion domainsPoC:
```html
<!DOCTYPE html>
<html>
<body>
<span></span>
<script>
const target = document.querySelector("span");
const before = Date.now();
const img = new Image();
img.onload = () => {
target.textContent = (Date.now() - bef...PoC:
```html
<!DOCTYPE html>
<html>
<body>
<span></span>
<script>
const target = document.querySelector("span");
const before = Date.now();
const img = new Image();
img.onload = () => {
target.textContent = (Date.now() - before);
};
img.onerror = () => {
target.textContent = (Date.now() - before);
};
img.src = "https://nytimes.securedrop.tor.onion";
</script>
</body>
</html>
```
Pref on: hundreds of ms, even thousands
Pref off: 0 or 16-17 (the request is immediately rejected because the resolution fails, even though at least the browser doesn't say the cause).
We should find a way to allow onion aliases only when the document initializing a request is in the same eTLD.
And if we extend the functionality to support more lists, it will be a nightmare: users could be fingerprinted on the list they have, like uBlock Origin.
/cc @ma1 @thorinma1ma1https://gitlab.torproject.org/tpo/core/tor/-/issues/40694hs: Client rendez-vous circuit expiry is a mess2022-11-10T15:09:25ZDavid Gouletdgoulet@torproject.orghs: Client rendez-vous circuit expiry is a messIt turns out that once a rendezvous circuit is ready waiting for the `RENDEZVOUS2` to arrive ( `CIRCUIT_PURPOSE_C_REND_READY_INTRO_ACKED`), we expire that circuit with `general_cutoff` which is a very very low value. We then flip `circ->...It turns out that once a rendezvous circuit is ready waiting for the `RENDEZVOUS2` to arrive ( `CIRCUIT_PURPOSE_C_REND_READY_INTRO_ACKED`), we expire that circuit with `general_cutoff` which is a very very low value. We then flip `circ->hs_circ_has_timed_out` indicating that it timed out "but we'll keep it around in case it works". However, in `circuit_is_acceptable()`, we return false if that flag is set meaning once flagged, it is good as dead until it finalizes which can be "never".
So, in the meantime, other rendezvous circuits get opened until one finally finalizes (all to the same RP). This can lead to a bomb of circuits opening by the client because it ain't cap and if the service never replies (because under DoS ;), then the client will just keep on trying.
There are a many issues here:
1. The cutoff of such circuit should be much higher because we end up in that circuit purpose when the `INTRODUCE_ACK` is received which could be *before* the service receives the `INTRODUCE2` cell. Thus, the worst case is a full 3 hop latency, a 4-hop circuit creation latency (service -> RP), and then a 7-hop latency for the `RENDEZVOUS2` cell to arrive. After talking to Mike, we'll apply a large value as in taking the basic CBT and multiplying it by 3.
2. We should get rid of `hs_circ_has_timed_out` because it is extremely fragile in its current logic and we should simply apply a much longer CBT for the `CIRCUIT_PURPOSE_C_REND_READY_INTRO_ACKED` purpose.
3. It turns out that we can't have RP circuits in parallel to the same RP. The RP relay will discard any old circuits if a new one shows up with the same cookie. And so this whole dance is pointless.
4. Unrelated, the service rendezvous establish timeout cutoff is too low, it should be the "four hop" circuit cutoff and not the general cutoff so this also needs to be bumped.
5. I'm sure I'll find more problems in this logic.
Again, we need to backport this for the sake of HS client UX.Tor: 0.4.8.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40436Migrate bridge_prefs.js to intermediate file format2022-03-11T18:14:29ZrichardMigrate bridge_prefs.js to intermediate file formatrdsys wants to read the most up-to-date bridge lines from the tor-browser-build repo, rather than having duplicate sources of truth. Currently, bridge lines are deployed to the tor-browser prefs by the `bridge_prefs.js` file.
Rather th...rdsys wants to read the most up-to-date bridge lines from the tor-browser-build repo, rather than having duplicate sources of truth. Currently, bridge lines are deployed to the tor-browser prefs by the `bridge_prefs.js` file.
Rather than having rdsys parse this javascript file, we should instead store the bridge lines in some intermediate data format (json, csv, etc) that can be easily parsed by rdsys and some new script in the tor-browser project which will generate `bridge_prefs.js` at build time.boklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40717UX: hide SSO2023-02-15T18:05:31ZThorinUX: hide SSO[bugzilla 1740777](https://bugzilla.mozilla.org/show_bug.cgi?id=1740777)
since we disable it this would be a simple fix @duncan - edit: just use all windows versions[bugzilla 1740777](https://bugzilla.mozilla.org/show_bug.cgi?id=1740777)
since we disable it this would be a simple fix @duncan - edit: just use all windows versionsSponsor 131 - Phase 2 - Privacy Browserrichardrichardhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40509relay: Stop advertising HSv2 protocol version2022-02-05T21:30:38ZDavid Gouletdgoulet@torproject.orgrelay: Stop advertising HSv2 protocol versionWe just disabled v2 in 035+ and so we should make the relays stop advertising the protocol version.
Tor clients don't use protocol versions to learn if a relay can be used for onion service v2 so this shouldn't change much. But it could...We just disabled v2 in 035+ and so we should make the relays stop advertising the protocol version.
Tor clients don't use protocol versions to learn if a relay can be used for onion service v2 so this shouldn't change much. But it could for any alt-implementation out there that uses those for v2.
Essentially, relay protocol version should be set to:
- `HSIntro=4-5` -> removing `3` which is v2 specific.
- `HSDir=2` -> removing `1` which is v2 specific.Tor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40434Don't set router is_running=false after intentionally closing a directory con...2022-07-07T00:47:10ZoparaDon't set router is_running=false after intentionally closing a directory connectionIn a testing tor network with a few relays, clients, and an onion service, the onion service will call `run_upload_descriptor_event()` periodically to upload its service descriptor. This eventually calls `directory_initiate_request()` wh...In a testing tor network with a few relays, clients, and an onion service, the onion service will call `run_upload_descriptor_event()` periodically to upload its service descriptor. This eventually calls `directory_initiate_request()` which creates a new dir connection for the upload. In the future when `run_upload_descriptor_event()` runs again, it will first call `close_directory_connections()` to mark for close any existing/incomplete descriptor uploads for that service. Later (on the next 1 second libevent timer) the dir connection will be closed and since the upload didn't finish, `connection_dir_client_request_failed()` will set the router's `is_running` field to false.
The problem is that `run_upload_descriptor_event()` can run shortly after a previous run, and in a shadow simulation, this can run only 2 seconds after a previous run. If the descriptor upload has not finished in this 2 seconds, the router will be marked as not running and will not be added to the routerlist when building circuits. Since this dir client request can fail often due to tor's new circuit timeout learning, in small tor networks we quickly run out of nodes in the routerlist, and end up with:
```
Jan 01 00:17:50.000 [info] compute_weighted_bandwidths(): Empty routerlist passed in to consensus weight node selection for rule weight as middle node
Jan 01 00:17:50.000 [info] router_choose_random_node(): We couldn't find any live, stable routers; falling back to list of all routers.
Jan 01 00:17:50.000 [info] compute_weighted_bandwidths(): Empty routerlist passed in to consensus weight node selection for rule weight as middle node
Jan 01 00:17:50.000 [warn] No available nodes when trying to choose node. Failing.
Jan 01 00:17:50.000 [info] pick_needed_intro_points(): Unable to find a suitable node to be an introduction point for service r4aj4kaqf46mala2yykldkvwrrwjagab2qppuqtvgdxwh6spsulwu2qd.
```
I propose to not mark a router as "not running" if tor intentionally closes a directory connection (except maybe for a `TestingDirConnectionMaxStall` timeout).Tor: 0.4.7.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40287Switch from POST to GET for DDG Searches2021-02-28T04:28:40ZpeterstorySwitch from POST to GET for DDG SearchesAs documented in a recent Tor-usability paper ("Peeling the Onion’s User Experience Layer,” by Gallagher et al. 2018)
> “I did run into a quirk, and I do not know if this was due to Tor or DuckDuckGo. I use StackOverFlow to get help on c...As documented in a recent Tor-usability paper ("Peeling the Onion’s User Experience Layer,” by Gallagher et al. 2018)
> “I did run into a quirk, and I do not know if this was due to Tor or DuckDuckGo. I use StackOverFlow to get help on coding problems and whenever I clicked back it took me to the main page of Tor and not to the list of search events. This was very frustrating because I had to retype my query and look for it again.” – (P6, F, 22, write-up)
This issue has the potential to seriously impact usability, because when following links in search, a significant percent of linked websites block Tor users. When a user encounters a page which blocks them, they will probably try to return to the search results to try another website. Crucially, the back button not returning to the search results breaks this workflow.
As [discussed on the tbb-dev mailing list](https://lists.torproject.org/pipermail/tbb-dev/2020-December/001178.html), this is due to DuckDuckGo being configured to issue searches using POST instead of GET. Thankfully, this is an easy fix, which requires just a couple small changes to two files:
* `tor-browser.git/browser/components/search/extensions/ddg/manifest.json` (for the search bar)
* `torbutton.git/chrome/content/aboutTor/aboutTor.xhtml` (for search on the homepage)
I've tested these changes in a local build of Tor Browser, and they have the desired effect of enabling the back-button to work.
NOTE: Tor Browser on Android seems to already use GET, so this is not a problem there.
## To reproduce this issue
1. Open a new window
2. Search using either the URL bar or the “Search with DDG” field. On the page with search results, note that the page’s URL doesn’t contain the search query in the URL parameters.
3. Click on a link in the search results
4. Click the back button
* Actual behavior: you are returned to a blank search page
* Expected behavior: you are returned to your search resultsTor Browser: 10.5https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41110Avoid Fontconfig warning about "ambiguous path"2024-03-27T08:15:02ZRusty BirdAvoid Fontconfig warning about "ambiguous path" $ ./start-tor-browser --verbose
Fontconfig warning: "/home/user/tor-browser/Browser/fontconfig/fonts.conf", line 42: Use of ambiguous path in <dir> element. please add prefix="cwd" if current behavior is desired.
I'll open a mer... $ ./start-tor-browser --verbose
Fontconfig warning: "/home/user/tor-browser/Browser/fontconfig/fonts.conf", line 42: Use of ambiguous path in <dir> element. please add prefix="cwd" if current behavior is desired.
I'll open a merge request that adds `prefix="cwd"`.Rusty BirdRusty Birdhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42459Add startpage onion service to list of search providers2024-03-26T21:17:06ZrichardAdd startpage onion service to list of search providersStartpage has added a new onion service, so lets add it to the list of built-in search providers.
URL: http://startpagel6srwcjlue4zgq3zevrujfaow726kjytqbbjyrswwmjzcqd.onion/
We'd like this in the next stable release 13.0.12 and the nex...Startpage has added a new onion service, so lets add it to the list of built-in search providers.
URL: http://startpagel6srwcjlue4zgq3zevrujfaow726kjytqbbjyrswwmjzcqd.onion/
We'd like this in the next stable release 13.0.12 and the next alpha release 13.5a6Dan BallardDan Ballardhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41102src archive does not match likely due to mismatched xz-utils version2024-03-11T14:50:02Zrichardsrc archive does not match likely due to mismatched xz-utils versionDiscovered during the 13.0.11 release, the underlying tar archive does match, so this is just a matter of the xz generation differing betwen versions:
- https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41101#not...Discovered during the 13.0.11 release, the underlying tar archive does match, so this is just a matter of the xz generation differing betwen versions:
- https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41101#note_3004284boklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42435Update moat domain fronting configuration2024-03-26T20:56:08ZCecylia BocovichUpdate moat domain fronting configurationThe front we're currently using for moat (foursquare.com) renewed its certificate today, which brought into effect [Fastly's new policy to match the Host header to the cert SANs](https://github.com/net4people/bbs/issues/309). Moat won't ...The front we're currently using for moat (foursquare.com) renewed its certificate today, which brought into effect [Fastly's new policy to match the Host header to the cert SANs](https://github.com/net4people/bbs/issues/309). Moat won't work until we update the `bridgedb_front` and `bridgedb_reflector` prefs. We're discussing what the new domain fronting configuration should be in https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/135Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/271After update, don't open the release page on Github. Instead link it in the s...2024-03-26T20:57:03ZruihildtAfter update, don't open the release page on Github. Instead link it in the startpage, like in Tor BrowserUsers are complaining a Github page is opening automatically after update (which I entirely agree is unnecessary and unwelcome).
Could we adopt the same flow as in Tor Browser.
See screenshot:
![image](/uploads/e19a1ed79ffdf358bf738ff...Users are complaining a Github page is opening automatically after update (which I entirely agree is unnecessary and unwelcome).
Could we adopt the same flow as in Tor Browser.
See screenshot:
![image](/uploads/e19a1ed79ffdf358bf738ffb8be9b953/image.png)richardrichardhttps://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/270Mullvad support email has changed from `support@mullvad.net` to `support@mull...2024-03-05T12:59:36ZruihildtMullvad support email has changed from `support@mullvad.net` to `support@mullvadvpn.net`From `support@mullvad.net` to `support@mullvadvpn.net`From `support@mullvad.net` to `support@mullvadvpn.net`Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41085kick_devmole_build script prints wrong URL for Mullvad's build hashes2024-03-05T16:39:24Zrichardkick_devmole_build script prints wrong URL for Mullvad's build hashesMissing `browser` in the path and a trailing /Missing `browser` in the path and a trailing /richardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42402Remove Android YEC strings2024-02-08T09:18:22ZPier Angelo VendrameRemove Android YEC stringsIn firefox-android!58 I missed the strings. We should remove them.
Desktop strings have already been removed.In firefox-android!58 I missed the strings. We should remove them.
Desktop strings have already been removed.Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41067Use Capture::Tiny instead of IO::CaptureOutput2024-01-31T08:52:10ZSertonixUse Capture::Tiny instead of IO::CaptureOutput[IO::CaptureOutput](https://metacpan.org/pod/IO::CaptureOutput) has been marked as deprecated. I think it is not a good idea to have deprecated dependencies so it would be nice to remove it.
- [ ] update instructions in README[IO::CaptureOutput](https://metacpan.org/pod/IO::CaptureOutput) has been marked as deprecated. I think it is not a good idea to have deprecated dependencies so it would be nice to remove it.
- [ ] update instructions in READMEboklmboklm