Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:19:11Zhttps://gitlab.torproject.org/legacy/trac/-/issues/2878Don't bootstrap from an old consensus if we're about to replace it2020-06-13T15:19:11ZSebastian HahnDon't bootstrap from an old consensus if we're about to replace itStarting up maint-0.2.2 with an old data dir, I got this:
```
[notice] We now have enough directory information to build circuits.
[notice] Bootstrapped 80%: Connecting to the Tor network.
[notice] Bootstrapped 85%: Finishing handshake ...Starting up maint-0.2.2 with an old data dir, I got this:
```
[notice] We now have enough directory information to build circuits.
[notice] Bootstrapped 80%: Connecting to the Tor network.
[notice] Bootstrapped 85%: Finishing handshake with first hop.
[notice] Bootstrapped 90%: Establishing a Tor circuit.
[notice] Tor has successfully opened a circuit. Looks like client functionality is working.
[notice] Bootstrapped 100%: Done.
[warn] Please upgrade! This version of Tor (0.2.2.19-alpha) is not recommended, according to the directory authorities. Recommended versions are: 0.2.1.29,0.2.1.30,0.2.2.21-alpha,0.2.2.22-alpha,0.2.2.23-alpha
[notice] Our directory information is no longer up-to-date enough to build circuits: We have only 0/2268 usable descriptors.
[notice] I learned some more directory information, but not enough to build a circuit: We have only 0/2268 usable descriptors.
[notice] Tor has successfully opened a circuit. Looks like client functionality is working.
[notice] I learned some more directory information, but not enough to build a circuit: We have only 96/2268 usable descriptors.
[notice] I learned some more directory information, but not enough to build a circuit: We have only 192/2268 usable descriptors.
[notice] I learned some more directory information, but not enough to build a circuit: We have only 288/2268 usable descriptors.
[notice] I learned some more directory information, but not enough to build a circuit: We have only 384/2268 usable descriptors.
[notice] I learned some more directory information, but not enough to build a circuit: We have only 480/2268 usable descriptors.
[notice] We now have enough directory information to build circuits.
```
First we make a circuit, then immediately we are say we don't have enough data to make a circuit and get a little spammy about that, too. Maybe there's an easy fix, if not we should postpone this for 0.2.3.xTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/7349Obfsbridges should be able to "disable" their ORPort2021-07-29T15:06:00ZGeorge KadianakisObfsbridges should be able to "disable" their ORPortIn the future, we will want obfsbridges to only expose their obfsports and not their ORPort, otherwise an adversary can launch an active-scanning attack against the ORPort.
We should spec and implement a torrc option that hides the ORPo...In the future, we will want obfsbridges to only expose their obfsports and not their ORPort, otherwise an adversary can launch an active-scanning attack against the ORPort.
We should spec and implement a torrc option that hides the ORPort of obfsbridges.
Maybe it should make the ORPort bind on localhost. But what happens if the transport proxy is not on the same host as the ORPort?Tor: 0.4.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/14209Implement SOCKSPort windows:path for named pipes2020-06-13T16:09:26ZTracImplement SOCKSPort windows:path for named pipesThis is identical to #12585 SocksSocket except for Windows users wishing to use Named Pipes in this same manner.
Firefox changes to use this (instead of SocksPort) unknown. See https://bugzilla.mozilla.org/show_bug.cgi?id=892114
**Trac...This is identical to #12585 SocksSocket except for Windows users wishing to use Named Pipes in this same manner.
Firefox changes to use this (instead of SocksPort) unknown. See https://bugzilla.mozilla.org/show_bug.cgi?id=892114
**Trac**:
**Username**: anonTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/21377DirAuths should expose bwauth bandwidth files2022-02-16T21:12:43ZTom Rittertom@ritter.vgDirAuths should expose bwauth bandwidth filesCurrently, DirAuths that vote on bwauth files do not expose the raw voting file they used. This data would be good to archive for debugging and transparency purposes.Currently, DirAuths that vote on bwauth files do not expose the raw voting file they used. This data would be good to archive for debugging and transparency purposes.Tor: 0.4.0.x-finaljugajugahttps://gitlab.torproject.org/legacy/trac/-/issues/24857Tor uses 100% CPU when accessing the cache directory on Windows2020-06-13T15:51:45ZTracTor uses 100% CPU when accessing the cache directory on WindowsHi,
I have tor 0.3.1.9 running as non-exit relay.
From time to time it starts consuming 100% of CPU. Even though network traffic is minimal.
Is it normal? If not, how can I help you to investigate it?
My system is Win 7 x64 SP1, cpu i...Hi,
I have tor 0.3.1.9 running as non-exit relay.
From time to time it starts consuming 100% of CPU. Even though network traffic is minimal.
Is it normal? If not, how can I help you to investigate it?
My system is Win 7 x64 SP1, cpu is Core i5-3570.
**Trac**:
**Username**: Eugene646Tor: 0.4.4.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/25347Tor keeps on trying the same overloaded guard over and over2020-06-13T15:24:07ZteorTor keeps on trying the same overloaded guard over and overWhen Tor can't download microdescriptors (#21969), maybe it should try authorities or fallbacks (#23863), before it runs out of microdesc retries (#24113).
But even after Tor has the microdescs it needs, it sometimes doesn't start build...When Tor can't download microdescriptors (#21969), maybe it should try authorities or fallbacks (#23863), before it runs out of microdesc retries (#24113).
But even after Tor has the microdescs it needs, it sometimes doesn't start building circuits again. Instead, it is in state "waiting for circuit".
For the log messages, see:
https://trac.torproject.org/projects/tor/ticket/21969#comment:82Tor: unspecifiedGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/25987Allow controller to receive log messages from outside main thread2020-06-13T15:25:14ZNick MathewsonAllow controller to receive log messages from outside main threadOur existing callback system doesn't allow this, but actually it would be pretty easy to take care of.
The trick here would be:
1) to make it so that the flush_queued_events_event uses the alert_sockets_create() mechanism, so it can b...Our existing callback system doesn't allow this, but actually it would be pretty easy to take care of.
The trick here would be:
1) to make it so that the flush_queued_events_event uses the alert_sockets_create() mechanism, so it can be turned on from another thread.
2) To remove the check for whether we're in the main thread from control_event_logmsg().
I think this would be pretty simple -- maybe a couple hours of work -- but we should consider it only for 0.3.5, since it has potential to be very destabilizing if we mess it up.
Found while working on #25951Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26168Rename HSDir consensus flag to OnionDir2020-06-13T15:25:54ZRoger DingledineRename HSDir consensus flag to OnionDirOver time, nobody is going to know what an HSDir is. Eventually we will want to use a more understandable name. I propose OnionDir.
Step 1: Make clients able to parse the OnionDir flag, and they just treat it as a synonym for HSDir.
St...Over time, nobody is going to know what an HSDir is. Eventually we will want to use a more understandable name. I propose OnionDir.
Step 1: Make clients able to parse the OnionDir flag, and they just treat it as a synonym for HSDir.
Step 2: Wait a long time until all clients from before step 1 are gone.
Step 3: Have dir auths start saying OnionDir instead of HSDir.
(In the above plan, step 2 could take years. But I think it's still the simplest plan. The only real risk is if we somehow screw up with step 1, and don't notice the screw-up until we try step 3.)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26295Fix problems with the Windows event loop2020-06-13T15:26:22ZAlexander Færøyahf@torproject.orgFix problems with the Windows event loopWe currently have a number of problems that is due to different issues around the Windows event loop:
- We do not have bi-directional communication with sub-processes, which limits what we can do with PT's and the upcoming Onion Naming ...We currently have a number of problems that is due to different issues around the Windows event loop:
- We do not have bi-directional communication with sub-processes, which limits what we can do with PT's and the upcoming Onion Naming Service sub-process.
- We should look into whether we dynamically can check if the Windows version that Tor is running on supports UNIX domain sockets such that Tor Browser can do its "network-less sandbox"-feature where it connects to Tor via the UNIX domain sockets. See: https://blogs.msdn.microsoft.com/commandline/2017/12/19/af_unix-comes-to-windows/Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26369Re-fetch onion service descriptor for isolated request2020-06-13T15:26:39ZMatthew FinkelRe-fetch onion service descriptor for isolated requestWhen tor receives a new request for connecting to an onion service and this request has different isolation flags/parameters than a previous (recent) request, then tor should re-fetch the service descriptor (if we already have it). Curre...When tor receives a new request for connecting to an onion service and this request has different isolation flags/parameters than a previous (recent) request, then tor should re-fetch the service descriptor (if we already have it). Currently, tor notices it already has the descriptor in its cache and it doesn't refetch. This is a nice performance optimization, but if a client is requesting an isolated circuit for an onion service, then we shouldn't leak that we already have the descriptor in our cache.
Instead of only using the onion service name as the map-key, we can add a unique value of the circuit isolation information (hash?).Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26478Unify bandwidth related terms in dir-spec and Tor code.2020-06-13T15:27:04ZjugaUnify bandwidth related terms in dir-spec and Tor code.Unifying these terms would make following what these bandwidth do in the code and the spec less confusing.
For instance:
- what is called `bandwidthrate` [0] in the code when building the descriptor, it is called `bandwidth-avg` in `dir-...Unifying these terms would make following what these bandwidth do in the code and the spec less confusing.
For instance:
- what is called `bandwidthrate` [0] in the code when building the descriptor, it is called `bandwidth-avg` in `dir-spec.txt` [1].
- what is called `bandwidthcapacity` [2] in the code, it is called `bandwidth-observed` in `dir-spec.txt`[1]
I don't know if it is prefered to modify terms in the spec or in the code.
It'd be also helpful to add formulae or more detailed descriptions on how the different bandwidth terms are generated in dir-spec.txt
[0] https://gitweb.torproject.org/tor.git/tree/src/or/router.c#n2370
[1] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n427
[2] https://gitweb.torproject.org/tor.git/tree/src/or/router.c#n2376Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26737File-level documentation for src/core/*/*.[ch]2020-06-13T15:27:49ZNick MathewsonFile-level documentation for src/core/*/*.[ch]Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26738File-level documentation for src/feature/*/*.[ch]2020-06-13T15:27:49ZNick MathewsonFile-level documentation for src/feature/*/*.[ch]Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26743Further refactoring follow-on tasks: split files that don't fit well within t...2020-06-13T15:27:50ZNick MathewsonFurther refactoring follow-on tasks: split files that don't fit well within their directoryTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26770Implement proposal 293: "Other ways for relays to know when to publish"2020-06-13T15:27:56ZNick MathewsonImplement proposal 293: "Other ways for relays to know when to publish"Tor: 0.4.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/26886prop295: revise proposal and determine feasability2020-06-13T15:32:14Zteorprop295: revise proposal and determine feasabilityProposal 295 is:
> Filename: 295-relay-crypto-with-atl.txt
> Title: Using ADL-GCM for relay cryptography (solving the crypto-tagging attack)
> Author: Tomer Ashur
At:
https://github.com/torproject/torspec/blob/master/proposals/295-relay...Proposal 295 is:
> Filename: 295-relay-crypto-with-atl.txt
> Title: Using ADL-GCM for relay cryptography (solving the crypto-tagging attack)
> Author: Tomer Ashur
At:
https://github.com/torproject/torspec/blob/master/proposals/295-relay-crypto-with-atl.txtTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26910Could tor drop privileges even earlier? (before trying to access anything on ...2020-06-13T15:28:34ZnusenuCould tor drop privileges even earlier? (before trying to access anything on the filesystem beyond its torrc files)Fedora/CentOS starts the tor service as root and drops
privileges to user 'toranon' due to the torrc 'User' parameter by default.
Also by default the tor service runs in a SELinux confined domain (tor_t). That means
root in that domain...Fedora/CentOS starts the tor service as root and drops
privileges to user 'toranon' due to the torrc 'User' parameter by default.
Also by default the tor service runs in a SELinux confined domain (tor_t). That means
root in that domain can NOT access just any files regardless
of DAC filesystem permissions (DAC_OVERRIDE is not granted by default).
Which results in the situation that during startup (before privileges
are dropped and user is switched to 'toranon') tor can not access
the hiddenservicedir without allowing DAC_OVERRIDE or changing filesystem permissions,
but it could if at that point privileges were already switched to the user specified in the torrc file.
From my point of view the nicest solution would be if tor drops
privileges before it accesses anything on the filesystem -
which would solve above problem. Would that introduce other problems?
Is there a specific reason why tor drops privileges later?
(this is about running tor and tor in --verify-config mode)
context:
https://bugzilla.redhat.com/show_bug.cgi?id=1602171
(I consider this problem solved via the workaround but
I'm still interested in the above question)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27921apparent DOS / impairment-of-service against FallbackDirs using DIR requests,...2020-06-13T15:32:23Zstarlightapparent DOS / impairment-of-service against FallbackDirs using DIR requests, please evaluate for possible mitigationEarly this year I noticed excessive DIR requests against my relay and also in the Relay Search usage graphs of other fallback directory nodes. Wrote an iptables rule and put an end to it.
The attacker enhanced their botware to request ...Early this year I noticed excessive DIR requests against my relay and also in the Relay Search usage graphs of other fallback directory nodes. Wrote an iptables rule and put an end to it.
The attacker enhanced their botware to request via OR port and the problem is back. In the previous 24-hour stats window DIR requests increased output load on the relay by 17%. In the current cycle the increase is 12%.
Opening this ticket to put the problem on the radar. When time permits (never enough time, I know) and/or the attack escalates please investigate an enhancement to DOS mitigation to address this issue.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28036Launch tests inside a single dirauth instance2020-06-13T15:32:51ZteorLaunch tests inside a single dirauth instanceTo test #27146, we need to be able to run dirvote_act() at a set time inside a launched dirauth instance.To test #27146, we need to be able to run dirvote_act() at a set time inside a launched dirauth instance.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28223Unparseable microdescriptor on public relay2020-06-13T15:33:25ZteorUnparseable microdescriptor on public relayA relay operator reported this error:
```
Get this at my exit relay since yesterday:
# head /tmp/warn.log
Oct 23 23:30:17.000 [notice] Tor 0.3.5.3-alpha opening new log file.
Oct 23 23:30:33.000 [warn] parse error: internal NUL characte...A relay operator reported this error:
```
Get this at my exit relay since yesterday:
# head /tmp/warn.log
Oct 23 23:30:17.000 [notice] Tor 0.3.5.3-alpha opening new log file.
Oct 23 23:30:33.000 [warn] parse error: internal NUL character.
Oct 23 23:30:33.000 [warn] Unparseable microdescriptor
Oct 23 23:30:33.000 [warn] parse error: internal NUL character.
Oct 23 23:30:33.000 [warn] Unparseable microdescriptor
even with log level "debug" there seems to be no more information.
Anything I should worry about?
```
https://lists.torproject.org/pipermail/tor-relays/2018-October/date.htmlTor: 0.4.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/28309Log the rust version when printing other library versions2020-06-13T15:33:43ZteorLog the rust version when printing other library versionstor --library-versions prints the versions of Tor's library dependencies.
Would it be useful for it to print the rust version as well?
Or the versions of our rust library dependencies?
Tor also prints the OS version and library version...tor --library-versions prints the versions of Tor's library dependencies.
Would it be useful for it to print the rust version as well?
Or the versions of our rust library dependencies?
Tor also prints the OS version and library versions when it starts up. We could add the rust version and significant rust library versions to that log message.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28344Should we log \r\n on Windows?2020-06-13T15:33:50ZteorShould we log \r\n on Windows?Tor's logging code terminates strings with \n.
When I run tor.exe via the command prompt on Windows, I don't see any of the log output, because there's no \r at the end of the line.
Should we make tor log \r\n on Windows?Tor's logging code terminates strings with \n.
When I run tor.exe via the command prompt on Windows, I don't see any of the log output, because there's no \r at the end of the line.
Should we make tor log \r\n on Windows?Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28356DataDirectoryGroupReadable and CacheDirectoryGroupReadable conflicts forcing ...2020-06-13T15:33:52ZTracDataDirectoryGroupReadable and CacheDirectoryGroupReadable conflicts forcing sandboxed Tor to crash== Problem 1
By default `DataDirectory` and `CacheDirectory` is the same. On Debian it is `/var/lib/tor`. If you set `DataDirectoryGroupReadable 1` in `torrc` (and forget about `CacheDirectoryGroupReadable`) and then restart Tor, you ex...== Problem 1
By default `DataDirectory` and `CacheDirectory` is the same. On Debian it is `/var/lib/tor`. If you set `DataDirectoryGroupReadable 1` in `torrc` (and forget about `CacheDirectoryGroupReadable`) and then restart Tor, you expect granting permissions to this directory. However, Tor will not do that, but change `drwx--S---` permission to `drwx------` for this directory (which is itself not logical---removing permissions instead of granting them). Tor will also issue a warning:
```
[warn] Fixing permissions on directory /var/lib/tor
```
Later this warning will be repeated at each startup of Tor. I think that this warning should be improved, e.g.:
```
[warn or err] DataDirectoryGroupReadable and CacheDirectoryGroupReadable links to the same directory. You have to set both of them to 1 of both of them to 0.
```
Maybe you have another suggestion (e.g., if any of these options is 1, another is 1 too). `man torrc` doesn't tell anything about this conflict. It should be addressed in man page too.
== Problem 2
The situation is worse when your `torrc` has `Sandbox` enabled:
```
DataDirectoryGroupReadable 1
CacheDirectoryGroupReadable 1
Sandbox 1
```
In this case Tor successfully starts, but if you issue `SIGNAL RELOAD` command (e.g., using `tor-prompt`), Tor immediately crashes with the log:
```
============================================================ T= XXXXXXXXXX
(Sandbox) Caught a bad syscall attempt (syscall chmod)
/usr/bin/tor(+0x1a4d66)[0x556326474d66]
/lib/x86_64-linux-gnu/libc.so.6(chmod+0x7)[0x7f63c91b4807]
/lib/x86_64-linux-gnu/libc.so.6(chmod+0x7)[0x7f63c91b4807]
/usr/bin/tor(+0xfafed)[0x5563263cafed]
/usr/bin/tor(set_options+0x2ed)[0x5563263d42dd]
/usr/bin/tor(options_init_from_string+0x4c7)[0x5563263d6d97]
/usr/bin/tor(options_init_from_torrc+0x471)[0x5563263d72f1]
/usr/bin/tor(+0x55531)[0x556326325531]
/usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0xe35)[0x7f63ca776a15]
/usr/bin/tor(do_main_loop+0x25f)[0x556326325e3f]
/usr/bin/tor(tor_run_main+0x1165)[0x556326328315]
/usr/bin/tor(tor_main+0x3a)[0x55632632032a]
/usr/bin/tor(main+0x19)[0x556326320099]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f63c90fab45]
/usr/bin/tor(+0x500e9)[0x5563263200e9]
```
Should `Sandbox` be in conflict with these option? If yes, this should be documented in man page, and Tor has to complain an error during startup.
== Problem 3
Suppose, you disable `Sandbox`, but keep the options `DataDirectoryGroupReadable` and `CacheDirectoryGroupReadable` in place. During start Tor sets directory permissions to `drwxr-x---` allowing `debian-tor` group to list files.
If you later grant read access to any file in this directory, Tor will remove this access soon. E.g., `state` file loses its group read permission at each Tor's startup. Other files may lose it less frequently. We are trapped in the situation where `DataDirectoryGroupReadable` and `CacheDirectoryGroupReadable` are useless: what's the goal to be able to read directory's content, bit be unable to read any file inside it?
Earlier it was in less conflict with different tools which control Tor, because it was recommended to run each tool on behalf of `debian-tor` user. Now it is recommended to run it from another user who is a member of `debian-tor` group (see discussion in [[https://trac.torproject.org/projects/tor/ticket/25890|#25890]]), but "group approach" also fails...
**Trac**:
**Username**: wagonTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/29896Backport connection_dir_buf_add() to 0.3.4 and later2020-06-13T15:39:49ZteorBackport connection_dir_buf_add() to 0.3.4 and laterWe need connection_dir_buf_add() in 0.3.4 for #21377.
But I don't want to backport all the refactoring, just the new function.We need connection_dir_buf_add() in 0.3.4 for #21377.
But I don't want to backport all the refactoring, just the new function.Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29897Refactor handle_get_next_bandwidth() to use connection_dir_buf_add()2020-06-13T15:39:50ZteorRefactor handle_get_next_bandwidth() to use connection_dir_buf_add()After #21377 merges, we want to refactor handle_get_next_bandwidth() to use connection_dir_buf_add().
If we backport this refactor to 0.4.0 or earlier, we'll also need #29896 for the connection_dir_buf_add() backport.After #21377 merges, we want to refactor handle_get_next_bandwidth() to use connection_dir_buf_add().
If we backport this refactor to 0.4.0 or earlier, we'll also need #29896 for the connection_dir_buf_add() backport.Tor: 0.4.0.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33411Make DirCache default to 0 on Windows relays, if we can't fix the mmap issues2020-06-13T15:51:45ZteorMake DirCache default to 0 on Windows relays, if we can't fix the mmap issuesIn #24857, tor's consensus diff cache implementation causes high CPU load on Windows.
As a workaround, we could make DirCache default to 0 on Windows.In #24857, tor's consensus diff cache implementation causes high CPU load on Windows.
As a workaround, we could make DirCache default to 0 on Windows.Tor: 0.4.4.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.org