Chutney issueshttps://gitlab.torproject.org/tpo/core/chutney/-/issues2020-07-23T20:28:31Zhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/21463Chutney creates keys directory for clients2020-07-23T20:28:31ZteorChutney creates keys directory for clientsBut clients don't ever use it.But clients don't ever use it.https://gitlab.torproject.org/tpo/core/chutney/-/issues/32972Chutney doesn't remove temporary files after processing warnings2020-06-27T13:18:35ZoparaChutney doesn't remove temporary files after processing warningsWhen the Chutney test-network script ends, it displays warnings from the tor logs. It summarizes/filters them in the `show_warnings()` function in `tools/warnings.sh`. This function creates two files with `LOGS=$(mktemp)` and `FILTERED_L...When the Chutney test-network script ends, it displays warnings from the tor logs. It summarizes/filters them in the `show_warnings()` function in `tools/warnings.sh`. This function creates two files with `LOGS=$(mktemp)` and `FILTERED_LOGS=$(mktemp)` but never deletes them when it's done.
The proposal is to add `rm "${LOGS}" "${FILTERED_LOGS}"` at the end of the function.https://gitlab.torproject.org/tpo/core/chutney/-/issues/29618Chutney doesn't use python3 if a "python2" binary exists, and fails if it use...2020-06-27T13:18:42ZNick MathewsonChutney doesn't use python3 if a "python2" binary exists, and fails if it uses python3 anyway.In the "chutney" shell script, the search list for python binaries is:
```
binaries="python2 python"
```
This means that even if python3 is installed as "python", chutney will use python2 instead.
This mistake has led us to accumulate ...In the "chutney" shell script, the search list for python binaries is:
```
binaries="python2 python"
```
This means that even if python3 is installed as "python", chutney will use python2 instead.
This mistake has led us to accumulate a bunch of python3 incompatibilities.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/33041Chutney error message says to use 'TOR_DIR' instead of 'CHUTNEY_TOR'2020-06-27T13:18:35ZoparaChutney error message says to use 'TOR_DIR' instead of 'CHUTNEY_TOR'When you attempt to run Chutney using a command like:
```
./chutney configure networks/basic
```
it will print the following error message if it cannot find `tor` or `tor-gencert`:
```
Cannot find the tor-gencert binary at 'tor-gencer...When you attempt to run Chutney using a command like:
```
./chutney configure networks/basic
```
it will print the following error message if it cannot find `tor` or `tor-gencert`:
```
Cannot find the tor-gencert binary at 'tor-gencert' for the command
line 'tor-gencert --create-identity-key --passphrase-fd 0 <snip>'.
Set the TOR_DIR environment variable to the directory containing
tor-gencert.
```
Chutney (the Python code) does not actually use this `TOR_DIR` environment variable (it's only used by `tools/test-network.sh` and related scripts). Instead the error message should say that the user should set the `CHUTNEY_TOR` and `CHUTNEY_TOR_GENCERT` environment variables.https://gitlab.torproject.org/tpo/core/chutney/-/issues/17631chutney fails on systems with python2, but no python2020-06-27T13:18:58Zteorchutney fails on systems with python2, but no pythonI forgot brackets when I rewrite the command checks.I forgot brackets when I rewrite the command checks.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/16902chutney fails to find python2 on stock OS X install2020-06-27T13:19:01Zteorchutney fails to find python2 on stock OS X installOS X Yosemite's /usr/bin/python is python 2.7.10, but OS X doesn't provide a python2 symlink (which chutney expects).
This causes chutney to fail out of the box on OS X.OS X Yosemite's /usr/bin/python is python 2.7.10, but OS X doesn't provide a python2 symlink (which chutney expects).
This causes chutney to fail out of the box on OS X.teorteorhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/16904chutney fails to work with python32020-06-27T13:19:01Zteorchutney fails to work with python3I thought we had this working at one stage, but maybe my recent changes broke it.I thought we had this working at one stage, but maybe my recent changes broke it.cypherpunkscypherpunkshttps://gitlab.torproject.org/tpo/core/chutney/-/issues/16386Chutney generates network with no bandwidth weights2020-07-23T21:07:50ZGeorge KadianakisChutney generates network with no bandwidth weightsHello,
when chutney makes a Tor network, it sets the following options in the dirauth torrc:
```
TestingDirAuthVoteExit *
TestingDirAuthVoteGuard *
```
which results in a network where all nodes are guards and exits.
This results in to...Hello,
when chutney makes a Tor network, it sets the following options in the dirauth torrc:
```
TestingDirAuthVoteExit *
TestingDirAuthVoteGuard *
```
which results in a network where all nodes are guards and exits.
This results in totally unbalanced bandwidths (0 guard bandwidth, 0 middle bandwidth, full guard+exit bandwidth) and authorities will not generate bandwidth weights:
```
[warn] Consensus with empty bandwidth: G=0 M=0 E=0 D=65770 T=65770
```
This is quite different from the real Tor network.
It would be great if chutney could assign Exit/Guard flag in a smarter way to only a few nodes, so that bandwidth can be allocated more widely.https://gitlab.torproject.org/tpo/core/chutney/-/issues/10764chutney has a non-obvious license2020-06-27T13:19:07ZRoger Dingledinechutney has a non-obvious licenseAt the top of some of the python files in Chutney is this text:
```
# Copyright 2011 Nick Mathewson, Michael Stone
# Copyright 2013 The Tor Project
#
# You may do anything with this work that copyright law would normally
# restrict, so...At the top of some of the python files in Chutney is this text:
```
# Copyright 2011 Nick Mathewson, Michael Stone
# Copyright 2013 The Tor Project
#
# You may do anything with this work that copyright law would normally
# restrict, so long as you retain the above notice(s) and this license
# in all redistributed copies and derived works. There is no warranty.
```
which some folks might recognize as the Tiny license.
But the work as a whole appears to have no license file. So e.g. tools/bootstrap-network.sh would sure look to be non open source software currently.
Can we add a license for the work as a whole?Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/23475Chutney logs a lot of "Failed to find node for hop #1 of our path"2020-06-27T13:18:48ZteorChutney logs a lot of "Failed to find node for hop #1 of our path"We need to hide this message using the ignore file.We need to hide this message using the ignore file.https://gitlab.torproject.org/tpo/core/chutney/-/issues/22224chutney mixed networks never test old clients or hidden services2020-06-27T13:18:50Zteorchutney mixed networks never test old clients or hidden servicesBecause they use the tags [b]cOLD and hOLD.
We can fix this by adding client and hidden_service flags to n._env, like the existing exit flag, and then tagging all the nodes in all the networks. (We might want to do this for authorities,...Because they use the tags [b]cOLD and hOLD.
We can fix this by adding client and hidden_service flags to n._env, like the existing exit flag, and then tagging all the nodes in all the networks. (We might want to do this for authorities, bridge relays, bridge clients, and any other nodes, if they don't already have a tag.)
We can then do a check that each node has at least one tag.
```
client_list = filter(lambda n:
n._env['tag'] == 'c' or n._env['tag'] == 'bc',
network._nodes)
exit_list = filter(lambda n:
('exit' in n._env.keys()) and n._env['exit'] == 1,
network._nodes)
hs_list = filter(lambda n:
n._env['tag'] == 'h',
network._nodes)
```teorteorhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/6753chutney needs to set AlternateBridgeAuthority too2020-06-27T13:19:08ZRoger Dingledinechutney needs to set AlternateBridgeAuthority tooSince git commit 21c6c8485 (to Tor), Tor won't start if TestingTorNetwork is on, AlternateDirAuthority is set, but AlternateBridgeAuthority is not.Since git commit 21c6c8485 (to Tor), Tor won't start if TestingTorNetwork is on, AlternateDirAuthority is set, but AlternateBridgeAuthority is not.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/34447Chutney networks need at least 3 AssumeReachable nodes.2020-06-27T13:18:29ZNick MathewsonChutney networks need at least 3 AssumeReachable nodes.Unless at least three nodes on a chutney network are AssumeReachable, the consensus as published will not have 3 descriptors in it. Without 3 descriptors in the initial consensus, relays won't be able to build self-testing circuits, dec...Unless at least three nodes on a chutney network are AssumeReachable, the consensus as published will not have 3 descriptors in it. Without 3 descriptors in the initial consensus, relays won't be able to build self-testing circuits, decide they are reachable, and publish their own descriptors... so they will never join the consensus.
Right now, this problem is masked by legacy/trac#34446, which means that we haven't actually disabled AssumeReachable as much as we think we have.Tor: 0.4.5.x-finalhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/30064Chutney often fails because Tor hasn't bootstrapped yet2020-06-27T13:18:40ZteorChutney often fails because Tor hasn't bootstrapped yetTravis appears to be under heavy load right now, so we're getting about one bootstrap failure per pull request:
https://travis-ci.org/torproject/chutney/jobs/517006783
https://travis-ci.org/torproject/chutney/jobs/516995533
There's two ...Travis appears to be under heavy load right now, so we're getting about one bootstrap failure per pull request:
https://travis-ci.org/torproject/chutney/jobs/517006783
https://travis-ci.org/torproject/chutney/jobs/516995533
There's two ways to fix this issue:
1. allow 120 seconds for bootstrap
2. make the network run with 10 second consensus intervals
Option 1 is easy.
Option 2 might lead to some instability, but it's worth trying.teorteorhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/18882chutney reads the system torrc when generating the router key2020-06-27T13:18:57Zanonymchutney reads the system torrc when generating the router keyThis can easily be demonstrated by adding an invalid option to `/etc/tor/torrc` and then running `chutney configure`. This feels wrong, and will fail if you run a hidden service on the system-wide Tor instance.This can easily be demonstrated by adding an invalid option to `/etc/tor/torrc` and then running `chutney configure`. This feels wrong, and will fail if you run a hidden service on the system-wide Tor instance.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/17622chutney rendezvous single onion services templates & network2020-06-27T13:18:59Zteorchutney rendezvous single onion services templates & network~~Please merge the feature-17178-rsos branch in https://github.com/teor2345/chutney.git~~
I'll make this happen when legacy/trac#17178 closes.~~Please merge the feature-17178-rsos branch in https://github.com/teor2345/chutney.git~~
I'll make this happen when legacy/trac#17178 closes.teorteorhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/20036Chutney should allow single onion and tor2web modes on any HS / client2020-07-23T20:23:51ZteorChutney should allow single onion and tor2web modes on any HS / clientAt the moment, chutney users have to specifically configure single onion mode and tor2web mode.
It would be nice to allow any chutney net to be run with its hidden services in single onion mode, perhaps using config options that are con...At the moment, chutney users have to specifically configure single onion mode and tor2web mode.
It would be nice to allow any chutney net to be run with its hidden services in single onion mode, perhaps using config options that are conditional on environmental variables.
This would be harder with tor2web, because we'd need a separate tor binary as well. And it might not be worth the effort if tor2web isn't part of next-generation hidden services.https://gitlab.torproject.org/tpo/core/chutney/-/issues/22132Chutney should avoid waiting for set times: wait for conditions instead2020-06-27T13:18:50ZteorChutney should avoid waiting for set times: wait for conditions insteadChutney has a few places where it waits for hard-coded amounts of time. It should wait for events to happen instead.
For example:
* re-trying connections (legacy/trac#22131)
* waiting for bootstrap
* anywhere else we use sleep()Chutney has a few places where it waits for hard-coded amounts of time. It should wait for events to happen instead.
For example:
* re-trying connections (legacy/trac#22131)
* waiting for bootstrap
* anywhere else we use sleep()Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/22131chutney should cope better when sockets are closed2020-06-27T13:18:51Zteorchutney should cope better when sockets are closedAt the moment, it just re-tries the connection after a few seconds, then gives up after a few tries. We should be smarter than that.At the moment, it just re-tries the connection after a few seconds, then gives up after a few tries. We should be smarter than that.teorteorhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/21371chutney should display bug warnings logged by tor2020-06-27T13:18:53Zteorchutney should display bug warnings logged by torWhile chutney runs, it should echo any bug messages that any of its running tor instances logs.
We could write a script in tools/ that logs all bug messages until tor exits. Or we could just run a script when chutney finishes.
Perhaps ...While chutney runs, it should echo any bug messages that any of its running tor instances logs.
We could write a script in tools/ that logs all bug messages until tor exits. Or we could just run a script when chutney finishes.
Perhaps we should log unexpected warnings as well.teorteor