Chutney issueshttps://gitlab.torproject.org/tpo/core/chutney/-/issues2022-02-07T19:32:14Zhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/23472Add support for ed25519 authorities and bridges to chutney2022-02-07T19:32:14ZteorAdd support for ed25519 authorities and bridges to chutneyThere is no fallback support in chutney yet.There is no fallback support in chutney yet.https://gitlab.torproject.org/tpo/core/chutney/-/issues/33598chutney does not fail on some SOCKS errors2022-02-07T19:32:13Zteorchutney does not fail on some SOCKS errorsWhen tor can't make a connection, and sends back a SOCKS error, chutney keeps on rapidly sending SOCKS requests. Instead, chutney should fail.
I think we introduced this bug when we started using asyncore.
I have worked around the bug...When tor can't make a connection, and sends back a SOCKS error, chutney keeps on rapidly sending SOCKS requests. Instead, chutney should fail.
I think we introduced this bug when we started using asyncore.
I have worked around the bug using a 5 second asyncore timeout, but we should come up with a permanent fix.
I think nickm might be able to help with this issue, because he wrote that code.https://gitlab.torproject.org/tpo/core/chutney/-/issues/17282Chutney could use a HOWTO for writing new test cases, network tests, etc2022-02-07T19:32:12ZNick MathewsonChutney could use a HOWTO for writing new test cases, network tests, etcDue April 2016Due April 2016https://gitlab.torproject.org/tpo/core/chutney/-/issues/17712Add chutney support for FallbackDirs2022-02-07T19:32:11ZteorAdd chutney support for FallbackDirsJust like chutney adds DirAuthority lines, it should add a FallbackDir line for each relay / exit. This will allow us to test legacy/trac#15775 / legacy/trac#4483.Just like chutney adds DirAuthority lines, it should add a FallbackDir line for each relay / exit. This will allow us to test legacy/trac#15775 / legacy/trac#4483.https://gitlab.torproject.org/tpo/core/chutney/-/issues/22815Chutney tests for IPv6 only bridges2020-08-14T12:40:22ZteorChutney tests for IPv6 only bridgesWe need an IPv6-only bridge test, so we can test legacy/trac#4847 and make sure there are no regressions.We need an IPv6-only bridge test, so we can test legacy/trac#4847 and make sure there are no regressions.https://gitlab.torproject.org/tpo/core/chutney/-/issues/34037Make chutney check tor's logs for reachability self-test success2020-10-29T15:13:54ZteorMake chutney check tor's logs for reachability self-test successThis ticket is an alternative to legacy/trac#33582 or legacy/trac#33222.
Instead of fixing bridge descriptor uploads, we can check bridge logs to make sure that reachability self-tests have succeeded.
For consistency, we should also do...This ticket is an alternative to legacy/trac#33582 or legacy/trac#33222.
Instead of fixing bridge descriptor uploads, we can check bridge logs to make sure that reachability self-tests have succeeded.
For consistency, we should also do the same checks for relays.
We can only do these tests on authorities, relays, and bridges that are configured with `AssumeReachable 0`. Chutney's current defaults are:
* directory authorities: 1
* bridge authorities: 1
* relays: 0
* bridges: 0
* clients: clients never perform reachability self-tests
Some custom chutney networks may set `AssumeReachable 1` for relays and bridges. So we should make it easy for them to disable these checks.https://gitlab.torproject.org/tpo/core/chutney/-/issues/22360chutney's --quiet mode could be quieter2021-11-15T16:55:19Zteorchutney's --quiet mode could be quieterIt would be nice to get it down to just a few lines per run.It would be nice to get it down to just a few lines per run.https://gitlab.torproject.org/tpo/core/chutney/-/issues/19019When chutney fails because of ports, tell the user2021-11-15T16:53:51ZteorWhen chutney fails because of ports, tell the userChutney can fail because old tors (or other processes) are already occupying the ports it wants to use.
We should make this more obvious, so developers don't blame tor code.Chutney can fail because old tors (or other processes) are already occupying the ports it wants to use.
We should make this more obvious, so developers don't blame tor code.https://gitlab.torproject.org/tpo/core/chutney/-/issues/26804Create a valid bwfile using a chutney script2021-11-15T16:55:24ZteorCreate a valid bwfile using a chutney scriptWe should write a small chutney script to make a valid bwfile, and put it in the scripts/ directory.We should write a small chutney script to make a valid bwfile, and put it in the scripts/ directory.https://gitlab.torproject.org/tpo/core/chutney/-/issues/26164Create HS network in chutney with client-auth enabled2021-11-15T16:55:23ZGeorge KadianakisCreate HS network in chutney with client-auth enabledTo improve our HS integration tests as part of `make test-network-all` we should make a network template similar to `hs` etc. where the HS is client-auth-protected, and the client needs to use the client auth token to submit data.
This ...To improve our HS integration tests as part of `make test-network-all` we should make a network template similar to `hs` etc. where the HS is client-auth-protected, and the client needs to use the client auth token to submit data.
This might be a bit of a hurdle to setup, since we would need to first start up the HS, so that it generates the client auth tokens, and then we would need to hax the client torrc to make it happen.https://gitlab.torproject.org/tpo/core/chutney/-/issues/21543Make chutney use a different base port2021-11-15T16:54:15ZteorMake chutney use a different base portI often want to run multiple chutney networks at once.
It would help if I could specify a different base port (for example, 10000) that would be added to all ports used by chutney.I often want to run multiple chutney networks at once.
It would help if I could specify a different base port (for example, 10000) that would be added to all ports used by chutney.https://gitlab.torproject.org/tpo/core/chutney/-/issues/20343Write a setup.py for chutney2021-11-15T16:54:11ZdawuudWrite a setup.py for chutney
I want to use the chutney API for various projects. It would make it much easier to use if it had a proper setup.py
I want to use the chutney API for various projects. It would make it much easier to use if it had a proper setup.pyhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/22135chutney should use python's loggging module2021-11-15T16:54:17ZNick Mathewsonchutney should use python's loggging moduleOur current debug() function is a silly kludge, and our print() statements are not much better. Python has built-in logging in its standard library, and perhaps we should just use that instead.Our current debug() function is a silly kludge, and our print() statements are not much better. Python has built-in logging in its standard library, and perhaps we should just use that instead.https://gitlab.torproject.org/tpo/core/chutney/-/issues/20655Run the chutney "mixed" network tests in multiple ways2021-11-15T16:54:13ZNick MathewsonRun the chutney "mixed" network tests in multiple waysWhile working on ed25519 handshake thigns, I found that the "mixed" chutney network test was often inadequate for my needs:
* I wanted to try testing with clients and relays that are very old, while keeping the authorities up-to-date...While working on ed25519 handshake thigns, I found that the "mixed" chutney network test was often inadequate for my needs:
* I wanted to try testing with clients and relays that are very old, while keeping the authorities up-to-date.
* I wanted `make test-network-all` to run the "mixed" test multiple times, with multiple older Tor instances.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/20068Chutney tests for IPv6-only bridge clients2021-11-15T16:54:04ZteorChutney tests for IPv6-only bridge clientsI think this is working already, but we should check that chutney bridge clients are using IPv6, and not falling back to IPv4.I think this is working already, but we should check that chutney bridge clients are using IPv6, and not falling back to IPv4.https://gitlab.torproject.org/tpo/core/chutney/-/issues/20142chutney IPv6 HiddenServicePort tests2021-11-15T16:54:09Zteorchutney IPv6 HiddenServicePort testsWe should test legacy/trac#18357 once it's implemented to make sure we don't accidentally break it.
This requires teaching chutney to listen on IPv6.We should test legacy/trac#18357 once it's implemented to make sure we don't accidentally break it.
This requires teaching chutney to listen on IPv6.https://gitlab.torproject.org/tpo/core/chutney/-/issues/40006Chutney's logic for bootstrap detection has gotten pretty complex2021-09-16T14:47:26ZNick MathewsonChutney's logic for bootstrap detection has gotten pretty complexI have a hard time understanding the code that checks whether directory information is bootstrapped. I think it might be time to refactor it. It all seems to get called via `getNodeDirInfoStatus()`, but after that it gets pretty hairy.I have a hard time understanding the code that checks whether directory information is bootstrapped. I think it might be time to refactor it. It all seems to get called via `getNodeDirInfoStatus()`, but after that it gets pretty hairy.https://gitlab.torproject.org/tpo/core/chutney/-/issues/11115use argparse for chutney when debian squeeze hits end-of-life2021-11-15T16:52:43ZTracuse argparse for chutney when debian squeeze hits end-of-lifeAs discussed in legacy/trac#10933, this is a reminder ticket for using argparse module to parse arguments in chutney. Currently people might still have Python 2.6 in the system so we will wait until support for debian squeeze ends (2014-...As discussed in legacy/trac#10933, this is a reminder ticket for using argparse module to parse arguments in chutney. Currently people might still have Python 2.6 in the system so we will wait until support for debian squeeze ends (2014-05-04?).
**Trac**:
**Username**: dave2008https://gitlab.torproject.org/tpo/core/chutney/-/issues/16806Chutney/integration tests for DNS server/client functionality2021-11-15T16:52:57ZNick MathewsonChutney/integration tests for DNS server/client functionalityhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/20067Chutney should verify IPv6 SOCKSPorts2021-11-15T16:53:57ZteorChutney should verify IPv6 SOCKSPortsChutney will soon verify using client to relay IPv6, but verify only sends traffic to and from tor over IPv4.
We need to test the following:
* IPv6 SOCKSPorts,
* IPv4 and IPv6 SOCKSPorts with IPv6Traffic, and
* ~~IPv6 Exits~~
* Hidden S...Chutney will soon verify using client to relay IPv6, but verify only sends traffic to and from tor over IPv4.
We need to test the following:
* IPv6 SOCKSPorts,
* IPv4 and IPv6 SOCKSPorts with IPv6Traffic, and
* ~~IPv6 Exits~~
* Hidden Services connecting to CHUTNEY_LISTEN_ADDRESS_V6:LISTEN_PORThttps://gitlab.torproject.org/tpo/core/chutney/-/issues/16807Framework for Clients And Relays that Do Bad Things2021-11-15T16:53:02ZNick MathewsonFramework for Clients And Relays that Do Bad ThingsWe need a simple testing framework that pretends to be a client or relay and then breaks the Tor protocols. This won't be trivial, but it will help us make sure that a lot of our countermeasures actually work.We need a simple testing framework that pretends to be a client or relay and then breaks the Tor protocols. This won't be trivial, but it will help us make sure that a lot of our countermeasures actually work.https://gitlab.torproject.org/tpo/core/chutney/-/issues/19573Use fixedresolver.py from dnslib in chutney2021-11-15T16:53:56ZteorUse fixedresolver.py from dnslib in chutneyTor Exits in chuntey run DNS checks to external addresses.
This is one of the things stopping chutney from working when there is no DNS.
We could redirect DNS queries to fixedresolver.py from Python's dnslib, and that would make sure DN...Tor Exits in chuntey run DNS checks to external addresses.
This is one of the things stopping chutney from working when there is no DNS.
We could redirect DNS queries to fixedresolver.py from Python's dnslib, and that would make sure DNS would all run locally.
(Although we might have to reply with a few different addresses somehow, because tor gets suspicious if every address from DNS is the same.)https://gitlab.torproject.org/tpo/core/chutney/-/issues/30305Chutney should give better failure info when its Tor has --disable-module-dir...2022-02-07T19:30:50ZNick MathewsonChutney should give better failure info when its Tor has --disable-module-dirauthIf Tor can't be a directory authority, you can't have a private network, so chutney won't work. But chutney doesn't notice, and it tries to run anyway, instead of telling you what the problem is.
This just consumed 20 minutes of my mor...If Tor can't be a directory authority, you can't have a private network, so chutney won't work. But chutney doesn't notice, and it tries to run anyway, instead of telling you what the problem is.
This just consumed 20 minutes of my morning. Maybe we can fix it along with our other plans to give chutney a "will this network work" command.https://gitlab.torproject.org/tpo/core/chutney/-/issues/30720Use test-network.sh for the examples in Chutney's README2022-02-07T19:30:52ZteorUse test-network.sh for the examples in Chutney's READMEChutney's README is confusing, because we provide examples that assume you have already started a chutney network.
Instead, we should provide test-network.sh command lines.Chutney's README is confusing, because we provide examples that assume you have already started a chutney network.
Instead, we should provide test-network.sh command lines.https://gitlab.torproject.org/tpo/core/chutney/-/issues/30884Test pluggable transports in chutney's CI2022-02-07T19:30:54ZteorTest pluggable transports in chutney's CIWe added PT support to chutney in legacy/trac#29024, now we need to make sure it keeps on working.We added PT support to chutney in legacy/trac#29024, now we need to make sure it keeps on working.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/30182IPv6 Exits succeed on Travis Linux, but Travis Linux doesn't support IPv62022-02-07T19:30:49ZteorIPv6 Exits succeed on Travis Linux, but Travis Linux doesn't support IPv6So maybe we're not actually testing IPv6 traffic?
Here are the symptoms of this bug:
* Travis Linux VMs don't have IPv6
* Travis macOS VMs have IPv6
* Most IPv6 tests succeed on Travis macOS, but fail on Travis Linux
* The IPv6 exit tes...So maybe we're not actually testing IPv6 traffic?
Here are the symptoms of this bug:
* Travis Linux VMs don't have IPv6
* Travis macOS VMs have IPv6
* Most IPv6 tests succeed on Travis macOS, but fail on Travis Linux
* The IPv6 exit test succeeds on Travis Linux, but it should nothttps://gitlab.torproject.org/tpo/core/chutney/-/issues/30553chutney: Bump the data size transmitted with the verify command2022-02-07T19:30:51ZDavid Gouletdgoulet@torproject.orgchutney: Bump the data size transmitted with the verify commandWith legacy/trac#29263, the SENDMEs can be tested properly but as long as the circuits has more than 500KB on it (which is roughly the 512 byte data cell size times the circuit window start of 1000).
To be safe, having let say 600KB of ...With legacy/trac#29263, the SENDMEs can be tested properly but as long as the circuits has more than 500KB on it (which is roughly the 512 byte data cell size times the circuit window start of 1000).
To be safe, having let say 600KB of data transmitted with `chutney verify` would be a sure test of the circuit flow control feature. And it doesn't take much more time at all from what we have right now.
On slow systems like arm64 for instance, there could be an argument to bump the SOCKS timeout from 3 to let say 5 or 10 seconds in order to avoid chutney killing the connections before 600KB went through the circuit.https://gitlab.torproject.org/tpo/core/chutney/-/issues/30153Add a command to chutney and test-network.sh that prints the default option v...2022-02-07T19:30:48ZteorAdd a command to chutney and test-network.sh that prints the default option valuesFollow up to legacy/trac#30059.
We should make a chutney command and a test-network.sh command that prints their default option values.
Maybe we could even import the defaults from chutney into test-network.sh.
Then we can update the ...Follow up to legacy/trac#30059.
We should make a chutney command and a test-network.sh command that prints their default option values.
Maybe we could even import the defaults from chutney into test-network.sh.
Then we can update the README to say:
"For the default values of these options, run..."https://gitlab.torproject.org/tpo/core/chutney/-/issues/28228In Chutney's debug mode, dump all tor warning logs to stderr as soon as they ...2022-02-07T19:30:46ZteorIn Chutney's debug mode, dump all tor warning logs to stderr as soon as they appearCurrently we wait until the end, which isn't ideal.Currently we wait until the end, which isn't ideal.https://gitlab.torproject.org/tpo/core/chutney/-/issues/30886Add pluggable transport support to chutney's tools/test-network.sh2022-02-07T19:31:25ZteorAdd pluggable transport support to chutney's tools/test-network.shWe have basic PT support in chutney, but we need a nicer interface to it.We have basic PT support in chutney, but we need a nicer interface to it.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/31639When Travis updates the homebrew cache in their images, stop updating it in ....2022-02-07T19:31:27ZteorWhen Travis updates the homebrew cache in their images, stop updating it in .travis.ymlIn legacy/trac#30928, we added a homebrew update to .travis.yml for shellcheck.
legacy/trac#30279 also uses an updated tor for the IPv6 v3 single onion service job.
This ticket removes that update.In legacy/trac#30928, we added a homebrew update to .travis.yml for shellcheck.
legacy/trac#30279 also uses an updated tor for the IPv6 v3 single onion service job.
This ticket removes that update.https://gitlab.torproject.org/tpo/core/chutney/-/issues/40017Chutney failure when CHUTNEY_DATA_BYTES is large2022-02-07T19:31:44ZAlexander Færøyahf@torproject.orgChutney failure when CHUTNEY_DATA_BYTES is largeMike ran into an issue today where Chutney fails with `all_done` being `False` (see status in `DEBUG: Done with run(); all_done == False and failure_count == 0`). The issue seemed to be related to having set the env variable `CHUTNEY_DAT...Mike ran into an issue today where Chutney fails with `all_done` being `False` (see status in `DEBUG: Done with run(); all_done == False and failure_count == 0`). The issue seemed to be related to having set the env variable `CHUTNEY_DATA_BYTES` to a large value (in this case: 104857600)https://gitlab.torproject.org/tpo/core/chutney/-/issues/40016Improve a way to check that a network has bootstrapped2022-02-07T19:31:43ZjugaImprove a way to check that a network has bootstrappedFor integration tests is very useful to know programmatically when a network has bootstrapped before start using it.
I used to use a similar script to https://github.com/TheTorProject/bwscanner/blob/develop/test/scripts/install-chutney....For integration tests is very useful to know programmatically when a network has bootstrapped before start using it.
I used to use a similar script to https://github.com/TheTorProject/bwscanner/blob/develop/test/scripts/install-chutney.sh#L15, which uses `verify` command but that stop working (don't have now the trace).
Then i realized that there was `wait_for_bootstrap`, but in Gitlab CI, sometimes there're relays missing, using the client and stem.
@nickm has suggested `status`, but it'd need more work to parse its exit.https://gitlab.torproject.org/tpo/core/chutney/-/issues/40013Template relay-non-exit.tmpl does generate exits2022-03-17T11:19:57ZjugaTemplate relay-non-exit.tmpl does generate exitsI assume this is the template to use to generate non-exits, if not this is probably not an issue.
The network `hs-v2-min` uses this template.
I start the network and try to obtain the relays without the EXIT flag:
```
from stem import F...I assume this is the template to use to generate non-exits, if not this is probably not an issue.
The network `hs-v2-min` uses this template.
I start the network and try to obtain the relays without the EXIT flag:
```
from stem import Flag
from stem.control import Controller
c = Controller.from_port(port=8000)
c.authenticate()
cons = c.get_network_statuses()
[(rs.nickname, rs.flags) for rs in cons if Flag.EXIT not in rs.flags]
>>> []
```
But all relays have the exit flag.
The generated `torrc` has `ExitRelay 0`, so i guess that it must be some other option that is making the relays to be flagged as exits?
Is there other way to generate non-exits?https://gitlab.torproject.org/tpo/core/chutney/-/issues/33825Make Environ handle "in" and "get()" like a dict2022-02-07T19:31:36ZteorMake Environ handle "in" and "get()" like a dictSome standard Python dict code doesn't work on chutney's Environ class:
```
is_in_env = 'foo' in self._env
value_or_none = self._env.get('foo')
```
"in" should return a boolean, and "get()" should return the value (or None).
But instea...Some standard Python dict code doesn't work on chutney's Environ class:
```
is_in_env = 'foo' in self._env
value_or_none = self._env.get('foo')
```
"in" should return a boolean, and "get()" should return the value (or None).
But instead, when the key is missing, sometimes they throw a KeyError. (It seems to happen in certain contexts, but not others.)
We should work out if Environ is missing some of the required dict implementation functions. Or if there is some issue with Environ's lookup code.
Then we should implement unit tests, to make sure we don't break Environ in future.https://gitlab.torproject.org/tpo/core/chutney/-/issues/17011chutney doesn't verify using IPv6 addresses2022-02-07T19:31:40Zteorchutney doesn't verify using IPv6 addressesEven when chutney is using IPv6 exits, it doesn't give clients an IPv6 address to connect to when verifying.
When chutney is using IPv6 bridges, I don't know if it gives their IPv6 address to bridge clients.
This is a significant cover...Even when chutney is using IPv6 exits, it doesn't give clients an IPv6 address to connect to when verifying.
When chutney is using IPv6 bridges, I don't know if it gives their IPv6 address to bridge clients.
This is a significant coverage gap that I think is easily fixed by slight modifications to the chutney templating and verification code.https://gitlab.torproject.org/tpo/core/chutney/-/issues/40011Chutney: remove support for Tor's pre-0.3.5 directory structure2022-02-07T19:31:40ZteorChutney: remove support for Tor's pre-0.3.5 directory structuretest-network*.sh still supports Tor's pre-0.3.5 directory structure. And there may be other Tor 0.2.9 code in chutney.
Now that 0.2.9 is unsupported, we can remove this code.
We should be able to find it by grepping for "0.2.9", "029",...test-network*.sh still supports Tor's pre-0.3.5 directory structure. And there may be other Tor 0.2.9 code in chutney.
Now that 0.2.9 is unsupported, we can remove this code.
We should be able to find it by grepping for "0.2.9", "029", "src/or", "src/common", "0.3.5", or "035".https://gitlab.torproject.org/tpo/core/chutney/-/issues/40010Create a chutney network with a single authority, and make sure it bootstraps2022-02-07T19:31:38ZteorCreate a chutney network with a single authority, and make sure it bootstrapsDepends on legacy/trac#28203, which logs bootstrap progress.
It looks like there are a lot of race conditions in chutney and tor. We can eliminate most of these race conditions by launching a single authority, and seeing if it bootstrap...Depends on legacy/trac#28203, which logs bootstrap progress.
It looks like there are a lot of race conditions in chutney and tor. We can eliminate most of these race conditions by launching a single authority, and seeing if it bootstraps reliably. Then we can narrow down the source of chutney's instability.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/40009Add a stub geoip file for chutney networks2022-02-07T19:31:37ZNick MathewsonAdd a stub geoip file for chutney networksFor Chutney networks, it would be handy to have geoip files for IPv4 and IPv6. Since all chutney relays are on localhost in our networks, the geoip files should map localhost to a make-believe country code.For Chutney networks, it would be handy to have geoip files for IPv4 and IPv6. Since all chutney relays are on localhost in our networks, the geoip files should map localhost to a make-believe country code.https://gitlab.torproject.org/tpo/core/chutney/-/issues/33677Stop waiting a set time for onion service descriptors2022-02-07T19:31:34ZteorStop waiting a set time for onion service descriptorsAfter we make chutney check for onion service descriptors in legacy/trac#33609, we can stop waiting a set time for onion service descriptors to download.
First, set HS_WAIT_FOR_UNCHECKED_DIR_INFO to 0:
https://github.com/torproject/chut...After we make chutney check for onion service descriptors in legacy/trac#33609, we can stop waiting a set time for onion service descriptors to download.
First, set HS_WAIT_FOR_UNCHECKED_DIR_INFO to 0:
https://github.com/torproject/chutney/blob/master/lib/chutney/TorNet.py#L953
Then check that `make test-network-all` still passes on:
* Tor master,
* Tor maint-0.3.5
Then check that chutney's CI still passes.
If all those tests pass, we can remove all the code that uses HS_WAIT_FOR_UNCHECKED_DIR_INFO:
* remove HS_WAIT_FOR_UNCHECKED_DIR_INFO
* remove getUncheckedDirInfoWaitTime()
* remove all the variables, code, and comments that depend on getUncheckedDirInfoWaitTime()
* https://github.com/torproject/chutney/blob/master/lib/chutney/TorNet.py#L2226
* https://github.com/torproject/chutney/blob/master/lib/chutney/TorNet.py#L2266https://gitlab.torproject.org/tpo/core/chutney/-/issues/31833Make chutney fail if Tor logs a bug warning2022-02-07T19:31:30ZteorMake chutney fail if Tor logs a bug warningWe've missed bug warnings in our CI, because chutney succeeds even if Tor logs a bug warning.
For example legacy/trac#31793.We've missed bug warnings in our CI, because chutney succeeds even if Tor logs a bug warning.
For example legacy/trac#31793.https://gitlab.torproject.org/tpo/core/chutney/-/issues/25157Chutney should set the same consensus parameters as the public network2022-02-07T19:30:45ZteorChutney should set the same consensus parameters as the public networkOtherwise, some of the code that runs on the public network won't get tested very well before we release it.Otherwise, some of the code that runs on the public network won't get tested very well before we release it.https://gitlab.torproject.org/tpo/core/chutney/-/issues/40020Not found error2022-07-25T03:24:47ZPulkit ChandelNot found errorFileNotFoundError: [Errno 2] No such file or directory: '/home/eict/chutney/net/nodes.1657278323/006r/torrc'
</pre>
Why am I Getting this error. The file 006r was never made when I executed tor chutney command, then why is it looking for...FileNotFoundError: [Errno 2] No such file or directory: '/home/eict/chutney/net/nodes.1657278323/006r/torrc'
</pre>
Why am I Getting this error. The file 006r was never made when I executed tor chutney command, then why is it looking for it.And how to solve ithttps://gitlab.torproject.org/tpo/core/chutney/-/issues/40021cgitb is deprecated2023-04-12T14:42:09ZNick Mathewsoncgitb is deprecatedWe use the cgitb module to generate nice tracebacks. But it seems that it's been deprecated for ages, and will soon go away in the next version of python3. We should remove or replace it.We use the cgitb module to generate nice tracebacks. But it seems that it's been deprecated for ages, and will soon go away in the next version of python3. We should remove or replace it.