The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:53:30Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26011Alias GETINFO config-can-saveconf to config/can-saveconf2020-06-27T13:53:30ZteorAlias GETINFO config-can-saveconf to config/can-saveconfBecause we have a config/ hierarchy, so we should use it.
This will also need a control spec patch.Because we have a config/ hierarchy, so we should use it.
This will also need a control spec patch.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25978UseEntryGuards 0 disables EntryNodes2021-07-22T16:20:51ZTracUseEntryGuards 0 disables EntryNodesUseEntryNodes {se} should allow UseEntryGuards 0
But UseEntryGuards 0 breaks UseEntryNodes unless it can find a GuardNode which is against the purpose of UseEntryNodes in TORRC.
**Trac**:
**Username**: tortracUseEntryNodes {se} should allow UseEntryGuards 0
But UseEntryGuards 0 breaks UseEntryNodes unless it can find a GuardNode which is against the purpose of UseEntryNodes in TORRC.
**Trac**:
**Username**: tortracTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25914dirserv: Remove dead code2020-06-27T13:53:37ZDavid Gouletdgoulet@torproject.orgdirserv: Remove dead codeWhile working on legacy/trac#25610, I've noticed dead code that uses `dirserv_get_consensus()`.
In `networkstatus.c`, function `networkstatus_set_current_consensus()`:
We parse the flavor and if it is unknown, we bail early with:
```
...While working on legacy/trac#25610, I've noticed dead code that uses `dirserv_get_consensus()`.
In `networkstatus.c`, function `networkstatus_set_current_consensus()`:
We parse the flavor and if it is unknown, we bail early with:
```
if (flav < 0) {
/* XXXX we don't handle unrecognized flavors yet. */
log_warn(LD_BUG, "Unrecognized consensus flavor %s", flavor);
return -2;
}
```
But later in the function we have this if/else on the flavor name with a `else {}` statement that uses `dirserv_get_consensus()`. But we can't get into that else case since the first conditions are the only two flavors we can handle.
In between the first checks above and this if/else ^, the flavor can change as in we take the one from the given consensus but again, there is a check on if we can handle that flavor:
```
if (flav != usable_consensus_flavor() &&
!we_want_to_fetch_flavor(options, flav)) {
```
Bottom line, I think the `else {}` code is dead code. This simplifies the callgraph into the dirauth subsystem.Tor: 0.3.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25897manual: document that ControlSocket is disabled by default2021-07-22T16:20:51Zcypherpunksmanual: document that ControlSocket is disabled by defaulthttps://www.torproject.org/docs/tor-manual.html.en#ControlSocket
"
Like ControlPort, but listens on a Unix domain socket, rather than a TCP socket. 0 disables ControlSocket (Unix and Unix-like systems only.)
"
Please add:
"(Default: ...https://www.torproject.org/docs/tor-manual.html.en#ControlSocket
"
Like ControlPort, but listens on a Unix domain socket, rather than a TCP socket. 0 disables ControlSocket (Unix and Unix-like systems only.)
"
Please add:
"(Default: 0)" add the end (as you do with most other entries).Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25892Replace RejectPlaintextPorts with RejectPlaintextPortPolicy2020-07-28T19:07:26ZcypherpunksReplace RejectPlaintextPorts with RejectPlaintextPortPolicyhttp://expyuzz4wqqyqhjn.onion/docs/tor-manual.html.en
RejectPlaintextPorts port,port
I want my Tor to allow only port 443(HTTPS) and 9877(XMPP).
But current RejectPlaintextPorts is not easy to use because I have to
set "RPP 0,1,2,3,4.....http://expyuzz4wqqyqhjn.onion/docs/tor-manual.html.en
RejectPlaintextPorts port,port
I want my Tor to allow only port 443(HTTPS) and 9877(XMPP).
But current RejectPlaintextPorts is not easy to use because I have to
set "RPP 0,1,2,3,4...65535".
I want something like this:
AccessibleTorPorts 443,9877
AccessibleTorPorts reject *
format:
AccessibleTorPorts port[,port...]
AccessibleTorPorts reject [port|*]Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25857::/128 is not the IPv6 equivalent of 0.0.0.0/02021-07-22T16:20:51ZTrac::/128 is not the IPv6 equivalent of 0.0.0.0/0The [man page of tor](https://gitweb.torproject.org/tor.git/tree/doc/tor.1.txt#n1837) states that "::/128" is the IPv6 equivalent of IPv4's "0.0.0.0/0" and that is not correct.
The equivalent of "0.0.0.0/0" in IPv6 is "::/0"
The IPv4 e...The [man page of tor](https://gitweb.torproject.org/tor.git/tree/doc/tor.1.txt#n1837) states that "::/128" is the IPv6 equivalent of IPv4's "0.0.0.0/0" and that is not correct.
The equivalent of "0.0.0.0/0" in IPv6 is "::/0"
The IPv4 equivalent of "::/128" would be "0.0.0.0/32".
https://en.wikipedia.org/wiki/IPv6_address#Unicast_addresses
**Trac**:
**Username**: CTassisFTor: 0.3.3.x-finalDamian JohnsonDamian Johnsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25839conn: Move connection bandwidth stuff into its own file2021-09-16T14:30:52ZDavid Gouletdgoulet@torproject.orgconn: Move connection bandwidth stuff into its own fileIn connection.c, we have the connection's bw management which means there are lots of functions only dealing with the `global_bucket` and per-connection rw bucket.
We could move all this to its own file like `connection_bw.c` to offload...In connection.c, we have the connection's bw management which means there are lots of functions only dealing with the `global_bucket` and per-connection rw bucket.
We could move all this to its own file like `connection_bw.c` to offload connection.c making it nicer, clearer and more modularized.https://gitlab.torproject.org/tpo/core/tor/-/issues/25786Policies for HTTPTunnelPort2021-09-16T14:30:52ZTracPolicies for HTTPTunnelPortFor SocksPort/Socks5Port one can configure SocksPolicy.
There should be corresponding option for HTTPTunnelPort.
**Trac**:
**Username**: pyhedgehogFor SocksPort/Socks5Port one can configure SocksPolicy.
There should be corresponding option for HTTPTunnelPort.
**Trac**:
**Username**: pyhedgehoghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25784Misleading error message when asking for IPv6 in a network with no IPv6-capab...2020-07-28T19:09:59ZpastlyMisleading error message when asking for IPv6 in a network with no IPv6-capable exitsI created a small test Tor network. 3 authorities, 7 relays, 3 exits. Great.
I didn't set `IPv6Exit 1` on any of the exits.
I had a client try to request `::1` over this Tor network on a hand crafted circuit (it makes sense to ask an e...I created a small test Tor network. 3 authorities, 7 relays, 3 exits. Great.
I didn't set `IPv6Exit 1` on any of the exits.
I had a client try to request `::1` over this Tor network on a hand crafted circuit (it makes sense to ask an exit to connect to localhost when this is all local ... trust me). I got the following confusing error message on the client.
> [warn] I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's not going to work. Did you perhaps ask for an IPv6 address on an IPv4Only port, or vice versa?
I think it's important to point out (again) that I was hand crafting these circuits and was not considering IPv6 support. That said, I don't know what Tor would do if I let it make the circuit for me and it couldn't find an IPv6-supporting exit.
As you can see, I'm talking myself out of this being a bug and it just being me screwing things up for myself. I was encouraged to make a ticket though, so here we are.
If rewriting the error message is the solution, maybe after fixing the "fulfil" typo, we should add "It's also possible we couldn't find any exits supporting the IP version you want to use"
I'm picking 0.3.5.x-final just because I've been told you have to pick a milestone or else your tickets generally fall through the cracks. :)Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25720man: RephistTrackTime is not a dirauth only option2021-07-22T16:20:51ZDavid Gouletdgoulet@torproject.orgman: RephistTrackTime is not a dirauth only optionWe should move the `RephistTrackTime` man page entry to the server side options because every node use it when dumping stats on a SIGUSR1.We should move the `RephistTrackTime` man page entry to the server side options because every node use it when dumping stats on a SIGUSR1.Tor: 0.3.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25661RendPostPeriod and HiddenServiceAuthorizeClient are v2 only2021-09-30T13:46:29ZteorRendPostPeriod and HiddenServiceAuthorizeClient are v2 onlyRendPostPeriod and HiddenServiceAuthorizeClient only apply to v2 onion services. We should update the man page so this is clearer.RendPostPeriod and HiddenServiceAuthorizeClient only apply to v2 onion services. We should update the man page so this is clearer.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25645n_possible variable goes unused in channel_get_for_extend()2020-06-27T13:53:50ZRoger Dingledinen_possible variable goes unused in channel_get_for_extend()```
$ grep n_possible *.c
channel.c: int n_noncanonical = 0, n_possible = 0;
channel.c: ++n_possible;
```
All we do is start it off at 0, and increment it sometimes.
Maybe it had a purpose once, but it doesn't anymore.```
$ grep n_possible *.c
channel.c: int n_noncanonical = 0, n_possible = 0;
channel.c: ++n_possible;
```
All we do is start it off at 0, and increment it sometimes.
Maybe it had a purpose once, but it doesn't anymore.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25618Document ISO_STREAM in the tor man page2021-07-22T16:20:50ZteorDocument ISO_STREAM in the tor man pageTor applies stream isolation by default: each new origin stream gets a new circuit.
This means that the default behaviour of Tor is stricter than IsolateDestAddr and IsolateDestPort, because each different destination address or port ne...Tor applies stream isolation by default: each new origin stream gets a new circuit.
This means that the default behaviour of Tor is stricter than IsolateDestAddr and IsolateDestPort, because each different destination address or port needs a new stream.
We should document this in the tor man page under the SOCKSPort option.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25530Closing Tor cleanly from command line (when started from command line) on win322020-07-28T18:48:06ZTracClosing Tor cleanly from command line (when started from command line) on win32When I close Tor after a session being started through Tor Browser, I see the log:
```
Mar 11 02:21:08.000 [notice] Owning controller connection has closed -- exiting now.
Mar 11 02:21:08.000 [notice] Catching signal TERM, exiting clean...When I close Tor after a session being started through Tor Browser, I see the log:
```
Mar 11 02:21:08.000 [notice] Owning controller connection has closed -- exiting now.
Mar 11 02:21:08.000 [notice] Catching signal TERM, exiting cleanly.
```
I think there's some operations Tor does in order to close it self cleanly.
I usually run Tor over command line (_**Windows 10**_) through:
```
cd "C:\Tor Browser\Browser\"
"C:\Tor Browser\Browser\TorBrowser\Tor\tor.exe" -f "C:\Tor Browser\Browser\TorBrowser\Data\Tor\torrc" | more
```
I just kill the _tor.exe_ process in order to close it. I don't get those two logs.
How could I close Tor cleanly through command line?
**Trac**:
**Username**: omareg94Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25432remove router.c internal functions from router.h2021-09-16T14:31:19ZTracremove router.c internal functions from router.hThese functions (group A):
```
A
const char *router_get_description(char *buf, const routerinfo_t *ri);
const char *node_get_description(char *buf, const node_t *node);
const char *routerstatus_get_description(char *buf, const routerstat...These functions (group A):
```
A
const char *router_get_description(char *buf, const routerinfo_t *ri);
const char *node_get_description(char *buf, const node_t *node);
const char *routerstatus_get_description(char *buf, const routerstatus_t *rs);
const char *extend_info_get_description(char *buf, const extend_info_t *ei);
```
Do the same as these (group B):
```
B
const char *router_describe(const routerinfo_t *ri);
const char *node_describe(const node_t *node);
const char *routerstatus_describe(const routerstatus_t *ri);
const char *extend_info_describe(const extend_info_t *ei);
```
With the difference that those last allocate a buffer, instead of forcing the caller to create and pass the buffer as a parameter.
The functions from group B are an abstraction to the ones from group A: they are better because they always generate buffers of enough size (the size is NODE_DESC_BUF_LEN). So, we should avoid using group A.
By now, both groups are declared in the header, and there is only one use of a function of group A (router_get_description is used on dirserv.c).
Also, all those functions are abstractions to format_node_description, that should also not be used externally, so we could also remove this one from the header.
The constant NODE_DESC_BUF_LEN is not necessary externally either.
**Trac**:
**Username**: valentecaioTor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25412TrackHostExits option in torrc file not working as documented2021-07-22T16:20:50ZTracTrackHostExits option in torrc file not working as documented1. Shut down Tor
2. Edit torrc file at c:\Program Files (x86)\Tor Browser\Browser\TorBrowser\Data\Tor\torrc so that it has the line:
TrackHostExits .
According to docs, this should mean to use the same exit node for all websites.
3. L...1. Shut down Tor
2. Edit torrc file at c:\Program Files (x86)\Tor Browser\Browser\TorBrowser\Data\Tor\torrc so that it has the line:
TrackHostExits .
According to docs, this should mean to use the same exit node for all websites.
3. Launch Tor, and open any two websites - let's say https://duckduckgo.com/ and https://www.nasa.gov/
4. Note that the exit node for each website may differ. If not reproducing, try using the IP addresses rather than URLs.
Why is this a problem? Some sites will generate a link that only works from the same IP as the original page. (In my case, one link is an IP that cannot be resolved to a URL, so using a URL isn't an option.)
Version: Tor 7.5 (The versions in the picker are massively out of date - not a good sign.)
**Trac**:
**Username**: LittleTorFanAnnieTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25398tests fail if COMPAT_HAS_MMAN_AND_PAGESIZE is not set2020-06-27T13:54:00ZAlex Xutests fail if COMPAT_HAS_MMAN_AND_PAGESIZE is not set`tor_mmap_file` doesn't check for empty files if `COMPAT_HAS_MMAN_AND_PAGESIZE` is not set, causes `test_util_mmap` to fail`tor_mmap_file` doesn't check for empty files if `COMPAT_HAS_MMAN_AND_PAGESIZE` is not set, causes `test_util_mmap` to failTor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25290refactor to use should_record_bridge_info() more2021-09-16T14:31:19ZRoger Dingledinerefactor to use should_record_bridge_info() moreWe have this function
`should_record_bridge_info`
which simply checks
`options->BridgeRelay && options->BridgeRecordUsageByCountry`.
But in geoip_note_client_seen(), where we just added the DoS mitigation stuff, we don't use the functio...We have this function
`should_record_bridge_info`
which simply checks
`options->BridgeRelay && options->BridgeRecordUsageByCountry`.
But in geoip_note_client_seen(), where we just added the DoS mitigation stuff, we don't use the function, instead choosing to check the variables directly. We make the same choice in the options_need_geoip_info() function.
We should refactor things so we use the function in all cases.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25284hidden-service-dir description in dir-spec should reference HSDir protovers2021-09-30T13:50:08Zteorhidden-service-dir description in dir-spec should reference HSDir protoversSince 0.3.0, tor supports HSDir versions 2 and 3 by default, and advertises no hidden-service-dir VersionNums.
But the spec says:
"If any VersionNum(s) are specified, this router supports those descriptor versions. If none are specified...Since 0.3.0, tor supports HSDir versions 2 and 3 by default, and advertises no hidden-service-dir VersionNums.
But the spec says:
"If any VersionNum(s) are specified, this router supports those descriptor versions. If none are specified, it defaults to version 2 descriptors"Tor: 0.3.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25269Set codegen-units to 1 in src/rust/Cargo.toml to eke out every last drop of p...2020-07-28T18:41:01ZcypherpunksSet codegen-units to 1 in src/rust/Cargo.toml to eke out every last drop of performanceRust 1.24 now sets codegen-units to 16 by default to speed up compilation time but it makes the final binary slower https://blog.rust-lang.org/2018/02/15/Rust-1.24
> For maximum speed, setting `codegen-units` to `1` in your `Cargo.toml`...Rust 1.24 now sets codegen-units to 16 by default to speed up compilation time but it makes the final binary slower https://blog.rust-lang.org/2018/02/15/Rust-1.24
> For maximum speed, setting `codegen-units` to `1` in your `Cargo.toml` is needed to eke out every last drop of performance.
So [src/rust/Cargo.toml](https://gitweb.torproject.org/tor.git/tree/src/rust/Cargo.toml) should be changed with that to squeeze the most perf.Tor: unspecified