Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T16:56:17Zhttps://gitlab.torproject.org/legacy/trac/-/issues/29101Configure the push hook from git.tpo to github for fallback-scripts2020-06-13T16:56:17ZteorConfigure the push hook from git.tpo to github for fallback-scriptsWe need to:
* create a repository for fallback-scripts on https://github.com/torproject
* give phoul and teor and network-team and the pusher permissions
* configure the pusher on the git.torproject.org endWe need to:
* create a repository for fallback-scripts on https://github.com/torproject
* give phoul and teor and network-team and the pusher permissions
* configure the pusher on the git.torproject.org endTor: 0.4.0.x-finalhttps://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/28247Use build.rs in place of test_linking_hack2020-06-13T15:33:31ZNick MathewsonUse build.rs in place of test_linking_hackSee Alex Crichton's comments at https://github.com/torproject/tor/commit/a8ac21fbb5f22b68ffa019b575085c142293bc40#commitcomment-30729271See Alex Crichton's comments at https://github.com/torproject/tor/commit/a8ac21fbb5f22b68ffa019b575085c142293bc40#commitcomment-30729271Tor: 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/28192Work out why 0.3.5 and later fail chutney (but 0.3.4 and earlier do not)2020-06-13T15:33:20ZteorWork out why 0.3.5 and later fail chutney (but 0.3.4 and earlier do not)In #27912, I created a chutney travis config.
0.2.9, 0.3.3, and 0.3.4 fail less than 1% of the time.
0.3.5 and 0.3.6 fail about 90% of the time.In #27912, I created a chutney travis config.
0.2.9, 0.3.3, and 0.3.4 fail less than 1% of the time.
0.3.5 and 0.3.6 fail about 90% of the time.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28135Bad CERTS cells in mixed chutney network2020-06-13T15:33:08ZteorBad CERTS cells in mixed chutney networkYet another mixed network error - these race conditions really are exercising a whole lot of unusual code paths:
```
FAIL: mixed+hs-v2
Detail: chutney/tools/warnings.sh /Users/base/chutney/net/nodes.1537279328
Warning: Received a bad CER...Yet another mixed network error - these race conditions really are exercising a whole lot of unusual code paths:
```
FAIL: mixed+hs-v2
Detail: chutney/tools/warnings.sh /Users/base/chutney/net/nodes.1537279328
Warning: Received a bad CERTS cell from 127.0.0.1:5002: Problem setting or checking peer id Number: 1
Warning: Received a bad CERTS cell from 127.0.0.1:5003: Problem setting or checking peer id Number: 1
Warning: Tried connecting to router at 127.0.0.1:5002, but RSA identity key was not as expected: wanted F0F7644942E7570548AA9BB1763F643123CE40C5 + no ed25519 key but got 72658EEB1AB9F6326635849C1D33052FC0C0F551 + 95IoksCTUXVIyqHU+lPMR3ppCzj+AdT5Bpg6BTSKDzI. Number: 1
Warning: Tried connecting to router at 127.0.0.1:5003, but RSA identity key was not as expected: wanted 185EF19538055B8B6F591224A66F0516C204BE98 + no ed25519 key but got 945CD7D474D11CA2A6DBEF63715477BA17657E68 + RT2D7+9+F4bADlz7427uBoUrV3iKtSz31l7/xT/xTls. Number: 1
Warning: http status 400 ("Nonauthoritative directory does not accept posted server descriptors") response from dirserver '127.0.0.1:7002'. Please correct. Number: 3
Warning: http status 400 ("Nonauthoritative directory does not accept posted server descriptors") response from dirserver '127.0.0.1:7003'. Please correct. Number: 3
```Tor: 0.3.5.x-finalhttps://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/27914Extract fallback-scripts to its own git repository2020-06-13T16:06:32ZNick MathewsonExtract fallback-scripts to its own git repositoryThis would let us give teor and phoul direct commit permissions here.This would let us give teor and phoul direct commit permissions here.Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/27273ASan fails to link on Travis due to rustc and linker arguments2020-06-13T15:33:29ZTracASan fails to link on Travis due to rustc and linker argumentsIn helping to debug https://trac.torproject.org/projects/tor/ticket/25386 I've found that a number of the link errors are attributable to the linker invocation on Travis. The recent `link_rust.sh` script is definitely necessary I think, ...In helping to debug https://trac.torproject.org/projects/tor/ticket/25386 I've found that a number of the link errors are attributable to the linker invocation on Travis. The recent `link_rust.sh` script is definitely necessary I think, except that I believe it needs a few tweaks:
* The `-lasan` argument should be replaced with `-fsanitizer=address` I believe to ensure that the C compiler links all of its relevant libraries (as they may have different names and different numbers of libs on some platforms I think).
* Second, the Rust compiler by default passes `-nodefaultlibs` to the linker which means that the linker script also passes this along. It looks, however, like this is incompatible with `-fsanitizer=address`, causing link errors. This argument should be safe to strip out though.
The first bullet was easy enough to fix locally and the second bullet was fixable by changing `link_rust.sh` to a `bash` script and then using something like:
```
linker_args="$@"
$CCLD @RUST_LINKER_OPTIONS@ ${linker_args//-nodefaultlibs/}
```
**Trac**:
**Username**: alexcrichtonTor: 0.3.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/27146Mismatched digest in 0.3.3.9 and master mixed chutney network2020-06-13T15:32:51ZteorMismatched digest in 0.3.3.9 and master mixed chutney networkWhen I run master i386 and Tor 0.3.3.9 x68_64 in a mixed chutney network, I see the following error:
```
Detail: chutney/tools/warnings.sh /Users/USER/tor/chutney/tools/../net/nodes.1534263100
Warning: Unable to add signatures to consens...When I run master i386 and Tor 0.3.3.9 x68_64 in a mixed chutney network, I see the following error:
```
Detail: chutney/tools/warnings.sh /Users/USER/tor/chutney/tools/../net/nodes.1534263100
Warning: Unable to add signatures to consensus: Mismatched digest. Number: 102
Exit 255
```
master x86_64 and Tor 0.3.3.9 x68_64 in a mixed chutney network also get the same error:
```
Detail: chutney/tools/warnings.sh /Users/USER/tor/chutney/tools/../net/nodes.1534285790
Warning: Unable to add signatures to consensus: Mismatched digest. Number: 102
Exit 255
```
We should fix this issue if it affects Linux and BSD. If it doesn't, maybe we should downgrade our support for authorities on macOS.
If we want to diagnose this issue, implementing #20625 and #4539 would help.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26908make it more clear that torrc files should not contain any bridges in their M...2020-06-13T15:28:33Znusenumake it more clear that torrc files should not contain any bridges in their MyFamily lines
We improved this part of the documentation in the past but it is still not clear enough:
https://lists.torproject.org/pipermail/tor-relays/2018-July/015735.html
lets add:
"Do NOT add MyFamily lines to your bridge configuration files."...
We improved this part of the documentation in the past but it is still not clear enough:
https://lists.torproject.org/pipermail/tor-relays/2018-July/015735.html
lets add:
"Do NOT add MyFamily lines to your bridge configuration files."
to the torrc and MyFamily section of the man page.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26812hs: Adding client authorization through control port on an existing service f...2020-06-13T15:28:07ZDavid Gouletdgoulet@torproject.orghs: Adding client authorization through control port on an existing service fails(Comes from reported issue in #26776).
The scenario is this:
* You have a configured HiddenService that has been configured through the control port (`SETCONF`) *without* client authorization.
* From the control port, you then `SETCON...(Comes from reported issue in #26776).
The scenario is this:
* You have a configured HiddenService that has been configured through the control port (`SETCONF`) *without* client authorization.
* From the control port, you then `SETCONF` that same hidden service directory but with client authorization this time. The service will still be reachable without the client authorization that has just been set up.
The issue I believe comes from our transition from staging to the ready service list. See the crazy function `rend_service_prune_list_impl_()` for v2, we keep the introduction points alive even if we now have client authorization. Not good...Tor: 0.3.5.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/26787Core file left on travis hardened rust builld2020-06-13T15:28:01ZMike PerryCore file left on travis hardened rust builldhttps://travis-ci.org/torproject/tor/jobs/403730172
It looks like all the tests pass, the only problem I can see is the mysterious core left over at the end. I'm unable to get this to happen on my system.https://travis-ci.org/torproject/tor/jobs/403730172
It looks like all the tests pass, the only problem I can see is the mysterious core left over at the end. I'm unable to get this to happen on my system.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24804Run an opt-in process for relay operators to become fallbacks in 20182020-06-13T16:06:25ZteorRun an opt-in process for relay operators to become fallbacks in 2018This involves mailing tor-relays and asking if stable relay operators want to become fallbacks.This involves mailing tor-relays and asking if stable relay operators want to become fallbacks.Tor: 0.4.0.x-finalColin ChildsColin Childshttps://gitlab.torproject.org/legacy/trac/-/issues/24803Generate a new fallback list in 2018 and backport it to all supported versions2020-06-13T15:19:50ZteorGenerate a new fallback list in 2018 and backport it to all supported versionsThis is the actual list generation ticket.This is the actual list generation ticket.Tor: 0.2.9.x-finalColin ChildsColin Childshttps://gitlab.torproject.org/legacy/trac/-/issues/24786Rebuild the fallback list in 20182020-06-13T16:21:09ZteorRebuild the fallback list in 2018We need to rebuild the list of fallbacks in late 2018 or early 2019.
We usually do this when 25% or more go down.
(This is tracked in #tor-bots on IRC.)
Here are the instructions for running a rebuild:
https://trac.torproject.org/projec...We need to rebuild the list of fallbacks in late 2018 or early 2019.
We usually do this when 25% or more go down.
(This is tracked in #tor-bots on IRC.)
Here are the instructions for running a rebuild:
https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallbackDirectoryMirrorsTor: 0.4.0.x-final