Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:53:10Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33919Write unit tests for channel_matches_target_addr_for_extend()2020-06-13T15:53:10ZteorWrite unit tests for channel_matches_target_addr_for_extend()In #33817, we modify channel_matches_target_addr_for_extend() to take an IPv4 and an IPv6 address.
We also modify channel_get_for_extend() to take an IPv4 and an IPv6 address. It has existing tests, but they ignore IP addresses. (And mo...In #33817, we modify channel_matches_target_addr_for_extend() to take an IPv4 and an IPv6 address.
We also modify channel_get_for_extend() to take an IPv4 and an IPv6 address. It has existing tests, but they ignore IP addresses. (And mock the matches_target() method, which is called by channel_matches_target_addr_for_extend().)
It would be useful to have tests that check that a channel matches, if its IP address matches the IPv4 or IPv6 address. But it's not urgent. (And the actual changes to the function are pretty trivial.)
The setup for these tasks is a bit tricky, we need to set up a channel_tls_t and an associated connection_t with a real_addr. (Note that #33898 may change the name of real_addr.)
This task is not urgent or important. Anyone can do this task.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/33167Test changes in descriptors2020-06-13T16:16:26ZjugaTest changes in descriptorsWorking on #30733 asn pointed out that there're no tests to check the changes in descriptors.
It'll be easier to create these tests when:
- sbws can use chutney (#33150) so that the test network lives longer than the 1st consensus
- `R...Working on #30733 asn pointed out that there're no tests to check the changes in descriptors.
It'll be easier to create these tests when:
- sbws can use chutney (#33150) so that the test network lives longer than the 1st consensus
- `RelayList` can be initialized with different consensus/descriptors and not only a controller (#29717)
- have an external tool that check the generated bandwidth files in the Tor network and detects changes in the descriptors (#33152)
Maybe we should include this ticket as part of #33121sbws: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/33166Test tor dormant mode2020-06-13T16:16:26ZjugaTest tor dormant modeWorking on #30733 asn pointed out to check the dormant mode.
Dormant mode was introduced in tor 0.4.0.4-rc.
As teor suggested, we should check whether sbws stop trying to make circuits, and therefore become dormant, when:
- the network...Working on #30733 asn pointed out to check the dormant mode.
Dormant mode was introduced in tor 0.4.0.4-rc.
As teor suggested, we should check whether sbws stop trying to make circuits, and therefore become dormant, when:
- the network goes down (it probably just stops and prints a traceback, as happened in #32939)
- tor doesn't have a recent consensus or descriptors
We also should check what happen when sbws starts with tor in dormant mode and probably set `DormantCanceledByStartup 1` until we fix bugs.
Maybe we should include this ticket as part of #33121.sbws: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/33150Allow to connect to an external control port2020-06-13T16:16:25ZjugaAllow to connect to an external control portTo be able to run integration tests with chutney.To be able to run integration tests with chutney.sbws: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/33149Parent ticket to improve test coverage and integration tests2020-06-13T16:16:24ZjugaParent ticket to improve test coverage and integration testsParent ticketParent ticketsbws: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/30902Stop comparing file_created key in test2020-06-13T16:16:13ZjugaStop comparing file_created key in testIn concrete tests/unit/lib/v3bwfile.py::test_from_results_read.
Because some times it files with the second: https://travis-ci.org/juga0/sbws/jobs/546378459#L1339.In concrete tests/unit/lib/v3bwfile.py::test_from_results_read.
Because some times it files with the second: https://travis-ci.org/juga0/sbws/jobs/546378459#L1339.sbws: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/30867Write proxy-go tests to cover existing implementation2020-06-13T18:20:19ZCecylia BocovichWrite proxy-go tests to cover existing implementationCurrently we only have proxy-go tests to test extracting the client's remote IP from the SDP offer.
We should increase test coverage.Currently we only have proxy-go tests to test extracting the client's remote IP from the SDP offer.
We should increase test coverage.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/legacy/trac/-/issues/29727Check output of generate in the integration tests2020-06-13T16:15:41ZjugaCheck output of generate in the integration testsIt was included `sbws scanner` in the tests, but `generate` could also be included and check that the files generated contain expectected Keys and Values.
These files could also replace many of the tests input examples and change them a...It was included `sbws scanner` in the tests, but `generate` could also be included and check that the files generated contain expectected Keys and Values.
These files could also replace many of the tests input examples and change them as part of #28684sbws: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/29358Stop overloading the CPU when the test network is run in the integration tests2020-06-13T16:15:29ZjugaStop overloading the CPU when the test network is run in the integration testsIt might be caused by the test network relays' configuration.
In the case it's not possible to do not possible to overload the CPU, it's still possible to simplify the relays' configuration.It might be caused by the test network relays' configuration.
In the case it's not possible to do not possible to overload the CPU, it's still possible to simplify the relays' configuration.sbws: 1.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28774Stop the integration tests http server when the tests end2020-06-13T16:15:08ZjugaStop the integration tests http server when the tests endThe integration tests launch an HTTP server (tox.ini), but it is not stop after tests finish.
This affect the developer running the integration tests, not the operator.The integration tests launch an HTTP server (tox.ini), but it is not stop after tests finish.
This affect the developer running the integration tests, not the operator.sbws: unspecifiedjugajugahttps://gitlab.torproject.org/legacy/trac/-/issues/28739Add more tests for assigning voting flags in test_voting_flags.c2020-06-13T15:35:16ZNick MathewsonAdd more tests for assigning voting flags in test_voting_flags.cIn test_voting_flags.c we add some tests to make sure that flags are assigned the way we want when authorities make votes. We didn't add tests for every flag, though. We should do that some time.In test_voting_flags.c we add some tests to make sure that flags are assigned the way we want when authorities make votes. We didn't add tests for every flag, though. We should do that some time.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26196Abort in test_bridges.c2020-06-13T15:25:57ZTracAbort in test_bridges.cRunning `test.exe bridges/clear_bridge_list` causes this assertion:
```
bridges/clear_bridge_list: May 23 17:12:53.714 [err] tor_assertion_failed_():
Bug: container.h:70: smartlist_get: Assertion sl->num_used > idx failed;
```
AFA...Running `test.exe bridges/clear_bridge_list` causes this assertion:
```
bridges/clear_bridge_list: May 23 17:12:53.714 [err] tor_assertion_failed_():
Bug: container.h:70: smartlist_get: Assertion sl->num_used > idx failed;
```
AFAICS, since `sweep_bridge_list()` caused all entries in `bridgelist` to get deleted, an index of zero is illegal. Don't ask me why.
And since I compiled all `test/*.c` sources with `-DDEBUG_SMARTLIST`, this will trigger this abort(). I fail to see why this isn't done in the officially.
\\
PS1. I'm on Win-10, tor.exe + libs was built with MSVC 2017.
\\
PS2. Build tor.exe from master at 23 May 2018.
**Trac**:
**Username**: gvanemTor: 0.3.4.x-finalrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/26105Perhaps, make test coverage deterministic _within_ lines2020-06-13T15:25:41ZNick MathewsonPerhaps, make test coverage deterministic _within_ linesSee #25907 and #26101 for background: apparently gcov now has a feature where it can tell us that a line was reached, but not every basic block within the line was reached.
Right now, our unit tests have two cases where sometimes a line...See #25907 and #26101 for background: apparently gcov now has a feature where it can tell us that a line was reached, but not every basic block within the line was reached.
Right now, our unit tests have two cases where sometimes a line is completely covered, and sometime the line is only partially covered:
```
--- a/workqueue.c.gcov.tmp
+++ /workqueue.c.gcov.tmp
@@ -198,7 +198,7 @@
1: tor_mutex_acquire(&ent->on_pool->lock);
1: workqueue_priority_t prio = ent->priority;
1: if (ent->pending) {
- 1*: TOR_TAILQ_REMOVE(&ent->on_pool->work[prio], ent, next_work);
+ 1: TOR_TAILQ_REMOVE(&ent->on_pool->work[prio], ent, next_work);
1: cancelled = 1;
1: result = ent->arg;
-: }
```
```
--- a/compat_pthreads.c.gcov.tmp
+++ /compat_pthreads.c.gcov.tmp
@@ -271,7 +271,7 @@
-: }
1: tvnow.tv_sec = ts.tv_sec;
1: tvnow.tv_usec = (int)(ts.tv_nsec / 1000);
- 1*: timeradd(tv, &tvnow, &tvsum);
+ 1: timeradd(tv, &tvnow, &tvsum);
-:#else /* !(defined(HAVE_CLOCK_GETTIME) && defined(USE_COND_CLOCK)) */
-: if (gettimeofday(&tvnow, NULL) < 0)
-: return -1;
```
Unless coveralls cares about these, I think solving the determinism here is not super-important, though it might be fun from a completionist perspective.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25787geoip_load_file() tests don't work on all window build environments2020-06-13T15:24:24ZNick Mathewsongeoip_load_file() tests don't work on all window build environmentsThese tests assume that when the test binary is run, it can see the contents of the builddir at the same location as the original build process. But that isn't always true for windows builds.These tests assume that when the test binary is run, it can see the contents of the builddir at the same location as the original build process. But that isn't always true for windows builds.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/24795test_rust fails on osx with "can't find crate for `libc`"2020-06-13T15:23:24ZNick Mathewsontest_rust fails on osx with "can't find crate for `libc`"After I apply mix fix for #24642, I see this message in test-suite.log from test_rust.sh:
```
Doc-tests protover
error[E0463]: can't find crate for `libc`
--> /Users/nickm/src/tor/src/rust/protover/lib.rs:25:1
|
25 | extern crat...After I apply mix fix for #24642, I see this message in test-suite.log from test_rust.sh:
```
Doc-tests protover
error[E0463]: can't find crate for `libc`
--> /Users/nickm/src/tor/src/rust/protover/lib.rs:25:1
|
25 | extern crate libc;
| ^^^^^^^^^^^^^^^^^^ can't find crate
```
I do not see the same message on my linux rust builds.Tor: 0.3.3.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/23071test_hs_ntor.sh fails with recent pysha32020-06-13T15:12:11ZNick Mathewsontest_hs_ntor.sh fails with recent pysha3Right now the recommended sha3 in python is pysha3, which emulates the same sha3 API as is added in python 3.6. But hs_ntor_ref.py doesn't work there.Right now the recommended sha3 in python is pysha3, which emulates the same sha3 API as is added in python 3.6. But hs_ntor_ref.py doesn't work there.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21935prop224: Deeper testing of HS ntor subsystem2020-06-13T15:07:47ZGeorge Kadianakisprop224: Deeper testing of HS ntor subsystemCurrently we have integration tests that cross-verify our little-t-or HS ntor implementation with a reference python implementation.
However, those tests don't go deep enough into verifying and parsing the actual INTRODUCE/RENDEZVOUS ...Currently we have integration tests that cross-verify our little-t-or HS ntor implementation with a reference python implementation.
However, those tests don't go deep enough into verifying and parsing the actual INTRODUCE/RENDEZVOUS cell contents like our regular ntor integration tests. Instead they just test that the ntor results are consistent between the C and python implementations.
When we implement the whole cell logic on the client and service side, we should test the HS ntor subsystem deeper.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/20620Unit test purpose_needs_anonymity_returns_true_by_default possible bug2020-06-13T15:03:11Zs7rUnit test purpose_needs_anonymity_returns_true_by_default possible bugdir/purpose_needs_anonymity_returns_true_by_default: Nov 09 17:25:37.223 [warn] purpose_needs_anonymity: Bug: Called with dir_purpose=0, router_purpose=0 (on Tor 0.3.0.0-alpha-dev d564187deedb9b85)
OK
Since the test returns OK, also pri...dir/purpose_needs_anonymity_returns_true_by_default: Nov 09 17:25:37.223 [warn] purpose_needs_anonymity: Bug: Called with dir_purpose=0, router_purpose=0 (on Tor 0.3.0.0-alpha-dev d564187deedb9b85)
OK
Since the test returns OK, also printing the line "Bug: [...]" seams confusing.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18490unit-test fail to cross-compile for aarch642020-06-13T14:55:05ZTracunit-test fail to cross-compile for aarch64When trying to cross-compile tor for AARCH64 following error is given:
src/common/libor-crypto-testing.a(src_common_libor_crypto_testing_a-crypto_format.o): In function `crypto_write_tagged_contents_to_file':
crypto_format.c:(.text+0x1c)...When trying to cross-compile tor for AARCH64 following error is given:
src/common/libor-crypto-testing.a(src_common_libor_crypto_testing_a-crypto_format.o): In function `crypto_write_tagged_contents_to_file':
crypto_format.c:(.text+0x1c): relocation truncated to fit: R_AARCH64_LDST64_ABS_LO12_NC against symbol `smartlist_new' defined in .text section in src/common/libor.a(container.o)
collect2: error: ld returned 1 exit status
For complete log see here:
http://autobuild.buildroot.net/results/13ef47c962afefbaa9ea7a95de083f885f1a8825/
The error might be misleading, I was told that this can happen because test and non-test library archives are getting mixed up and the aarch64 toolchain is more picky about this then other toolchains.
**Trac**:
**Username**: wbxTor: 0.2.7.x-finalcypherpunkscypherpunkshttps://gitlab.torproject.org/legacy/trac/-/issues/18378test_address_get_if_addrs_ifaddrs should check for NULL smartlist2020-06-13T14:54:43Zteortest_address_get_if_addrs_ifaddrs should check for NULL smartlistIn test_address_get_if_addrs_ifaddrs, we should check for a NULL smartlist before calling SMARTLIST_FOREACH on it:
```
if (results) {
SMARTLIST_FOREACH(results, tor_addr_t *, t, tor_free(t));
}
```In test_address_get_if_addrs_ifaddrs, we should check for a NULL smartlist before calling SMARTLIST_FOREACH on it:
```
if (results) {
SMARTLIST_FOREACH(results, tor_addr_t *, t, tor_free(t));
}
```Tor: 0.2.8.x-final