The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-07-22T16:20:51Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26333Write trac templates for bug reports / other tickets, and link them from some...2021-07-22T16:20:51ZNick MathewsonWrite trac templates for bug reports / other tickets, and link them from somewhere usefulIt would be awesome if we could have templates for opening better trac tickets, in a way to actually help people include all the necessary info and not have a hard time figure out what they're supposed to say.
This might be an "internal...It would be awesome if we could have templates for opening better trac tickets, in a way to actually help people include all the necessary info and not have a hard time figure out what they're supposed to say.
This might be an "internal services" ticket, but before we can get it there, we need to figure out what we actually want.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26327Add Vagrant configurations for multiple different systems to contrib2020-06-27T13:53:14Zrl1987Add Vagrant configurations for multiple different systems to contribVagrant can enable us to have pre-configured VM blueprints with Tor development environment that developers could easily instantiate on their local machines.
We should have Vagrantfiles for:
* Linux (at least Debian, maybe some more)....Vagrant can enable us to have pre-configured VM blueprints with Tor development environment that developers could easily instantiate on their local machines.
We should have Vagrantfiles for:
* Linux (at least Debian, maybe some more).
* FreeBSD
* OpenBSD
* NetBSD
* Windows 10 (stretch goal)
* Android-x86 (stretch goal)Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26223Allow longer bandwidth lines in bandwidth files2020-06-27T13:53:20ZteorAllow longer bandwidth lines in bandwidth filesBandwidth files have a line limit of 510 characters (512 - newline and NUL).
We should make sure this limit is high enough for future bandwidth files.
We can do this by finding out the current length of sbws and torflow lines, multiply...Bandwidth files have a line limit of 510 characters (512 - newline and NUL).
We should make sure this limit is high enough for future bandwidth files.
We can do this by finding out the current length of sbws and torflow lines, multiplying it by 4x, then rounding up to the nearest power of two.
We can use the examples in the spec if we need to:
https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-spec.txt
Maybe we should wait until sbws has added all the new fields?Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26138DirPort /tor/server/all document contains spurrious blank line following serv...2020-07-28T19:13:56ZstarlightDirPort /tor/server/all document contains spurrious blank line following serving relay's descriptorissuing
```
curl -s http://x.x.x.x:x/tor/server/all.z | openssl zlib -d | less -SX
```
as expected retrieves a complete set of server descriptors; contains one blank line immediately after the descriptor of the serving relay which is n...issuing
```
curl -s http://x.x.x.x:x/tor/server/all.z | openssl zlib -d | less -SX
```
as expected retrieves a complete set of server descriptors; contains one blank line immediately after the descriptor of the serving relay which is not expected
trivial issue, but noticed it so reported it
glitch appears in 0.3.3 as wellTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26113Control spec is ambiguous whether a GETCONF error message is specified2020-07-31T14:03:27ZdmrControl spec is ambiguous whether a GETCONF error message is specifiedThe [[spec for `GETCONF` response](https://gitweb.torproject.org/torspec.git/tree/control-spec.txt?id=436d08b49fb84aa62d7bc96013002a0c27534bbb#n307|control)] says:
```
If some of the listed keywords can't be found, Tor replies with a
...The [[spec for `GETCONF` response](https://gitweb.torproject.org/torspec.git/tree/control-spec.txt?id=436d08b49fb84aa62d7bc96013002a0c27534bbb#n307|control)] says:
```
If some of the listed keywords can't be found, Tor replies with a
"552 unknown configuration keyword" message.
```
The spec also has a [[about error messages](https://gitweb.torproject.org/torspec.git/tree/control-spec.txt?id=436d08b49fb84aa62d7bc96013002a0c27534bbb#n1809|clause)]:
```
Unless specified to have specific contents, the human-readable messages
in error replies should not be relied upon to match those in this document.
```
Unfortunately, it's unclear what //specified to have specific contents// means here. The message for `GETCONF` is quoted, which at least in cursory read made me think it was //specified//.
But I suppose it's ambiguous.
==== Expected change
In discussion over IRC, arma suggested it...
> might be even better to change the spec to be like "replies with a 552 message because of the unrecognized configuration key."
Overall, it was agreed upon amongst arma, meejah, sysrqb, and myself that the spec shouldn't be denoting a specific message here, and that controllers shouldn't rely on a specific message. Only the numeric code `552` should be relied upon.https://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-final