Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T18:04:42Zhttps://gitlab.torproject.org/legacy/trac/-/issues/34298Address networkx's API change, which breaks OnionPerf2020-06-13T18:04:42ZPhilipp Winterphw@torproject.orgAddress networkx's API change, which breaks OnionPerfNetworkx in version [2.4](https://networkx.github.io/documentation/stable/release/release_2.4.html) deprecated the `node` attribute of `DiGraph` and suggests using `nodes` instead. This breaks OnionPerf but luckily, it's an easy fix.
He...Networkx in version [2.4](https://networkx.github.io/documentation/stable/release/release_2.4.html) deprecated the `node` attribute of `DiGraph` and suggests using `nodes` instead. This breaks OnionPerf but luckily, it's an easy fix.
Here's the error I'm getting on master:
```
Traceback (most recent call last):
File "/home/phw/rcs/onionperf/venv/bin/onionperf", line 4, in <module>
__import__('pkg_resources').run_script('OnionPerf==0.2rc0', 'onionperf')
File "/home/phw/rcs/onionperf/venv/lib/python3.7/site-packages/pkg_resources/__init__.py", line 666, in run_script
self.require(requires)[0].run_script(script_name, ns)
File "/home/phw/rcs/onionperf/venv/lib/python3.7/site-packages/pkg_resources/__init__.py", line 1453, in run_script
exec(script_code, namespace, namespace)
File "/home/phw/rcs/onionperf/venv/lib/python3.7/site-packages/OnionPerf-0.2rc0-py3.7.egg/EGG-INFO/scripts/onionperf", line 529, in <module>
File "/home/phw/rcs/onionperf/venv/lib/python3.7/site-packages/OnionPerf-0.2rc0-py3.7.egg/EGG-INFO/scripts/onionperf", line 350, in main
File "/home/phw/rcs/onionperf/venv/lib/python3.7/site-packages/OnionPerf-0.2rc0-py3.7.egg/EGG-INFO/scripts/onionperf", line 401, in measure
File "/home/phw/rcs/onionperf/venv/lib/python3.7/site-packages/OnionPerf-0.2rc0-py3.7.egg/onionperf/measurement.py", line 239, in run
File "/home/phw/rcs/onionperf/venv/lib/python3.7/site-packages/OnionPerf-0.2rc0-py3.7.egg/onionperf/measurement.py", line 315, in __start_tgen_client
File "/home/phw/rcs/onionperf/venv/lib/python3.7/site-packages/OnionPerf-0.2rc0-py3.7.egg/onionperf/measurement.py", line 341, in __start_tgen
File "/home/phw/rcs/onionperf/venv/lib/python3.7/site-packages/OnionPerf-0.2rc0-py3.7.egg/onionperf/model.py", line 66, in __init__
File "/home/phw/rcs/onionperf/venv/lib/python3.7/site-packages/OnionPerf-0.2rc0-py3.7.egg/onionperf/model.py", line 74, in generate
AttributeError: 'DiGraph' object has no attribute 'node'
```Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/34103Stop rounding y axis labels with units2020-06-13T18:15:35ZKarsten LoesingStop rounding y axis labels with unitsThe [Time to download files over Tor graph](https://metrics.torproject.org/torperf.html) now displays the following labels, all using seconds as units: 0, 0, 1, 2, 2, 2. Better labels would be 0.0, 0.5, 1.0, 1.5, 2.0, 2.5.
Similarly, th...The [Time to download files over Tor graph](https://metrics.torproject.org/torperf.html) now displays the following labels, all using seconds as units: 0, 0, 1, 2, 2, 2. Better labels would be 0.0, 0.5, 1.0, 1.5, 2.0, 2.5.
Similarly, the [Advertised bandwidth distribution graph](https://metrics.torproject.org/advbwdist-perc.html?start=2015-01-19&end=2020-04-18&p=50) showing the median displays the following labels, all using Gbit/s: 0.00, 0.02, 0.05, 0.08. Better labels would be 0.000, 0.025, 0.050, 0.075.
The underlying issue, which we didn't fix in #33933 nor in #33066, is that we have to pick a number of digits for a graph which then needs to work for whichever scale is being displayed. In some cases this is difficult to do right (first graph above with measurements apparently getting faster over time), in other cases it's impossible (second graph above with 1st and 99th percentile having different orders of magnitude).
The fix is to stop using the `unit_format` function from the somewhat outdated `scales` package that we're using and instead write our own function for formatting labels with units.
I'm going to attach two example graphs where this went wrong plus a patch that I'll review more carefully tomorrow before I deploy it on the server.Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/34023Reduce the number of 50 KiB downloads2020-06-13T18:04:30ZKarsten LoesingReduce the number of 50 KiB downloadsOn #33076 we discussed whether we should kill the 50 KiB downloads in deployed OnionPerfs and only keep the 1 MiB and 5 MiB downloads. The primary reason would be that our [throughput](https://metrics.torproject.org/onionperf-throughput....On #33076 we discussed whether we should kill the 50 KiB downloads in deployed OnionPerfs and only keep the 1 MiB and 5 MiB downloads. The primary reason would be that our [throughput](https://metrics.torproject.org/onionperf-throughput.html) graphs would be based on five times as many data points per day, because they only include 1 MiB and 5 MiB downloads, but not 50 KiB downloads. This would not affect our [circuit round-trip latencies graphs](https://metrics.torproject.org/onionperf-latencies.html) which include all three downloaded file sizes.
The main reason against killing 50 KiB downloads is that OnionPerfs would consume more bandwidth and also put more load on the Tor network. Let's consider two scenarios with and without 50 KiB downloads. In both scenarios we're making a new download every 5 minutes, randomly chosen with a weight of 1.0 for 5 MiB runs, 2.0 for 1 MiB runs, and either 12.0 or 0.0 for 50 KiB runs:
- With 50 KiB downloads we're downloading on average `12/15 * 50 KiB + 2/15 * 1 MiB + 1/15 * 5 MiB = 517 KiB` every 5 minutes, or `517 * 8 * 1024 / (300 * 1000) = 14 kbps`.
- Without 50 KiB downloads we're downloading on average `2/3 * 1 MiB + 1/3 * 5 MiB = 2389 KiB` every 5 minutes, or `2389 * 8 * 1024 / (300 * 1000) = 65 kbps`.
These numbers are both tiny in comparison to the overall network capacity and to other services like the bandwidth scanners.
I'm going to make this change and deploy it on new OnionPerf instances tomorrow, unless I hear objections here.Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/33974Update OnionPerf to TGen 1.0.02020-06-13T18:04:28ZKarsten LoesingUpdate OnionPerf to TGen 1.0.0[TGen 1.0.0](https://github.com/shadow/tgen/releases/tag/v1.0.0) comes with a "change in the format of some of the configuration options that breaks compatibility with the previous version 0.0.1."
I tried to update OnionPerf to write ou...[TGen 1.0.0](https://github.com/shadow/tgen/releases/tag/v1.0.0) comes with a "change in the format of some of the configuration options that breaks compatibility with the previous version 0.0.1."
I tried to update OnionPerf to write out TGen files that TGen 1.0.0 understands. Here's the diff:
```
diff --git a/onionperf/model.py b/onionperf/model.py
index 3c057c5..90c824e 100644
--- a/onionperf/model.py
+++ b/onionperf/model.py
@@ -77,9 +77,9 @@ class TorperfModel(GeneratableTGenModel):
if self.socksproxy is not None:
g.node["start"]["socksproxy"] = self.socksproxy
g.add_node("pause", time="5 minutes")
- g.add_node("transfer50k", type="get", protocol="tcp", size="50 KiB", timeout="295 seconds", stallout="300 seconds")
- g.add_node("transfer1m", type="get", protocol="tcp", size="1 MiB", timeout="1795 seconds", stallout="1800 seconds")
- g.add_node("transfer5m", type="get", protocol="tcp", size="5 MiB", timeout="3595 seconds", stallout="3600 seconds")
+ g.add_node("stream50k", recvsize="50 KiB", timeout="295 seconds", stallout="300 seconds")
+ g.add_node("stream1m", recvsize="1 MiB", timeout="1795 seconds", stallout="1800 seconds")
+ g.add_node("stream5m", recvsize="5 MiB", timeout="3595 seconds", stallout="3600 seconds")
g.add_edge("start", "pause")
@@ -88,9 +88,9 @@ class TorperfModel(GeneratableTGenModel):
g.add_edge("pause", "pause")
# these are chosen with weighted probability, change edge 'weight' attributes to adjust probability
- g.add_edge("pause", "transfer50k", weight="12.0")
- g.add_edge("pause", "transfer1m", weight="2.0")
- g.add_edge("pause", "transfer5m", weight="1.0")
+ g.add_edge("pause", "stream50k", weight="12.0")
+ g.add_edge("pause", "stream1m", weight="2.0")
+ g.add_edge("pause", "stream5m", weight="1.0")
return g
@@ -109,10 +109,10 @@ class OneshotModel(GeneratableTGenModel):
g.add_node("start", serverport=self.tgen_port, peers=server_str, loglevel="info", heartbeat="1 minute")
if self.socksproxy is not None:
g.node["start"]["socksproxy"] = self.socksproxy
- g.add_node("transfer5m", type="get", protocol="tcp", size="5 MiB", timeout="15 seconds", stallout="10 seconds")
+ g.add_node("stream5m", recvsize="5 MiB", timeout="15 seconds", stallout="10 seconds")
- g.add_edge("start", "transfer5m")
- g.add_edge("transfer5m", "start")
+ g.add_edge("start", "stream5m")
+ g.add_edge("stream5m", "start")
return g
```
I'll let an OnionPerf instance run for a day to see at the output, also to see if we need to make adjustments to OnionPerf's analyze mode due to slightly changed log messages.
Until then, do these changes above look reasonable? Or did I miss something? Thanks!Ana CusturaAna Custurahttps://gitlab.torproject.org/legacy/trac/-/issues/33899Allow IPv6 addresses to be canonical2020-06-13T15:53:06ZteorAllow IPv6 addresses to be canonicalIn #17604, we allowed IPv6 connections to set is_canonical_to_peer. But we did not let them set is_canonical.
So channel_tls_process_netinfo_cell() handles IPv6 addresses, but connection_or_check_canonicity() does not.
This inconsisten...In #17604, we allowed IPv6 connections to set is_canonical_to_peer. But we did not let them set is_canonical.
So channel_tls_process_netinfo_cell() handles IPv6 addresses, but connection_or_check_canonicity() does not.
This inconsistency could be one cause of the logging issues in #24841.
We should allow IPv6 connections to be canonical. We should also do some cleanup of the related connection address logging in #33898.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33793Avoid some race conditions when running chutney networks in series2020-06-13T13:31:49ZteorAvoid some race conditions when running chutney networks in seriesWhen chutney runs multiple networks, one after the others, sometimes older tor instances are left running.
To avoid these issues, chutney can:
* wait longer after terminating tor processes
* cleanup pid files, so we don't accidentally t...When chutney runs multiple networks, one after the others, sometimes older tor instances are left running.
To avoid these issues, chutney can:
* wait longer after terminating tor processes
* cleanup pid files, so we don't accidentally terminate unrelated processesteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33679Make sure every address function that takes for_listening supports IPv62020-06-13T15:52:28ZteorMake sure every address function that takes for_listening supports IPv6We need to make sure all of our basic address functions support IPv6.
For example, tor_addr_is_valid() only supports IPv4 for_listening.
We need to make this change before we create generic IPv6 listeners for proposal 312.We need to make sure all of our basic address functions support IPv6.
For example, tor_addr_is_valid() only supports IPv4 for_listening.
We need to make this change before we create generic IPv6 listeners for proposal 312.Tor: 0.4.4.x-finalMrSquancheeMrSquancheehttps://gitlab.torproject.org/legacy/trac/-/issues/33672Force include https-everywhere in incremental mar update2020-06-16T01:11:57ZMatthew FinkelForce include https-everywhere in incremental mar updateWe should include an older version of https-everywhere in the upcoming release. This won't be a problem for new installations. However, any recently run instance of Tor Browser mostlikely automatically upgraded to the newest https-e vers...We should include an older version of https-everywhere in the upcoming release. This won't be a problem for new installations. However, any recently run instance of Tor Browser mostlikely automatically upgraded to the newest https-e version (2020.3.16), so we should include the older version (2019.11.7) in our incremental mar files.
2019.11.7 is the version we included in the last Tor Browser version, so it won't be included in the incrementals. It seems like we can force inclusion in `make_incremental_update.sh`.
I see two options:
1. (tor-browser) Patch `tools/update-packaging/make_incremental_update.sh` so it always include https-everywhere (and then we revert/drop that patch at the next rebase)
1. (tor-browser-build) Patch `tools/update-responses/gen_incrementals` so it passes `-f $ext_path/$https_everywhere_dir/* $packed_https_e_path` (with appropriate paths) when it calls `make_incremental_update.sh`?
If there are alternatives, we can consider those, too.https://gitlab.torproject.org/legacy/trac/-/issues/33643Appveyor: OpenSSL version mismatch in unit tests, 2020 edition2020-06-13T15:52:21ZteorAppveyor: OpenSSL version mismatch in unit tests, 2020 editionIt's happened again:
```
OpenSSL library version 1.1.1d did not begin with header version 1.1.1e.
```
https://ci.appveyor.com/project/torproject/tor/builds/31549942/job/v0i9svtg78gqln1v#L6380
Just like #32449, #28574, #28399 and #25942....It's happened again:
```
OpenSSL library version 1.1.1d did not begin with header version 1.1.1e.
```
https://ci.appveyor.com/project/torproject/tor/builds/31549942/job/v0i9svtg78gqln1v#L6380
Just like #32449, #28574, #28399 and #25942.
We think our tests are fragile, because they are not copying the necessary libraries into `${env:build}/src/test` from `C:/mingw32/lib`:
```
ssl
crypto
lzma
event
zstd
```
We already copy zlib and ssp at https://github.com/ahf/tor/blob/master/.appveyor.yml#L98-L99 .
These libraries might have different dll prefixes or suffixes, for example, OpenSSL is:
```
/mingw32/bin/libcrypto-1_1.dll
/mingw32/bin/libssl-1_1.dll
```
https://packages.msys2.org/package/mingw-w64-i686-openssl
We might also want to copy these libraries into the same directory as the tor executable `${env:build}/src/app`, before we run the tests that launch tor.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/33583Stop setting AssumeReachable on chutney relays and bridges2020-06-13T15:53:49ZteorStop setting AssumeReachable on chutney relays and bridgesWe need to stop setting AssumeReachable on relays and bridges in chutney networks, so they do reachability self-tests.
We should continue to set AssumeReachable on authorities (including the bridge authority), because it disables author...We need to stop setting AssumeReachable on relays and bridges in chutney networks, so they do reachability self-tests.
We should continue to set AssumeReachable on authorities (including the bridge authority), because it disables authority to relay reachability tests. (These tests are still performed on a half-hourly schedule, even in chutney networks. And they are out of scope for Sponsor 55.)
After we implement this change, we should also be able to implement #33581.teorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33458Assertion desc failed in hs_client_close_intro_circuits_from_desc at src/feat...2020-06-13T15:51:51ZGeorge KadianakisAssertion desc failed in hs_client_close_intro_circuits_from_desc at src/feature/hs/hs_client.c: 2413Just got this assert failure in my TBB. I had a v3 onion open, and long ago I visited a client-auth onion that I didn't manage to decrypt so it lingered in my cache with `->desc` set to `NULL`.
```
Feb 26 14:17:31.000 [err] tor_asserti...Just got this assert failure in my TBB. I had a v3 onion open, and long ago I visited a client-auth onion that I didn't manage to decrypt so it lingered in my cache with `->desc` set to `NULL`.
```
Feb 26 14:17:31.000 [err] tor_assertion_failed_(): Bug: src/feature/hs/hs_client.c:2413: hs_client_close_intro_circuits_from_desc: Assertion desc failed; aborting. (on T
or 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: Tor 0.4.3.2-alpha (git-dcbf6611d9980953): Assertion desc failed in hs_client_close_intro_circuits_from_desc at src/feature/hs/hs_client.c:
2413: . Stack trace: (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(log_backtrace_impl+0x56) [0x5623c8fe6e96] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(tor_assertion_failed_+0x147) [0x5623c8fe1f97] (on Tor 0.4.3.2-alpha dcbf6611d9980
953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(hs_client_close_intro_circuits_from_desc+0xb6) [0x5623c8ee7c76] (on Tor 0.4.3.2-a
lpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(hs_cache_clean_as_client+0xf2) [0x5623c8edfbd2] (on Tor 0.4.3.2-alpha dcbf6611d99
80953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(+0x6ebbc) [0x5623c8e3fbbc] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(+0x73487) [0x5623c8e44487] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: ./TorBrowser/Tor/libevent-2.1.so.6(+0x22565) [0x7f3c28b8a565] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: ./TorBrowser/Tor/libevent-2.1.so.6(event_base_loop+0x517) [0x7f3c28b8af27] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(do_main_loop+0xdb) [0x5623c8e4372b] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(tor_run_main+0x10b5) [0x5623c8e309f5] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(tor_main+0x3a) [0x5623c8e2e19a] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(main+0x19) [0x5623c8e2dd39] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f3c28207bbb] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(+0x5cd89) [0x5623c8e2dd89] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
```Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33434Allow users to select Onion Service version to measure2020-06-13T18:15:35ZAna CusturaAllow users to select Onion Service version to measureCurrently OP runs measurements using both v2 and v3 Onion Services by default, when the user may only wish to only test one of them.Currently OP runs measurements using both v2 and v3 Onion Services by default, when the user may only wish to only test one of them.Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/33420Add CBT events to Onionperf result files2020-06-13T18:04:23ZAna CusturaAdd CBT events to Onionperf result filesAs I understand this, the results should record whether the CBT was set at the time of measurement. This could just be a CBT_SET True/False field in the tpf results file. The CBT resets in certain conditions, and this should be reflected...As I understand this, the results should record whether the CBT was set at the time of measurement. This could just be a CBT_SET True/False field in the tpf results file. The CBT resets in certain conditions, and this should be reflected in the results. The events should be parsed from the tor logs.
We should check with Mike if this meets the requirements.https://gitlab.torproject.org/legacy/trac/-/issues/33396Automatically compress Onionperf logs2020-06-13T18:04:20ZAna CusturaAutomatically compress Onionperf logsAutomatically compress Onionperf logs to save space. This could be done as part of the log rotation at midnight or separately.Automatically compress Onionperf logs to save space. This could be done as part of the log rotation at midnight or separately.https://gitlab.torproject.org/legacy/trac/-/issues/33334Add a mixed+hs-v23-ipv6 network to tor's test-network2020-06-13T15:51:26ZteorAdd a mixed+hs-v23-ipv6 network to tor's test-networkWe want to add the new mixed+hs-v23-ipv6 chutney network from #33333 to tor's makefile tests:
* test-network-all
* test-network-ipv6
We'll need some minor refactoring, so that we can test for "ipv6" and "mixed", before using this networ...We want to add the new mixed+hs-v23-ipv6 chutney network from #33333 to tor's makefile tests:
* test-network-all
* test-network-ipv6
We'll need some minor refactoring, so that we can test for "ipv6" and "mixed", before using this network.
I think the resulting code will be simpler.
We can pass the following network lists to the test-network-run target:
* unconditional (ipv4 and not mixed)
* ipv6
* mixed
* mixed_ipv6
Then we can:
* test for ipv6 and mixed in separate tests,
* set flags for mixed and ipv6, and
* skip or use the right network lists.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33257Add CDF-DL graph2020-06-13T18:04:06ZKarsten LoesingAdd CDF-DL graphWe're planning to add the CDF-DL graph discussed in #33076 to OnionPerf. This ticket is for adding that graph to the set of graphs produced by OnionPerf's visualization mode.We're planning to add the CDF-DL graph discussed in #33076 to OnionPerf. This ticket is for adding that graph to the set of graphs produced by OnionPerf's visualization mode.Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/32994Get all flag defaults from port_cfg_new()2020-06-13T15:52:10ZteorGet all flag defaults from port_cfg_new()The Tor port flags code is needlessly complex. To change a default, you need to change:
* port_cfg_new()
* port_parse_config()
* connection_listener_new()
We should call port_cfg_new() for the defaults in all these cases.The Tor port flags code is needlessly complex. To change a default, you need to change:
* port_cfg_new()
* port_parse_config()
* connection_listener_new()
We should call port_cfg_new() for the defaults in all these cases.Tor: 0.4.4.x-finalMrSquancheeMrSquancheehttps://gitlab.torproject.org/legacy/trac/-/issues/32792Copy chutney CI diagnostics to Tor's chutney job2020-06-13T15:49:19ZteorCopy chutney CI diagnostics to Tor's chutney jobIn #32630, we improved chutney's CI diagnostics on failure. We should also run those diagnostics in tor's chutney CI job.In #32630, we improved chutney's CI diagnostics on failure. We should also run those diagnostics in tor's chutney CI job.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32721Allow chutney users to disable tor's sandbox at runtime2020-06-13T13:31:14ZteorAllow chutney users to disable tor's sandbox at runtimeIn #32240, we discovered that tor's sandbox doesn't work on recent Ubuntu versions. So we need to disable the sandbox on those CI jobs.
One good way to implement this change, is by making it a first-class chutney feature.In #32240, we discovered that tor's sandbox doesn't work on recent Ubuntu versions. So we need to disable the sandbox on those CI jobs.
One good way to implement this change, is by making it a first-class chutney feature.teorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32663Require coccinelle 1.0.4 in check_cocci_parse.sh2020-06-13T15:48:48ZteorRequire coccinelle 1.0.4 in check_cocci_parse.shIn #31919, we upgraded most of our CI jobs to Ubuntu bionic, so that we had a recent enough version of coccinelle (1.0.4 or later).
But we didn't put a minimum coccinelle version requirement in check_cocci_parse.sh.
We should also chec...In #31919, we upgraded most of our CI jobs to Ubuntu bionic, so that we had a recent enough version of coccinelle (1.0.4 or later).
But we didn't put a minimum coccinelle version requirement in check_cocci_parse.sh.
We should also check what happens if we install coccinelle on Windows.
For details, see:
https://trac.torproject.org/projects/tor/ticket/32500#comment:18Tor: 0.4.3.x-finalteorteor