The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-03-13T09:57:24Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19162Make it even harder to become HSDir2023-03-13T09:57:24ZGeorge KadianakisMake it even harder to become HSDirIn legacy/trac#8243 we started requiring `Stable` flag for becoming HSDirs, but this is still not hard enough for motivated adversaries. Hence we need to make it even harder for a relay to become HSDir, so that only relays that have been...In legacy/trac#8243 we started requiring `Stable` flag for becoming HSDirs, but this is still not hard enough for motivated adversaries. Hence we need to make it even harder for a relay to become HSDir, so that only relays that have been around for long get the flag. After prop224 gets deployed, there will be less incentive for adversaries to become HSDirs since they won't be able to harvest onion addresses.
Until then, our current plan is to increase the bandwidth and uptime required to become an HSDir to something almost unreasonable. For example requiring an uptime of over 6 months, or maybe requiring that the relay is in the top 1/4th of uptimes on the network.Tor: unspecifiedRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41237Separate VPN Classes into their own module2022-11-30T14:52:44ZShane IsbellSeparate VPN Classes into their own moduleThe VPN and TorService code isn't correctly layered. It has some interdependence.
By breaking out the code, it should be easier to maintain. Its also easier to strip out the VPN for Tor Browser, while maintaining it for Orbot.The VPN and TorService code isn't correctly layered. It has some interdependence.
By breaking out the code, it should be easier to maintain. Its also easier to strip out the VPN for Tor Browser, while maintaining it for Orbot.https://gitlab.torproject.org/tpo/network-health/metrics/collector/-/issues/40007onionperf: No longer need to download tpf files2022-09-28T07:02:04Zirlonionperf: No longer need to download tpf filesThe OnionPerf module still has residual code related to the download of *.tpf files, which are no longer produced by modern OnionPerf. This code could be removed, and in the process might make the JSON downloading code that remains more ...The OnionPerf module still has residual code related to the download of *.tpf files, which are no longer produced by modern OnionPerf. This code could be removed, and in the process might make the JSON downloading code that remains more robust.
Relevant code: https://gitlab.torproject.org/tpo/metrics/collector/-/blob/master/src/main/java/org/torproject/metrics/collector/onionperf/OnionPerfDownloader.javaHiroHirohttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/28102Make sure we pick the exact same compile environment for Tor Browser builds2023-01-05T13:55:23ZGeorg KoppenMake sure we pick the exact same compile environment for Tor Browser buildsWhen creating a container image at time t and creating a container image at time t1 it is not guaranteed that we include the same compiler versions etc.
This has led to `mar` executables being different, for instance (see: comment:52:ti...When creating a container image at time t and creating a container image at time t1 it is not guaranteed that we include the same compiler versions etc.
This has led to `mar` executables being different, for instance (see: comment:52:ticket:26475): GCC version was in both cases 4.9.2 but in one of them contained an updated resulting in `GCC: (Debian 4.9.2-10+deb8u1) 4.9.2` as a version string instead of `GCC: (Debian 4.9.2-10) 4.9.2`.
We could fix that by making sure we compile our own GCC for this case but there might be other packages lurking with the same trouble potential. We should make sure instead that everyone creating *and* using a container image is getting/having the same available.boklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/12968Specify HEASLR (High Entropy Address Space Layout Randomization) in MinGW-w642023-01-05T12:45:28ZMike PerrySpecify HEASLR (High Entropy Address Space Layout Randomization) in MinGW-w64Mozilla patched mingw-w64 to allow the specification of "high-entropy" ASLR, which is an extra hardened ASLR option on Windows. Not sure if this flag only applies to 64bit builds. I think it might.
Here's their ticket:
https://github.co...Mozilla patched mingw-w64 to allow the specification of "high-entropy" ASLR, which is an extra hardened ASLR option on Windows. Not sure if this flag only applies to 64bit builds. I think it might.
Here's their ticket:
https://github.com/rust-lang/rust/issues/16593
and the patch:
https://sourceware.org/ml/binutils/2014-08/msg00167.html
and it's approval by the Binutils team:
https://sourceware.org/ml/binutils/2014-08/msg00177.htmlhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/12631Tor Browser for ARM architecture2024-03-28T13:16:10ZMatt PaganTor Browser for ARM architectureThe Tor Project should provide a Tor Browser compatible with the ARMv7 processor. This would provide a safe way of using Tor for users of the Samsung ARM Chromebook, the Samsung Chromebook 2, the Raspberry Pi, the Novena Open Laptop, and...The Tor Project should provide a Tor Browser compatible with the ARMv7 processor. This would provide a safe way of using Tor for users of the Samsung ARM Chromebook, the Samsung Chromebook 2, the Raspberry Pi, the Novena Open Laptop, and probably other platforms too.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/26858TBA: Investigating patching AccountManager2022-07-20T17:28:37ZMatthew FinkelTBA: Investigating patching AccountManagerOrfox previously patched some of the AccountManager and Sync code. Are these still needed?
https://github.com/guardianproject/tor-browser/commit/45ba8e208975daebda7520ea0f111f475adba967
https://github.com/guardianproject/tor-browser/com...Orfox previously patched some of the AccountManager and Sync code. Are these still needed?
https://github.com/guardianproject/tor-browser/commit/45ba8e208975daebda7520ea0f111f475adba967
https://github.com/guardianproject/tor-browser/commit/b044089a93bd36ddb454ac11eecc72a2c295229c
https://github.com/guardianproject/tor-browser/commit/842618571bbe865657836447cbd50fffc027b582
From https://bugzilla.mozilla.org/show_bug.cgi?id=1314778https://gitlab.torproject.org/tpo/core/torsocks/-/issues/3711Application support for optimistic data: Torsocks2021-11-15T16:42:22ZNick MathewsonApplication support for optimistic data: TorsocksNow that Tor (as of 0.2.3.x) supports optimistic data, we should try to get torsocks to support it.
This won't be totally trivial, since we'll need to tell the application "yes, it connected" early, and then give an error if the connect...Now that Tor (as of 0.2.3.x) supports optimistic data, we should try to get torsocks to support it.
This won't be totally trivial, since we'll need to tell the application "yes, it connected" early, and then give an error if the connection actually happens. (Perhaps we can get away with doing an early shutdown() on the connection so that reads and writes fail, but the fd lingers. If not, we'll have to intercept read, write, pread, pwrite, writev, select, etc, so that we can give an error if needed.)
There was some discussion of this in the comments of legacy/trac#1849.https://gitlab.torproject.org/tpo/core/tor/-/issues/33072When under load, give 503 aggressively for dirport requests without compression2022-03-21T19:36:49ZNick MathewsonWhen under load, give 503 aggressively for dirport requests without compressionPreliminary analysis of the parent ticket suggests that most of the problematic requests are coming from an aggressively non-tor sources. One reasonable thing we could do to disfavor them is to give a 503 to directory requests that don'...Preliminary analysis of the parent ticket suggests that most of the problematic requests are coming from an aggressively non-tor sources. One reasonable thing we could do to disfavor them is to give a 503 to directory requests that don't request compression, either with a ".z" suffix or an Accept-Encoding list.https://gitlab.torproject.org/tpo/core/tor/-/issues/32165On first boot, Tor mistakenly tells me "The current consensus has no exit nodes"2021-02-17T09:23:04ZRoger DingledineOn first boot, Tor mistakenly tells me "The current consensus has no exit nodes"Starting up 0.4.3.0-alpha-dev (git-71daad1692bc3f24) without any cached-* files in my DataDirectory, I get:
```
Oct 20 04:44:56.026 [notice] Bootstrapped 30% (loading_status): Loading networkstatus consensus
Oct 20 04:44:56.636 [notice] ...Starting up 0.4.3.0-alpha-dev (git-71daad1692bc3f24) without any cached-* files in my DataDirectory, I get:
```
Oct 20 04:44:56.026 [notice] Bootstrapped 30% (loading_status): Loading networkstatus consensus
Oct 20 04:44:56.636 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
Oct 20 04:44:56.758 [notice] Bootstrapped 40% (loading_keys): Loading authority key certs
Oct 20 04:44:56.936 [notice] The current consensus has no exit nodes. Tor can only build internal paths, such as paths to onion services.
Oct 20 04:44:56.936 [notice] Bootstrapped 45% (requesting_descriptors): Asking for relay descriptors
Oct 20 04:44:56.936 [notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 0/5841, and can only build 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, and 0% of end bw (no exits in consensus, using mid) = 0% of path bw.)
Oct 20 04:44:57.337 [notice] Bootstrapped 50% (loading_descriptors): Loading relay descriptors
Oct 20 04:44:57.592 [notice] The current consensus contains exit nodes. Tor can build exit and internal paths.
Oct 20 04:44:58.178 [notice] Bootstrapped 58% (loading_descriptors): Loading relay descriptors
```
It's that "The current consensus has no exit nodes." line that is out of place.https://gitlab.torproject.org/tpo/core/tor/-/issues/31632hs-v3: Service doesn't re-upload descriptor on circuit failure2021-06-23T17:19:23ZDavid Gouletdgoulet@torproject.orghs-v3: Service doesn't re-upload descriptor on circuit failureI'm observing, quite often actually, a service posting its descriptor to an HSDir but the circuit collapses due to remote reason `CHANNEL_CLOSED`.
This is possible for many reasons where a link between two relays failed/disconnected/clo...I'm observing, quite often actually, a service posting its descriptor to an HSDir but the circuit collapses due to remote reason `CHANNEL_CLOSED`.
This is possible for many reasons where a link between two relays failed/disconnected/closed/...
However, we do not retry the upload after that which means that we can end up with HSDir(s) without our descriptor even though we think they are there.
Solution is unclear but it appears that we probably want to hook this case into `hs_circ_cleanup()` which is called from the mark for close function.https://gitlab.torproject.org/tpo/core/tor/-/issues/27241Extract information from more kinds of wedged directory connections.2021-11-06T13:26:13ZNick MathewsonExtract information from more kinds of wedged directory connections.In main.c, we do:
```
/* This check is temporary; it's to let us know whether we should consider
* parsing partial serverdesc responses. */
if (conn->purpose == DIR_PURPOSE_FETCH_SERVERDESC &&
connection_get_inbuf_le...In main.c, we do:
```
/* This check is temporary; it's to let us know whether we should consider
* parsing partial serverdesc responses. */
if (conn->purpose == DIR_PURPOSE_FETCH_SERVERDESC &&
connection_get_inbuf_len(conn) >= 1024) {
log_info(LD_DIR,"Trying to extract information from wedged server desc "
"download.");
connection_dir_reached_eof(TO_DIR_CONN(conn));
```
We should also, at a minimum, do this for microdesc downloads.https://gitlab.torproject.org/tpo/core/tor/-/issues/27049"No circuits are opened" messages with onion services2022-10-17T10:12:18ZMike Perry"No circuits are opened" messages with onion servicesIf a Tor instance is only doing onion service activity, and circuits time out, then the Tor client thinks that circuits aren't opened and gives them a full minute to complete. It also complains about this in the logs at notice level, lik...If a Tor instance is only doing onion service activity, and circuits time out, then the Tor client thinks that circuits aren't opened and gives them a full minute to complete. It also complains about this in the logs at notice level, like this:
```
Aug 06 02:55:30.000 [notice] No circuits are opened. Relaxed timeout for circuit 21570 (a Hidden service: Pre-built vanguard circuit 4-hop circuit in state doing handshakes with channel state open) to 60000ms. However, it appears the circuit has timed out anyway.
```
The fix is simple. circuit_any_opened_circuits() in circuitlist.c is only counting circuits as opened if they use the DEFAULT_ROUTE_LEN. We just need to count >= DEFAULT_ROUTE_LEN to count them.Mike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16255Guardfraction on dirauths screws up bandwidth weights2022-02-28T19:41:25ZGeorge KadianakisGuardfraction on dirauths screws up bandwidth weightsIt seems that dirauths stopped including bandwidth weights on the consensus after Guardfraction got enabled:
https://lists.torproject.org/pipermail/tor-dev/2015-June/008908.html
Looking at weasel's dirauth we get plenty of related error...It seems that dirauths stopped including bandwidth weights on the consensus after Guardfraction got enabled:
https://lists.torproject.org/pipermail/tor-dev/2015-June/008908.html
Looking at weasel's dirauth we get plenty of related error messages:
```
[warn] Bw Weights error 1 for Case 3be (E scarce, Wee=1, Wmd == Wgd) v10. G=14793673 M=8310679 E=3428814 D=7040272 T=26698303 Wmd=-512 Wme=0 Wmg=2192 Wed=11025 Wee=10000 Wgd=-512 Wgg=7808 Wme=0 Wmg=2192 weight_scale=10000
```
That is, it seems like the bandwidth calculation of the dirauths got screwed a bit. This might be the result of using the guardfraction data during bandwidth calculation in `compute_weighted_bandwidths()` that might combine badly with legacy/trac#13297.
The negative Wmd/Wgd values seem weird here as well.
Let's disable the GuardFraction feature for now, till we figure out this issue.https://gitlab.torproject.org/tpo/core/tor/-/issues/12389Should we warn when exit nodes are using opendns or google dns?2022-10-24T20:49:32ZNick MathewsonShould we warn when exit nodes are using opendns or google dns?Somewhat related to discussion on legacy/trac#8093 -- people are still setting up exit nodes to use OpenDNS or Google DNS. Is that really a safe idea? That makes it distressingly easy for these DNS services (or anybody watching them) t...Somewhat related to discussion on legacy/trac#8093 -- people are still setting up exit nodes to use OpenDNS or Google DNS. Is that really a safe idea? That makes it distressingly easy for these DNS services (or anybody watching them) to get timing information on user DNS requests.
Furthermore, the default OpenDNS configuration blocks some stuff. If we don't warn about OpenDNS in general, maybe we should warn when configuring an OpenDNS server in a way that hasn't disabled blocking.https://gitlab.torproject.org/tpo/core/chutney/-/issues/33825Make Environ handle "in" and "get()" like a dict2022-02-07T19:31:36ZteorMake Environ handle "in" and "get()" like a dictSome standard Python dict code doesn't work on chutney's Environ class:
```
is_in_env = 'foo' in self._env
value_or_none = self._env.get('foo')
```
"in" should return a boolean, and "get()" should return the value (or None).
But instea...Some standard Python dict code doesn't work on chutney's Environ class:
```
is_in_env = 'foo' in self._env
value_or_none = self._env.get('foo')
```
"in" should return a boolean, and "get()" should return the value (or None).
But instead, when the key is missing, sometimes they throw a KeyError. (It seems to happen in certain contexts, but not others.)
We should work out if Environ is missing some of the required dict implementation functions. Or if there is some issue with Environ's lookup code.
Then we should implement unit tests, to make sure we don't break Environ in future.