Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T13:52:48Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26890Redefine coverity version of the BUG macro2020-06-27T13:52:48ZNick MathewsonRedefine coverity version of the BUG macroOur BUG macro definition is all wrong for coverity.
We shouldn't be including __coverity_panic__, since hitting a BUG doesn't actually mean Tor will crashed, and we shouldn't imply that the condition might be visited anyway. We should ...Our BUG macro definition is all wrong for coverity.
We shouldn't be including __coverity_panic__, since hitting a BUG doesn't actually mean Tor will crashed, and we shouldn't imply that the condition might be visited anyway. We should just do "#define BUG(x) (x)" when we're building with coverity.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26892log_addr_has_changed() does not heed SafeLogging2020-06-27T13:52:48Zrl1987log_addr_has_changed() does not heed SafeLoggingNo IP address scrubbing is performed at any loglevel:
```
2694 if (!tor_addr_is_null(prev))
2695 log_fn(severity, LD_GENERAL,
2696 "Our IP Address has changed from %s to %s; "
2697 "rebuilding descriptor (sou...No IP address scrubbing is performed at any loglevel:
```
2694 if (!tor_addr_is_null(prev))
2695 log_fn(severity, LD_GENERAL,
2696 "Our IP Address has changed from %s to %s; "
2697 "rebuilding descriptor (source: %s).",
2698 addrbuf_prev, addrbuf_cur, source);
2699 else
2700 log_notice(LD_GENERAL,
2701 "Guessed our IP address as %s (source: %s).",
2702 addrbuf_cur, source);
```Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26893spec: all-zeroes special case is for relay IDs, not cell digests2020-06-27T13:52:48ZTaylor Yuspec: all-zeroes special case is for relay IDs, not cell digeststor-spec.txt Section 5.3 (Creating circuits) says:
```
As special cases, if the extend cell includes a digest of
all zeroes, or asks to extend back to the relay that sent the extend
```
The implementation uses "digest" internally t...tor-spec.txt Section 5.3 (Creating circuits) says:
```
As special cases, if the extend cell includes a digest of
all zeroes, or asks to extend back to the relay that sent the extend
```
The implementation uses "digest" internally to refer to relay ID hashes, while tor-spec.txt primarily uses it to refer to the truncated running SHA-1 hash that relays use to "recognize" a cell as targeting them.
arma says this probably intends to refer to relay ID hashes, and pointed to commit e34727a65c411a6260f3960ff8a753088e287565.
We should reword this text to make it clear it refers to relay ID hashes.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26894spec: say CREATE/CREATE2 and EXTEND/EXTEND2 when we mean to2020-06-27T13:52:48ZTaylor Yuspec: say CREATE/CREATE2 and EXTEND/EXTEND2 when we mean toIn several places in tor-spec.txt, it looks like we say only `CREATE` or `EXTEND` when we really mean to also include `CREATE2` or `EXTEND2`. We should fix those.In several places in tor-spec.txt, it looks like we say only `CREATE` or `EXTEND` when we really mean to also include `CREATE2` or `EXTEND2`. We should fix those.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26899Rev counter prevents easy move of v3 onion service2020-06-27T13:52:47ZirlRev counter prevents easy move of v3 onion serviceThis weekend I was moving a v3 onion service to another box. Copying the folder alone was not enough. I also had to manually edit the rev counter in the state file otherwise the hs descriptors were always rejected as invalid. It took me ...This weekend I was moving a v3 onion service to another box. Copying the folder alone was not enough. I also had to manually edit the rev counter in the state file otherwise the hs descriptors were always rejected as invalid. It took me a while to figure this out, perhaps I was looking in the wrong place or perhaps this isn't documented.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26903Document what 'GETINFO net/listeners/*' do2020-06-27T13:52:47ZDamian JohnsonDocument what 'GETINFO net/listeners/*' doHi lovely tor folks. Minor thing but a recent spec addition made me realize that we should document what the listener ports do...
https://gitweb.torproject.org/torspec.git/commit/?id=a8a838f
Personally I haven't a clue what extor or ht...Hi lovely tor folks. Minor thing but a recent spec addition made me realize that we should document what the listener ports do...
https://gitweb.torproject.org/torspec.git/commit/?id=a8a838f
Personally I haven't a clue what extor or httptunnel endpoints are, and if I'm puzzled by them I suspect others might be as well. ;)
This is an existing problem. Control, dns, and such weren't documented either. Since they were self explanatory it didn't seem worth bringing this up when we first added the field, but now that the endpoints are getting more exotic I'd appreciate a short description in the spec for what they do.
Thanks!Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26927Improve the log message when peer id authentication fails2020-06-27T13:52:46ZteorImprove the log message when peer id authentication failsSplit off legacy/trac#26924.Split off legacy/trac#26924.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26942Privcount blinding and encryption: Rust code conventions2020-06-27T13:52:44ZteorPrivcount blinding and encryption: Rust code conventionsRust code convention fixes from https://trac.torproject.org/projects/tor/ticket/25669#comment:15Rust code convention fixes from https://trac.torproject.org/projects/tor/ticket/25669#comment:15Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26946Privcount blinding and encryption: warning fixes2020-06-27T13:52:44ZteorPrivcount blinding and encryption: warning fixesprivcount_shamir builds and tests ok, but has a few warnings.
Split off legacy/trac#25669.privcount_shamir builds and tests ok, but has a few warnings.
Split off legacy/trac#25669.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26947Add function for reporting the tor version in tor_api.h2020-06-27T13:52:44ZArturo FilastòAdd function for reporting the tor version in tor_api.hAs a user of libtor_api it would be useful for me to be able to obtain the version of tor without having to call it's main function.
The function could look something like:
```
const char * tor_version()
{
return tor_version_string...As a user of libtor_api it would be useful for me to be able to obtain the version of tor without having to call it's main function.
The function could look something like:
```
const char * tor_version()
{
return tor_version_string;
}
```
This would be very useful for a user of the library that wishes to check if they have linked to the right tor version (or implement some sanity checks) without having to start tor and then speak to it on the control port (therefore paying some significant overhead).Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26948tor_run_main crashes when called a second time with --version2020-06-27T13:52:43ZArturo Filastòtor_run_main crashes when called a second time with --versionI wrote a testing harness that uses python and cffi, to implement some basic smoke tests for libtor. This can be found here: https://gist.github.com/hellais/b56043d57eb5be885958e80b3665bfe2 (to run it do pip install cffi and change the ...I wrote a testing harness that uses python and cffi, to implement some basic smoke tests for libtor. This can be found here: https://gist.github.com/hellais/b56043d57eb5be885958e80b3665bfe2 (to run it do pip install cffi and change the LIB_PATH to the correct path).
In particular by adding the command line flag --version and starting tor, I am unable to re-start it due to the exception listed in the above gist.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26952Try enabling ccache on Travis2020-06-27T13:52:43ZteorTry enabling ccache on TravisBased on my branch in legacy/trac#24629.Based on my branch in legacy/trac#24629.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26953Privcount blinding and encryption: add travis CI2020-06-27T13:52:43ZteorPrivcount blinding and encryption: add travis CIBecause I don't want to spend all my time running multiple builds.Because I don't want to spend all my time running multiple builds.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26955Privcount blinding and encryption: rustfmt2020-06-27T13:52:43ZteorPrivcount blinding and encryption: rustfmtI'm going to rustfmt the entire codebase, so I don't have spurious changes when I edit particular files.I'm going to rustfmt the entire codebase, so I don't have spurious changes when I edit particular files.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26956Privcount blinding and encryption: deny warnings2020-06-27T13:52:43ZteorPrivcount blinding and encryption: deny warningsLet's fail the Travis build on any warning.Let's fail the Travis build on any warning.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26972Create make target to ensure that all Rust files have been formatted with rus...2020-06-27T13:52:42ZChelsea KomloCreate make target to ensure that all Rust files have been formatted with rustfmtWe should have a CI task that ensures Rust files have been properly formatted- this will be helpful when reviewing PRs.
Other linting tooling can be added here in the future (for example, any clippy warnings we want to explicitly check...We should have a CI task that ensures Rust files have been properly formatted- this will be helpful when reviewing PRs.
Other linting tooling can be added here in the future (for example, any clippy warnings we want to explicitly check) but starting with rustfmt seems like a good first step.
It looks like running rustfmt with `--check` will be helpful here: https://github.com/rust-lang-nursery/rustfmt#runningTor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26986Appveyor CI fails on master due to #195062020-06-27T13:52:42ZteorAppveyor CI fails on master due to #19506For some reason, Appveyor CI didn't run on the pull request for legacy/trac#19506:
https://github.com/torproject/tor/pull/216
When legacy/trac#19506 was merged to master, it failed Appveyor with:
```
../src/tools/tor-print-ed-signing-ce...For some reason, Appveyor CI didn't run on the pull request for legacy/trac#19506:
https://github.com/torproject/tor/pull/216
When legacy/trac#19506 was merged to master, it failed Appveyor with:
```
../src/tools/tor-print-ed-signing-cert.c:52:67: error: unknown conversion type character 'z' in format [-Werror=format=]
fprintf(stderr, "ed25519_cert_parse failed with return value %zd\n",
^
../src/tools/tor-print-ed-signing-cert.c:52:21: error: too many arguments for format [-Werror=format-extra-args]
fprintf(stderr, "ed25519_cert_parse failed with return value %zd\n",
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/tools/tor-print-ed-signing-cert.c:52:67: error: unknown conversion type character 'z' in format [-Werror=format=]
fprintf(stderr, "ed25519_cert_parse failed with return value %zd\n",
^
../src/tools/tor-print-ed-signing-cert.c:52:21: error: too many arguments for format [-Werror=format-extra-args]
fprintf(stderr, "ed25519_cert_parse failed with return value %zd\n",
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26994Solaris 10: test_bwmgt.c compile error with tor-0.3.4.5-rc2020-06-27T13:52:41ZTracSolaris 10: test_bwmgt.c compile error with tor-0.3.4.5-rcI'm running in the same compile error on all tor-0.3.4.* versions
when trying to build tor on Solaris 10
tor-0.3.3.9 builds and works without any issue.
The error looks like:
```
In file included from /usr/include/sys/select.h:23:0,
...I'm running in the same compile error on all tor-0.3.4.* versions
when trying to build tor on Solaris 10
tor-0.3.3.9 builds and works without any issue.
The error looks like:
```
In file included from /usr/include/sys/select.h:23:0,
from /usr/include/sys/types.h:616,
from /usr/include/unistd.h:20,
from ./src/or/or.h:18,
from src/test/test_bwmgt.c:11:
src/test/test_bwmgt.c: In function ‘test_bwmgt_token_buf_refill’:
src/test/test_bwmgt.c:127:18: error: expected identifier or ‘(’ before numeric constant
const uint32_t SEC =
^
gmake[1]: *** [src/test/src_test_test-test_bwmgt.o] Error 1
gmake[1]: Leaving directory `/usr/local/lib/tor-0.3.4.5-rc'
gmake: *** [all] Error 2
```
Any help is appreciated.
Thanks.
Knut
**Trac**:
**Username**: KnutTor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27003Regression: 'SETCONF ORPort' can kill tor process2020-06-27T13:52:41ZDamian JohnsonRegression: 'SETCONF ORPort' can kill tor processHi network team. Recently-ish Stem's integ tests began failing when ran with network tests ('run_tests.py --integ --target ONLINE'). Here's the repro...
1. My torrc...
```
DataDirectory /home/atagar/.tor
ORPort 9052
ControlPort 9051
Ex...Hi network team. Recently-ish Stem's integ tests began failing when ran with network tests ('run_tests.py --integ --target ONLINE'). Here's the repro...
1. My torrc...
```
DataDirectory /home/atagar/.tor
ORPort 9052
ControlPort 9051
ExitRelay 0
```
2. Start tor.
3. Connect to the control port and toggle the ORPort off and on...
```
% telnet localhost 9051
AUTHENTICATE
250 OK
RESETCONF ORPort
250 OK
SETCONF ORPort=9090
Connection closed by foreign host.
```
The tor dies with...
```
Jul 31 14:49:21.000 [notice] Opening OR listener on 0.0.0.0:9090
Jul 31 14:49:21.000 [warn] Can't get my x509 link cert.
Jul 31 14:49:21.000 [err] Unable to update Ed25519 keys! Exiting.
Jul 31 14:49:21.000 [notice] Your Tor server's identity key fingerprint is 'Unnamed 4853AB6F9215A837EA3562CF4AF00713737FDF01'
Jul 31 14:49:21.000 [notice] Now checking whether ORPort 71.231.87.208:9090 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Jul 31 14:49:21.000 [notice] Configured to measure directory request statistics, but no GeoIP database found. Please specify a GeoIP database using the GeoIPFile option.
```
This was with the latest tor git commit (7e4ac02).Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27034Clarification on 'GETINFO exit-policy/*'s valid 'non-transient internal errors'2020-06-27T13:52:40ZDamian JohnsonClarification on 'GETINFO exit-policy/*'s valid 'non-transient internal errors'Hi network team. I was just about to tweak Stem to treat 552 GETINFO response codes as "I'm not configured to be a relay" per...
https://trac.torproject.org/projects/tor/ticket/25853
https://trac.torproject.org/projects/tor/ticket/25852...Hi network team. I was just about to tweak Stem to treat 552 GETINFO response codes as "I'm not configured to be a relay" per...
https://trac.torproject.org/projects/tor/ticket/25853
https://trac.torproject.org/projects/tor/ticket/25852
https://gitweb.torproject.org/torspec.git/commit/?id=c5453a0
However, the spec addition says "Will send 552 error if the server is not running as nion router or if there's non-transient internal error." So I'm unsure what the response code actually indicates. If we *are* a relay that what are the scenarios where tor validly returns a 552?
For now in stem gonna pretend that part doesn't exist and 552s indicate 'not a relay'. :)Tor: 0.3.5.x-finalrl1987rl1987