The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-01-21T21:12:14Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40227Add ccls compile_commands.json auto-generation support2021-01-21T21:12:14ZDavid Gouletdgoulet@torproject.orgAdd ccls compile_commands.json auto-generation supportFor those in this world that use a LSP and `ccls` along with tor code base, this ticket is about adding a `make lsp` command that would use `bear` to generate the `compile_commands.json` to the root of tor.git.
Next step will be to add ...For those in this world that use a LSP and `ccls` along with tor code base, this ticket is about adding a `make lsp` command that would use `bear` to generate the `compile_commands.json` to the root of tor.git.
Next step will be to add a proper `.ccls` file defining all the `-D*_PRIVATE` that we have in order to access those symbols.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40346DuckDuckGo redirect to html doesn't work2021-02-19T11:53:30ZHackerNCoderhackerncoder@encryptionin.spaceDuckDuckGo redirect to html doesn't workA few users over at [reddit](https://old.reddit.com/r/TOR/comments/lm8fgr/tor_browser_not_working_for_anyone_else/) have noticed that DuckDuckGo, Startpage and other such sites do not redirect to their non-javascript versions or work sud...A few users over at [reddit](https://old.reddit.com/r/TOR/comments/lm8fgr/tor_browser_not_working_for_anyone_else/) have noticed that DuckDuckGo, Startpage and other such sites do not redirect to their non-javascript versions or work suddenly when using safest security level.
I believe I have narrowed down the problem to the new feature to disallow noscript (the HTML element) in NoScript (the extension). Setting DDG and Startpage to custom and allowing noscript made them work.
Because of how Tor Browser does NoScript options, restarting or changing security level will make the user have to enable the noscript tag again.
I recommend that the noscript tag be added on the safest.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40245Rebuild all container images after #236312021-03-01T19:20:23ZboklmRebuild all container images after #23631In #40240 we found that package updates were not installed in containers
created using debootstrap, but are now installed in the containers
created with mmdebstrap. Some of those updates are causing differences
in the build of some compo...In #40240 we found that package updates were not installed in containers
created using debootstrap, but are now installed in the containers
created with mmdebstrap. Some of those updates are causing differences
in the build of some components.
To be able to build both the stable and master branches from the same
tor-browser-build directory without sharing containers, I think we should
update the filenames of all containers.boklmboklmhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40177check.tpo is unavailable2021-02-19T20:00:35ZGuscheck.tpo is unavailableThe website check.tpo is returning 503 Service Unavailable.The website check.tpo is returning 503 Service Unavailable.https://gitlab.torproject.org/tpo/core/tor/-/issues/40229Audit strstr() calls to see which should be find_str_at_start_of_line().2021-03-03T20:05:24ZNick MathewsonAudit strstr() calls to see which should be find_str_at_start_of_line().Related to #40226 -- we sometimes have a string that we want to find at the start of a line only, but instead we look for it with `strstr()`. That's not right: if you just do `strstr(s, "target")` then you'll match a line like `prefixed...Related to #40226 -- we sometimes have a string that we want to find at the start of a line only, but instead we look for it with `strstr()`. That's not right: if you just do `strstr(s, "target")` then you'll match a line like `prefixed-target ...`. But if you do `strstr(s, "\n target")` then you'll miss `target` at the start of a file.
We should go through our uses of strstr() and see which of them, if any, should be modified to use find_str_at_start_of_line().Tor: 0.4.6.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40246Prep 10.0.132021-03-02T15:50:23ZMatthew FinkelPrep 10.0.13Tor Browser: 10.0https://gitlab.torproject.org/tpo/tpa/team/-/issues/40179Please change correspondence@ email alias forwarding2021-02-23T19:07:50ZErin WyattPlease change correspondence@ email alias forwardingHello. Please change correspondence@ to forward to frontdesk@. We don't know why this alias was created, but it' only gets a few emails and is redundant w/ frontdesk@. However, we speculate it may be tied to some important accounts, so w...Hello. Please change correspondence@ to forward to frontdesk@. We don't know why this alias was created, but it' only gets a few emails and is redundant w/ frontdesk@. However, we speculate it may be tied to some important accounts, so we don't want to delete it entirely.
Thanks!https://gitlab.torproject.org/tpo/core/tor/-/issues/40230If relays have the Exit flag, don't give them the Guard flag2023-04-12T15:23:08ZRoger DingledineIf relays have the Exit flag, don't give them the Guard flagMotivated by this tor-relays@ thread:
https://lists.torproject.org/pipermail/tor-relays/2020-October/019014.html
In short, there's an edge case in our "Bandwidth-weight Case 3a (E scarce)" where exit capacity is scarce but not that scarc...Motivated by this tor-relays@ thread:
https://lists.torproject.org/pipermail/tor-relays/2020-October/019014.html
In short, there's an edge case in our "Bandwidth-weight Case 3a (E scarce)" where exit capacity is scarce but not that scarce, so Wgd ("the weight for choosing a Guard+Exit for the guard position") can become non-zero by a little bit.
What this means in practice is that when we hit that edge case, relays that have both the Guard flag and the Exit flag will be used just a tiny bit as guards by clients. But because of how clients actually use guards (all or nothing, rather than spreading out the load over all the guards), the reality for a relay with a tiny guard weight is that it will accumulate only a handful of clients.
And that situation is extra-scary for those few unlucky clients -- their "guard fingerprint" is a much more distinguishable feature for them because so few other people have it, and also when a guard has one-ish active user, middle relays can know that circuits coming from that guard are likely to be that user.
All in all, it seems much safer to eliminate this situation: dedicate Exits to being exits (or they can be middles too if there's enough exit capacity), and dedicate Guards to being entries (or they can be middles too if there's enough guard capacity).
I hear that @mikeperry wants this feature too, for padding efficiency, because having low-use guards but still needing to pad at them is a suboptimal use of our network bandwidth.
Now, how exactly we should implement this feature remains to be chosen. I think all of the good ways involve doing it at the dir auths (i.e. clients and relays shouldn't have to care how we do it or even *that* we did it). One option (super easy to do) is that if we're giving it the Exit flag, we withhold the Guard flag. Another option (requires a new consensus method, and also a Mike) is that we redo the consensus weighting to handle case 3a ("exit scarce") differently. Are there other approaches that would accomplish the goal?
There are some edge cases to consider here, for example, in a test network that is all Exits, if we therefore never give out the Guard flag, things might get bad. We could handle that either by having this setting be a torrc option that gets overwritten when TestingTorNetwork, or ...maybe Mike's plan of rewriting the linear equations will handle that edge case automatically?https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40348check.torproject.org is down2021-02-19T16:46:25Zcypherpunkscheck.torproject.org is downhttps://check.torproject.org is downhttps://check.torproject.org is downhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40247Remove projects/firefox/mozconfig-android-* files2021-03-05T14:44:54ZboklmRemove projects/firefox/mozconfig-android-* filesI see that we have some `projects/firefox/mozconfig-android-*` files. However, if I think we don't use the firefox project on android anymore, instead we use the geckoview project. So those files are not needed and can be removed.I see that we have some `projects/firefox/mozconfig-android-*` files. However, if I think we don't use the firefox project on android anymore, instead we use the geckoview project. So those files are not needed and can be removed.boklmboklmhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40231Non fatal assertion in relay_addr_learn_from_dirauth when Address is set to a...2021-11-25T19:38:34Zs7rNon fatal assertion in relay_addr_learn_from_dirauth when Address is set to an internal non-public addressTrying to run a bridge with `ORPort 127.0.0.1` and `Address 127.0.0.1` and of course `AssumeReachable 1` and `PublishServerDescriptor 0`. I get this on startup, the Tor process does not die but it doesn't open the ORPort either:
```
Dec...Trying to run a bridge with `ORPort 127.0.0.1` and `Address 127.0.0.1` and of course `AssumeReachable 1` and `PublishServerDescriptor 0`. I get this on startup, the Tor process does not die but it doesn't open the ORPort either:
```
Dec 23 04:34:58.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/relay/relay_find_addr.c:201: relay_addr_learn_from_dirauth: Non-fatal assertion !(!node) failed. (on Tor 0.4.6.0-alpha-dev )
Dec 23 04:34:58.000 [warn] Bug: Tor 0.4.6.0-alpha-dev: Non-fatal assertion !(!node) failed in relay_addr_learn_from_dirauth at ../src/feature/relay/relay_find_addr.c:201. Stack trace: (on Tor 0.4.6.0-alpha-dev )
Dec 23 04:34:58.000 [warn] Bug: tor(log_backtrace_impl+0x56) [0x562cc4940fd6] (on Tor 0.4.6.0-alpha-dev )
Dec 23 04:34:58.000 [warn] Bug: tor(tor_bug_occurred_+0x16c) [0x562cc494c08c] (on Tor 0.4.6.0-alpha-dev )
Dec 23 04:34:58.000 [warn] Bug: tor(relay_addr_learn_from_dirauth+0x1a7) [0x562cc4a6b0c7] (on Tor 0.4.6.0-alpha-dev )
Dec 23 04:34:58.000 [warn] Bug: tor(+0xacceb) [0x562cc48feceb] (on Tor 0.4.6.0-alpha-dev )
Dec 23 04:34:58.000 [warn] Bug: tor(router_build_fresh_descriptor+0x46) [0x562cc48fefe6] (on Tor 0.4.6.0-alpha-dev )
Dec 23 04:34:58.000 [warn] Bug: tor(router_rebuild_descriptor+0x5f) [0x562cc48ff3cf] (on Tor 0.4.6.0-alpha-dev )
Dec 23 04:34:58.000 [warn] Bug: tor(+0x21a823) [0x562cc4a6c823] (on Tor 0.4.6.0-alpha-dev )
Dec 23 04:34:58.000 [warn] Bug: tor(+0x82bd7) [0x562cc48d4bd7] (on Tor 0.4.6.0-alpha-dev )
Dec 23 04:34:58.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x22c05) [0x7f600cb7dc05] (on Tor 0.4.6.0-alpha-dev )
Dec 23 04:34:58.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7f600cb7e537] (on Tor 0.4.6.0-alpha-dev )
Dec 23 04:34:58.000 [warn] Bug: tor(do_main_loop+0xff) [0x562cc48bd27f] (on Tor 0.4.6.0-alpha-dev )
Dec 23 04:34:58.000 [warn] Bug: tor(tor_run_main+0x895) [0x562cc48b7405] (on Tor 0.4.6.0-alpha-dev )
Dec 23 04:34:58.000 [warn] Bug: tor(tor_main+0x3a) [0x562cc48b52ea] (on Tor 0.4.6.0-alpha-dev )
Dec 23 04:34:58.000 [warn] Bug: tor(main+0x19) [0x562cc48b4ea9] (on Tor 0.4.6.0-alpha-dev )
Dec 23 04:34:58.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f600c45f09b] (on Tor 0.4.6.0-alpha-dev )
Dec 23 04:34:58.000 [warn] Bug: tor(_start+0x2a) [0x562cc48b4efa] (on Tor 0.4.6.0-alpha-dev )
```Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40349Using UserCss2021-02-25T18:26:24ZcypherpunksUsing UserCssHi all,
I don't like the way the tor browser looks on GNU/Linux systems. To fix this I can use usercss, but it requires the inclusion of a setting (toolkit.legacyUserProfileCustomizations.stylesheets) I'm worried it might bring negative...Hi all,
I don't like the way the tor browser looks on GNU/Linux systems. To fix this I can use usercss, but it requires the inclusion of a setting (toolkit.legacyUserProfileCustomizations.stylesheets) I'm worried it might bring negative consequences. What do you think about this?https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40248Remove obsolete comment in projects/firefox/build2022-04-01T09:19:58ZboklmRemove obsolete comment in projects/firefox/build`projects/firefox/build` contains this comment:
```
# Android does not support --enable-bundled-fonts option
```
But we no longer use `projects/firefox/build` for Android builds. It seems it was forgotten in e913b103a9bd501503a42c338738e...`projects/firefox/build` contains this comment:
```
# Android does not support --enable-bundled-fonts option
```
But we no longer use `projects/firefox/build` for Android builds. It seems it was forgotten in e913b103a9bd501503a42c338738efa1d1424588.boklmboklmhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40232"Closing no-longer-configured OR listener" does not put brackets around IPv6 ...2021-07-09T17:22:52ZNeel Chauhanneel@neelc.org"Closing no-longer-configured OR listener" does not put brackets around IPv6 addressesWhen I was setting `IPv4Only` on a new Tor relay with broken IPv6, and did `killall -HUP tor`, I got this:
Dec 23 20:08:02.000 [notice] Closing no-longer-configured OR listener on :::143
(I believe) the `:::143` should be `[::]:143`.When I was setting `IPv4Only` on a new Tor relay with broken IPv6, and did `killall -HUP tor`, I got this:
Dec 23 20:08:02.000 [notice] Closing no-longer-configured OR listener on :::143
(I believe) the `:::143` should be `[::]:143`.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40350Unable to start Tor Browser since latest Slackware64 -current update2021-02-21T04:35:16Zbeluga38Unable to start Tor Browser since latest Slackware64 -current updateHello,
Since I have updated one of my systems to the Feb. 18th update of Slackware64 -current the following tab crash occurs on start and on any page. Just opening a tab causes the crash:
![tor-crash](/uploads/89222840be3d1a56630e24afd...Hello,
Since I have updated one of my systems to the Feb. 18th update of Slackware64 -current the following tab crash occurs on start and on any page. Just opening a tab causes the crash:
![tor-crash](/uploads/89222840be3d1a56630e24afd1d45584/tor-crash.png)
I tried starting Tor Browser from the terminal but I don't see any output in the terminal regarding the crash. If anyone can guide me on how to generate a more verbose output it would be appreciated. Or, if anyone may have an idea already about what is causing the issue it's appreciated!
Below is a link to the Slackware changelog:
http://www.slackware.com/changelog/current.php?cpu=x86_64https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40249Update Windows toolchain for Firefox 78.9 (maint-10.0-desktop)2021-03-20T15:02:51ZboklmUpdate Windows toolchain for Firefox 78.9 (maint-10.0-desktop)We will need to update the Windows toolchain to build Firefox 78.9.
MinGW update:
* https://hg.mozilla.org/releases/mozilla-esr78/rev/1b0e1f0d885e
clang update:
* https://hg.mozilla.org/releases/mozilla-esr78/rev/cc840a008393
* https:/...We will need to update the Windows toolchain to build Firefox 78.9.
MinGW update:
* https://hg.mozilla.org/releases/mozilla-esr78/rev/1b0e1f0d885e
clang update:
* https://hg.mozilla.org/releases/mozilla-esr78/rev/cc840a008393
* https://hg.mozilla.org/releases/mozilla-esr78/rev/cf1ff3a632bfboklmboklmhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40233Assertion when starting an IPv4-only bridge on 0.4.5.2-alpha2022-07-07T00:48:32ZNeel Chauhanneel@neelc.orgAssertion when starting an IPv4-only bridge on 0.4.5.2-alphaWhen I set up a bridge on FreeBSD, I got this issue.
Jan 01 21:10:44.000 [notice] Bootstrapped 0% (starting): Starting
Jan 01 21:10:44.000 [notice] Starting with guard context "default"
Jan 01 21:10:44.000 [notice] Registere...When I set up a bridge on FreeBSD, I got this issue.
Jan 01 21:10:44.000 [notice] Bootstrapped 0% (starting): Starting
Jan 01 21:10:44.000 [notice] Starting with guard context "default"
Jan 01 21:10:44.000 [notice] Registered server transport 'obfs4' at '[::]:80'
Jan 01 21:10:45.000 [warn] tor_bug_occurred_: Bug: src/feature/relay/relay_find_addr.c:201: relay_addr_learn_from_dirauth: Non-fatal assertion !(!node) failed. (on Tor 0.4.5.2-alpha )
Jan 01 21:10:
Jan 01 21:10:45.000 [warn] Bug: 0x11a2ad2 <router_build_fresh_descriptor+0x2a2> at /usr/local/bin/tor (on Tor 0.4.5.2-alpha )
Jan 01 21:10:45.000 [warn] Bug: 0x11a1f3f <router_rebuild_descriptor+0x6f> at /usr/local/bin/tor (on Tor 0.4.5.2-alpha )
Jan 01 21:10:45.000 [warn] Bug: 0x11a1d49 <consider_publishable_server+0x39> at /usr/local/bin/tor (on Tor 0.4.5.2-alpha )
Jan 01 21:10:45.000 [warn] Bug: 0x1225714 <reschedule_descriptor_update_check+0x274> at /usr/local/bin/tor (on Tor 0.4.5.2-alpha )
Jan 01 21:10:45.000 [warn] Bug: 0x122a77a <periodic_event_connect+0x10a> at /usr/local/bin/tor (on Tor 0.4.5.2-alpha )
Jan 01 21:10:45.000 [warn] Bug: 0x8013fe0ed <event_base_assert_ok_nolock_+0xa5d> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.5.2-alpha )
Jan 01 21:10:45.000 [warn] Bug: 0x8013fa09c <event_base_loop+0x53c> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.5.2-alpha )
Jan 01 21:10:45.000 [warn] Bug: 0x116c861 <do_main_loop+0xf1> at /usr/local/bin/tor (on Tor 0.4.5.2-alpha )
Jan 01 21:10:45.000 [warn] Bug: 0x1155cbc <tor_run_main+0x12c> at /usr/local/bin/tor (on Tor 0.4.5.2-alpha )
Jan 01 21:10:45.000 [warn] Bug: 0x1154651 <tor_main+0x61> at /usr/local/bin/tor (on Tor 0.4.5.2-alpha )
Jan 01 21:10:45.000 [warn] Bug: 0x1154309 <main+0x19> at /usr/local/bin/tor (on Tor 0.4.5.2-alpha )
This happened on FreeBSD 12.2 on a bridge on Microsoft Azure. Tor was installed via `pkg` and I do not have a local-link IPv6 address.Tor: 0.4.5.x-post-stablehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40351Using Cloudflare Onion Service in Tor Browser2021-12-13T19:03:35Zkms2db0f6fUsing Cloudflare Onion Service in Tor BrowserCloudflare has [Onion Services available](https://blog.cloudflare.com/cloudflare-onion-service/), and is announced via `alt-svc`, but it seems that there is no way to configure Tor Browser to connect to Cloudflare's `.onion` addresses.
...Cloudflare has [Onion Services available](https://blog.cloudflare.com/cloudflare-onion-service/), and is announced via `alt-svc`, but it seems that there is no way to configure Tor Browser to connect to Cloudflare's `.onion` addresses.
For example, when you go to `cloudflare.com`, browser console will show lines like:
`Alternate Service Mapping found: https://www.cloudflare.com:-1 to https://cflareki4v3lh674hq55k3n7xd4ibkwx3pnw67rr3gkpsonjmxbktxyd.onion:443`
Even though I have "Prioritize .onion sites when known" enabled in Tor Browser, Tor Browser will still connect to `www.cloudflare.com` for webpage resources instead of `cflareki4v3lh674hq55k3n7xd4ibkwx3pnw67rr3gkpsonjmxbktxyd.onion`.
Cloudflare recommended Tor Browser 8.0 in their post (which was written a long time ago), but I am using Tor Browser 10.5a8.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40250Set MOZILLA_OFFICIAL on Android2021-03-15T18:00:55ZMatthew FinkelSet MOZILLA_OFFICIAL on AndroidAdded in fenix@81e08b2e7ff90774442342891dbbb59c4e2b8852, adding `-Pofficial` on the gradle command should do it.Added in fenix@81e08b2e7ff90774442342891dbbb59c4e2b8852, adding `-Pofficial` on the gradle command should do it.Tor Browser: 10.0https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40352Bundle an add-on like Privacy Redirect2021-03-19T13:30:43ZcypherpunksBundle an add-on like Privacy RedirectIn response to #40300 and tpo/community/support#40013, a browser add-on such as [Privacy Redirect](https://github.com/SimonBrazell/privacy-redirect) that allows the user to configure automatic rewrites of URL hosts could reduce complaint...In response to #40300 and tpo/community/support#40013, a browser add-on such as [Privacy Redirect](https://github.com/SimonBrazell/privacy-redirect) that allows the user to configure automatic rewrites of URL hosts could reduce complaints from users to read, at least, popular websites that are blocking/censoring itself to Tor users.
From another front, we could educate those website admins about Tor and the filtering alternatives to totally blocking readership. Facebook and others run onion services, so there are many examples. Until the popular sites allow readers directly, their blocks will drive readers to go to other sites anyway, regardless of add-ons.