Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:04:14Zhttps://gitlab.torproject.org/legacy/trac/-/issues/20932Coding Standards: No changes file for bug fix on unreleased code2020-06-13T15:04:14ZTracCoding Standards: No changes file for bug fix on unreleased codeWhile reviewing #20572, dgoulet said that a changes file is not used when fixing something that has not been released.
That's not stated in the `CodingStandards.md` yet, so it would help new contributors to clarify this.
**Trac**:
**...While reviewing #20572, dgoulet said that a changes file is not used when fixing something that has not been released.
That's not stated in the `CodingStandards.md` yet, so it would help new contributors to clarify this.
**Trac**:
**Username**: jryansTor: 0.3.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/20885Portions of the tor.1 man page and html doc formatted incorrectly2020-06-13T15:04:01ZTracPortions of the tor.1 man page and html doc formatted incorrectlySome portions of the tor.1 doc don't join paragraphs correctly, leading to strange output styles, especially in html view, which appears to default to <pre> blocks when asciidoc is confused by the syntax.
**Trac**:
**Username**: jryansSome portions of the tor.1 doc don't join paragraphs correctly, leading to strange output styles, especially in html view, which appears to default to <pre> blocks when asciidoc is confused by the syntax.
**Trac**:
**Username**: jryansTor: 0.3.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/20853rend_config_services should use service_is_ephemeral rather than old/new->dir...2020-06-13T15:03:52Zteorrend_config_services should use service_is_ephemeral rather than old/new->directoryWe missed this in the earlier refactor.
(Does that make it a bug? I think so.)We missed this in the earlier refactor.
(Does that make it a bug? I think so.)Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/20572hs: Remove the private key material from hs_descriptor.h2020-06-13T15:04:14ZDavid Gouletdgoulet@torproject.orghs: Remove the private key material from hs_descriptor.hBasically, we need to remove the private keys from some data structure in `hs_descriptor.h`. Namely:
```
ed25519_keypair_t signing_kp;
curve25519_keypair_t curve25519;
```
Those private keys should be in a dedicated data struct...Basically, we need to remove the private keys from some data structure in `hs_descriptor.h`. Namely:
```
ed25519_keypair_t signing_kp;
curve25519_keypair_t curve25519;
```
Those private keys should be in a dedicated data structure on the service side which we don't have yet so only put public keys there.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/20492Tor git version is not generated in git worktrees2020-07-31T12:44:02ZteorTor git version is not generated in git worktreesWhen I compile tor on macOS, it doesn't log the git version on startup:
```
Oct 29 01:27:48.261 [notice] Tor 0.3.0.0-alpha-dev running on Darwin with Libevent 2.0.22-stable, OpenSSL 1.0.2j and Zlib 1.2.8.
```
This happens regardless of ...When I compile tor on macOS, it doesn't log the git version on startup:
```
Oct 29 01:27:48.261 [notice] Tor 0.3.0.0-alpha-dev running on Darwin with Libevent 2.0.22-stable, OpenSSL 1.0.2j and Zlib 1.2.8.
```
This happens regardless of compiler and architecture:
gcc (MacPorts gcc49 4.9.4_0+universal) 4.9.4 (i386/x86_64)
clang version 3.9.0 (tags/RELEASE_390/final) (x86_64)
$ git --version
git version 2.10.1
But when I compile it on Linux, I see a git commit hash:
```
Oct 28 14:28:15.669 [notice] Tor 0.3.0.0-alpha-dev (git-f3e158edf7d8128d) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g and Zlib 1.2.8.
```
Compiler:
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
$ git --version
git version 2.6.3.36.g9a8c740
I'm putting this in 0.3.0 because it makes diagnosing issues much easier if we have the full commit. But feel free to disagree.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/20014GETINFO version in torspec is inconsistent with the implementation2020-06-13T15:00:50ZteorGETINFO version in torspec is inconsistent with the implementationThe torspec description of GETINFO version is:
```
"version" -- The version of the server's software, including the name
of the software. (example: "Tor 0.0.9.4")
```
But tor responds:
```
GETINFO version
250-version=0.2.8.6 (...The torspec description of GETINFO version is:
```
"version" -- The version of the server's software, including the name
of the software. (example: "Tor 0.0.9.4")
```
But tor responds:
```
GETINFO version
250-version=0.2.8.6 (git-4d217548e3f05569)
250 OK
```
The "Tor " is missing from the response. We should remove it from the spec.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/19965Log torrc option can't handle tab after severity2020-06-13T15:00:28ZRoger DingledineLog torrc option can't handle tab after severitySet your torrc file to be
```
log debug file /tmp/debug.log
```
where that long space is a tab.
Then `tor -f /path/to/torrc`
and you'll get
```
Aug 23 15:23:49.300 [warn] Couldn't parse log levels in Log option 'Log debug f...Set your torrc file to be
```
log debug file /tmp/debug.log
```
where that long space is a tab.
Then `tor -f /path/to/torrc`
and you'll get
```
Aug 23 15:23:49.300 [warn] Couldn't parse log levels in Log option 'Log debug file /tmp/debug.log'
Aug 23 15:23:49.300 [warn] Failed to parse/validate config: Failed to validate Log options. See logs for details.
Aug 23 15:23:49.300 [err] Reading config failed--see warnings above.
```
It looks like the issue is in parse_log_severity_config() where we do stuff like
```
space = strchr(cfg, ' ');
```
Reported by toralf.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18146Tor's control protocol misspells "Dependent"2020-06-13T14:53:45ZteorTor's control protocol misspells "Dependent"In getinfo_helper_config(), tor misspells "Dependent" as "Dependant".
There's probably nothing we can do about this, because it's part of the controller interface.
But we should at least document it, preferably in the code and the cont...In getinfo_helper_config(), tor misspells "Dependent" as "Dependant".
There's probably nothing we can do about this, because it's part of the controller interface.
But we should at least document it, preferably in the code and the control spec.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18145Avoid using "people" when we mean relays in tor's comments2020-06-13T14:53:44ZteorAvoid using "people" when we mean relays in tor's commentsThere are places in the tor codebase where relays and/or clients are referred to as "he" or "guy".
We could remove these unnecessary gender references, as it's more accurate to use "it" or "they".There are places in the tor codebase where relays and/or clients are referred to as "he" or "guy".
We could remove these unnecessary gender references, as it's more accurate to use "it" or "they".Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17605Stop HTTP caches storing or modifying X-Your-Address-Is from Tor Directory do...2020-06-13T14:51:03ZteorStop HTTP caches storing or modifying X-Your-Address-Is from Tor Directory documentsSome web caches (such as Farahavar's previous cache), pass on the X-Your-IP-Address-Is header from one directory document to multiple clients. This causes the clients to guess the wrong IP address as their address.
I think we should add...Some web caches (such as Farahavar's previous cache), pass on the X-Your-IP-Address-Is header from one directory document to multiple clients. This causes the clients to guess the wrong IP address as their address.
I think we should add one or more of the following headers to every directory response:
`Pragma: no-cache` tells HTTP 1.0 compliant caches to disable caching entirely. (This will also disable caching for HTTP 1.1 caches unless we provide a more generous Cache-Control header, like the one below.)
`Connection: close X-Your-IP-Address-Is` tells HTTP 1.1 caches to never send out the X-Your-IP-Address-Is header, even to the first client requesting the document.
`Cache-Control: no-cache="X-Your-IP-Address-Is"` tells HTTP 1.1 caches to not cache the header at all. Alternately, if the cache doesn't support the no-cache="<header-name>" feature, it tells the cache not to cache the entire document. (This also causes the cache to attempt to revalidate the header, which might not be what we want, as Tor doesn't support cache revalidation.)
I don't know enough about how caches typically behave to recommend which ones.
See:
* #16205 - bogus IP address / clock change from authority server
* https://lists.torproject.org/pipermail/tor-relays/2015-November/008137.htmlTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/17070".local" is mDNS for the local network, but tor assumes localhost2020-06-13T14:49:06Zteor".local" is mDNS for the local network, but tor assumes localhost`tor_addr_hostname_is_local` labels hostnames ending in ".local" as resolving to the loopback address. But ".local" is used for multicast DNS, so some names ending in ".local" may be on the local network(s), and not on 127.0.0.1 or ::1 o...`tor_addr_hostname_is_local` labels hostnames ending in ".local" as resolving to the loopback address. But ".local" is used for multicast DNS, so some names ending in ".local" may be on the local network(s), and not on 127.0.0.1 or ::1 or the associated netblocks.
https://en.wikipedia.org/wiki/Multicast_DNS
However, the current implementation is probably doing the right thing anyway, as allowing ".local" over SOCKS/Tor could open up access to servers or devices on Exit relays' local networks, which has security implications.
This may require a documentation change, or perhaps refactoring and review of all uses of `tor_addr_hostname_is_local` to see if they want only localhost, or local networks as well.Tor: 0.3.0.x-final