Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:48:09Zhttps://gitlab.torproject.org/legacy/trac/-/issues/16808High coverage on connection_edge, addressmap2020-06-13T14:48:09ZNick MathewsonHigh coverage on connection_edge, addressmapThese functions get more than their share of bugs, and aren't very well reached by our current tests. We can use integration and unit tests for these.These functions get more than their share of bugs, and aren't very well reached by our current tests. We can use integration and unit tests for these.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/16805Improve unit-test coverage on old and/or pure-ish functions/modules in src/or2020-06-13T14:48:08ZNick MathewsonImprove unit-test coverage on old and/or pure-ish functions/modules in src/orThese files have the most old code in src/or right now, and they have a lot of functions that are mostly pure-ish functions. Let's call these low-hanging fruit.
```
routerparse.c.gcov 717 1620 69.32
routerlist.c.gcov 1496 588 28.21
node...These files have the most old code in src/or right now, and they have a lot of functions that are mostly pure-ish functions. Let's call these low-hanging fruit.
```
routerparse.c.gcov 717 1620 69.32
routerlist.c.gcov 1496 588 28.21
nodelist.c.gcov 503 165 24.70
rendcache.c.gcov 332 1 0.30
networkstatus.c.gcov 681 144 17.45
policies.c.gcov 244 506 67.47
rephist.c.gcov 931 278 22.99
buffers.c.gcov 361 506 58.36
```Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/16801Increase torgzip coverage as high as possible2020-06-13T14:48:07ZNick MathewsonIncrease torgzip coverage as high as possibleWe've actually had bugs in this one that caused needless bandwidth wastage. (eg #11824 and #11787.) Let's see if there are any more!
```
x/torgzip.c.gcov 88 136 60.71
```We've actually had bugs in this one that caused needless bandwidth wastage. (eg #11824 and #11787.) Let's see if there are any more!
```
x/torgzip.c.gcov 88 136 60.71
```Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/16799Raise utility testing over 95%2020-06-13T14:48:06ZNick MathewsonRaise utility testing over 95%These modules perform utility functionality that we should be able to get to a very high testing coverage rate.
```
x/memarea.c.gcov 20 85 80.95
x/util.c.gcov 484 1263 72.30
x/util_format.c.gcov 11 183 94.33
x/workqueue.c.gcov 34 117 77...These modules perform utility functionality that we should be able to get to a very high testing coverage rate.
```
x/memarea.c.gcov 20 85 80.95
x/util.c.gcov 484 1263 72.30
x/util_format.c.gcov 11 183 94.33
x/workqueue.c.gcov 34 117 77.48
x/address.c.gcov 77 595 88.54
x/log.c.gcov 274 274 50.00
```
(In the case of one or two of these, they might be actually compatibility stuff. In which case, compatibility stuff should move into new compat_* modules to be considered under #16798)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/16795Process-related utility code should have unit test coverage over 95%2020-06-13T14:48:04ZNick MathewsonProcess-related utility code should have unit test coverage over 95%```
x/procmon.c.gcov 45 0 0.00
x/util_process.c.gcov 5 33 86.84
``````
x/procmon.c.gcov 45 0 0.00
x/util_process.c.gcov 5 33 86.84
```Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/16791All modules in src/common should have 90-95%+ unit test coverage2020-06-13T14:48:01ZNick MathewsonAll modules in src/common should have 90-95%+ unit test coverageIt's a dirty shame to have anything in src/common that isn't really deeply covered by our unit tests, since src/common is supposed to be full of stuff that's _easy_ to test.
As of 2015-08-13, here's what's problematic (running "make che...It's a dirty shame to have anything in src/common that isn't really deeply covered by our unit tests, since src/common is supposed to be full of stuff that's _easy_ to test.
As of 2015-08-13, here's what's problematic (running "make check") on OSX, sorted by percentage of lines covered.
```
x/procmon.c.gcov 45 0 0.00
x/sandbox.c.gcov 9 0 0.00
x/compat_libevent.c.gcov 92 32 25.81
x/tortls.c.gcov 593 355 37.45
x/log.c.gcov 274 274 50.00
x/compat_threads.c.gcov 48 51 51.52
x/compat.c.gcov 360 426 54.20
x/torgzip.c.gcov 88 136 60.71
x/util.c.gcov 484 1263 72.30
x/compat_pthreads.c.gcov 22 72 76.60
x/workqueue.c.gcov 34 117 77.48
x/crypto.c.gcov 204 738 78.34
x/memarea.c.gcov 20 85 80.95
x/backtrace.c.gcov 9 42 82.35
x/crypto_ed25519.c.gcov 17 95 84.82
x/util_process.c.gcov 5 33 86.84
x/address.c.gcov 77 595 88.54
x/crypto_curve25519.c.gcov 8 74 90.24
x/crypto_s2k.c.gcov 14 152 91.57
x/util_format.c.gcov 11 183 94.33
x/crypto_format.c.gcov 5 95 95.00
x/container.c.gcov 15 390 96.30
x/crypto_pwbox.c.gcov 2 59 96.72
x/di_ops.c.gcov 1 37 97.37
x/aes.c.gcov 0 17 100.00
```Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/16698Split directory_handle_command_get into per-command functions2020-06-13T14:47:45ZNick MathewsonSplit directory_handle_command_get into per-command functionsTor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/15434Tor dies if you send it a HUP before it read its config, and doesn't take PTs...2020-06-13T14:44:35ZTvdWTor dies if you send it a HUP before it read its config, and doesn't take PTs with itWhen sending tor a HUP before it has read its config, it will die, without killing its PTs. Starting tor again will then result in more PT crashes, as the ports will already be used by previous instances.
```
10149 ? Sl 0:00 ...When sending tor a HUP before it has read its config, it will die, without killing its PTs. Starting tor again will then result in more PT crashes, as the ports will already be used by previous instances.
```
10149 ? Sl 0:00 /usr/bin/obfs4proxy managed
10581 ? Sl 0:01 /usr/bin/tor -f /etc/tor/torrc-node1
10582 ? S 0:00 \_ /usr/bin/python /usr/bin/obfsproxy managed
10583 ? Z 0:00 \_ [obfs4proxy] <defunct>
10584 ? S 0:00 \_ /usr/bin/python /usr/bin/fteproxy --managed --mode server
```Tor: 0.2.7.x-finalRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/14164Controller method to get our own descriptor2020-06-13T14:41:41ZtoralfController method to get our own descriptorI'm wondering why this pythin snippet
```
def main():
ControlPort = 9051
ProcessName = 'tor'
with Controller.from_port(port = ControlPort) as controller:
controller.authenticate()
#print " Tor version %s" % controller.get_...I'm wondering why this pythin snippet
```
def main():
ControlPort = 9051
ProcessName = 'tor'
with Controller.from_port(port = ControlPort) as controller:
controller.authenticate()
#print " Tor version %s" % controller.get_version()
try:
desc = controller.get_microdescriptor()
print " flags : %s" % desc.flags()
print " measured bandwidth : %i" % desc.measured()
except Exception as exc:
print exc
#pass
```
gives
```
Tor was unable to provide the descriptor for 'F1BE15429B3CE696D6807F4D4A58B1BFEC45C822'
```
Does this means that stems asks tor and tor doesn't know itself ?Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/13753Validate is_canonical more thoroughly2020-06-13T14:40:17ZNick MathewsonValidate is_canonical more thoroughlyWe use is_canonical to tell whether we should extend a circuit over a channel... but we should also double-check it as we are extending that circuit, to make sure we didn't mess up.
Also, we should audit the code that sets is_canonical.We use is_canonical to tell whether we should extend a circuit over a channel... but we should also double-check it as we are extending that circuit, to make sure we didn't mess up.
Also, we should audit the code that sets is_canonical.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/9729Make bridges publish additional ORPort addresses in their descriptor2020-06-13T14:31:56ZTracMake bridges publish additional ORPort addresses in their descriptorI run Tor 0.2.4.17-rc as a bridge configured with multiple IPv4 addresses and one ORPort line for each, like so:
ORPort <n1>:443
ORPort <n2>:443
...
ORPort <nN>:443
When starting tor, the log will show that only <n1> is self-tested and...I run Tor 0.2.4.17-rc as a bridge configured with multiple IPv4 addresses and one ORPort line for each, like so:
ORPort <n1>:443
ORPort <n2>:443
...
ORPort <nN>:443
When starting tor, the log will show that only <n1> is self-tested and a bridge descriptor is published:
[notice] Now checking whether ORPort <n1>:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
[notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Tor should publish bridge descriptors for all the available addresses and the bridge authorities should probably put them into pools of different confidentiality levels.
For clarity, the documentation should explain Tor's bandwidth allocation as configured with Relay(Bandwidth|Burst)Rate (per address or total).
**Trac**:
**Username**: sqrt2Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/8001obfsproxy makes tor warn when one bridge is down2020-06-13T14:26:37ZRoger Dingledineobfsproxy makes tor warn when one bridge is downWhen you run the fancy new flashproxy/obfsproxy bundle:
https://blog.torproject.org/blog/combined-flash-proxy-pyobfsproxy-browser-bundles
you get
```
Jan 19 15:09:17.120 [Warning] Proxy Client: unable to connect to 208.79.90.242:55564 ("...When you run the fancy new flashproxy/obfsproxy bundle:
https://blog.torproject.org/blog/combined-flash-proxy-pyobfsproxy-browser-bundles
you get
```
Jan 19 15:09:17.120 [Warning] Proxy Client: unable to connect to 208.79.90.242:55564 ("server rejected connection")
```
That's because that bridge is down currently.
When a bridge fails, we should probably only [warn] if no bridges have succeeded.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/6837More fine-grained modular decomposition2020-06-13T14:22:44ZNick MathewsonMore fine-grained modular decompositionWe should chop up our huger C files into smaller ones, based on actual module boundaries.
This will make it harder for us to merge pending branches that touch that code, but those are at a low ebb right now, so it's a good time.
The to...We should chop up our huger C files into smaller ones, based on actual module boundaries.
This will make it harder for us to merge pending branches that touch that code, but those are at a low ebb right now, so it's a good time.
The top 10 offenders in our current codebase are:
```
4614 src/or/rendservice.c
4839 src/or/channel.c
5200 src/or/connection.c
5386 src/or/or.h
5648 src/common/util.c
5666 src/or/directory.c
5688 src/or/routerparse.c
5771 src/or/routerlist.c
7223 src/or/control.c
8006 src/or/config.c
```
(updated May 2017)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/6313Many of Tor's complex functions should be refactored2020-06-13T14:20:57ZNick MathewsonMany of Tor's complex functions should be refactoredSee some discussion on #6177.
I'm attaching a list of the most complex functions in Tor (by cyclomatic complexity).
Possibly cyclomatic-complexity-per-line would be another good thing to look at.See some discussion on #6177.
I'm attaching a list of the most complex functions in Tor (by cyclomatic complexity).
Possibly cyclomatic-complexity-per-line would be another good thing to look at.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19701Allow tor and tor-gencert to be specified on the chutney command-line2020-06-13T13:29:47ZteorAllow tor and tor-gencert to be specified on the chutney command-lineAs well as being specified via the CHUTNEY_TOR and CHUTNEY_TOR_GENCERT environmental variables.As well as being specified via the CHUTNEY_TOR and CHUTNEY_TOR_GENCERT environmental variables.teorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/19116Add scripts to chutney so it works on a tor binary2020-06-13T13:29:44ZteorAdd scripts to chutney so it works on a tor binaryIf chutney was self-contained and could run tests on a plain tor binary, it would be easier to do jenkins tests using chutney.
To make chutney work, we use parts of the tor git tree, including some Makefile targets to select the tests w...If chutney was self-contained and could run tests on a plain tor binary, it would be easier to do jenkins tests using chutney.
To make chutney work, we use parts of the tor git tree, including some Makefile targets to select the tests we run, and src/test/test-network.sh.
If we move these scripts to the chutney tree, we can run a set of chutney targets anywhere, without requiring a tor build tree.teorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/18827Allow specifying the Chutney data directory2020-06-13T13:29:42ZanonymAllow specifying the Chutney data directoryWith "Chutney data directory" I am referring to the `net` sub-directory. I find it preferable to be able to store such cruft outside of the source tree. See the attached patch.With "Chutney data directory" I am referring to the `net` sub-directory. I find it preferable to be able to store such cruft outside of the source tree. See the attached patch.anonymanonymhttps://gitlab.torproject.org/legacy/trac/-/issues/18826Allow setting the listen address for all Chutney hosts2020-06-13T13:29:42ZanonymAllow setting the listen address for all Chutney hostsIn Tails' automated test suite we have plans to use Chutney to run a simulated Tor network (for increased performance and, in particular, robustness). Of course, we do not want to run that Chutney instance in the system under testing (i....In Tails' automated test suite we have plans to use Chutney to run a simulated Tor network (for increased performance and, in particular, robustness). Of course, we do not want to run that Chutney instance in the system under testing (i.e. the Tails instance) but on the host orchestrating the tests. In order to avoid having to forward traffic via firewall rules, we'd like it to be possible to make the Chutney hosts listen on some other IP address than localhost.
The attached patch allows setting the address all Chutney hosts will listen on via the `CHUTNEY_LISTEN_ADDRESS` environment variable.anonymanonymhttps://gitlab.torproject.org/legacy/trac/-/issues/18185Fix coding style according to PEP82020-06-13T13:29:39ZcypherpunksFix coding style according to PEP8The pep8 tool shows several minor PEP8 violations. Fixing these violations would makes it easier for future developers (including me) to check whether their patches are according to the PEP8 without having to ignore existing violations. ...The pep8 tool shows several minor PEP8 violations. Fixing these violations would makes it easier for future developers (including me) to check whether their patches are according to the PEP8 without having to ignore existing violations. Also having existing violations gives future developers less incentive to fix violations they introduce.cypherpunkscypherpunkshttps://gitlab.torproject.org/legacy/trac/-/issues/17290Include network tests with ill-behaved clients and servers2020-06-13T13:29:36ZNick MathewsonInclude network tests with ill-behaved clients and serversThis is a deliverable for October 2016.This is a deliverable for October 2016.