The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-11-24T11:56:40Zhttps://gitlab.torproject.org/tpo/community/team/-/issues/8Template letter to universities to unblock Tor2023-11-24T11:56:40ZGusTemplate letter to universities to unblock TorSome universities are blocking torproject.org and also the Tor network.
If we create a template letter, I think many students and teachers will feel engaged to formalize and fill some papers to request to unblock Tor at their universiti...Some universities are blocking torproject.org and also the Tor network.
If we create a template letter, I think many students and teachers will feel engaged to formalize and fill some papers to request to unblock Tor at their universities. And even if the university doesn't unblock at least it will require a formal answer from the university. Thoughts?Roger DingledineRoger Dingledine2023-12-01https://gitlab.torproject.org/tpo/core/tor/-/issues/19968Test fails on Debian experimental reproducible builds2020-06-27T13:58:23ZcypherpunksTest fails on Debian experimental reproducible buildsA [recent build](https://tests.reproducible-builds.org/debian/rbuild/experimental/i386/tor_0.2.9.1-alpha-1.rbuild.log) on the reproducible build machines with Debian experimental fails on one test.
```
util/num_cpus:
FAIL ../src/test...A [recent build](https://tests.reproducible-builds.org/debian/rbuild/experimental/i386/tor_0.2.9.1-alpha-1.rbuild.log) on the reproducible build machines with Debian experimental fails on one test.
```
util/num_cpus:
FAIL ../src/test/test_util.c:3689: assert(num OP_LE 16): 18 vs 16
[num_cpus FAILED]
```
This test was added in [commit 603cb712ef756dd700a52e837bcd643a96311ad6](https://gitweb.torproject.org/tor.git/commit/?id=603cb712ef756dd700a52e837bcd643a96311ad6) which expects the maximum number of CPUs to be 16. The [compute_num_cpus function](https://gitweb.torproject.org/tor.git/tree/src/common/compat.c?id=8feb301413cc0f23b37dedbac0c57de25b88f519#n2801) only logs a message for machines with more than 16 CPUs but doesn't clamp the return value to 16. So there is a discrepancy between the implementation and the test. (Why is there a limit anyway?)
Furthermore, the preprocessor macro that defines the maximum number of CPUs isn't public and can't be used in tests leading to undefined magic numbers.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23066Test granularity, distribution, and inner range of crypto_rand* functions2021-09-16T14:32:00ZteorTest granularity, distribution, and inner range of crypto_rand* functionsIn legacy/trac#23061, we added tests for crypto_rand_double() that test:
* granularity: low bits being non-zero,
* distribution: some values above and below half, and
* inner range: mock crypto_rand() and generate lowest and highest vali...In legacy/trac#23061, we added tests for crypto_rand_double() that test:
* granularity: low bits being non-zero,
* distribution: some values above and below half, and
* inner range: mock crypto_rand() and generate lowest and highest valid results.
We should do the same for:
* crypto_rand()
* crypto_rand_int()
* crypto_rand_int_range()
* crypto_rand_uint64()
* crypto_rand_uint64_range()
* crypto_rand_time_range()
* crypto_rand_hostname()https://gitlab.torproject.org/tpo/core/tor/-/issues/20653Test targets should gracefully handle missing dependencies2021-06-18T18:09:39ZChelsea KomloTest targets should gracefully handle missing dependenciesTest targets should be able to gracefully handle situations where Stem, Chutney or Perl (in the case of check-spaces and check-docs) are not available.
Currently none of these targets do this and just fail by either exiting with exit co...Test targets should be able to gracefully handle situations where Stem, Chutney or Perl (in the case of check-spaces and check-docs) are not available.
Currently none of these targets do this and just fail by either exiting with exit code 1 or simply running non-existing commands (which leads to the same result).https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/21657Test to make sure we isolate or disable all speculative connects2023-01-05T17:16:53ZArthur EdelsteinTest to make sure we isolate or disable all speculative connectsThere are a variety of "resource hint" features in Tor Browser that we want to make sure are isolated by first-party or disabled. These include
```
link rel=preconnect
link rel=prefetch
link rel=prerender
```
and possibly more.
We ...There are a variety of "resource hint" features in Tor Browser that we want to make sure are isolated by first-party or disabled. These include
```
link rel=preconnect
link rel=prefetch
link rel=prerender
```
and possibly more.
We should test this for the ESR45 and ESR52 versions of Tor Browser, because isolation will have different mechanisms.
See https://w3c.github.io/resource-hints/
We should also look into "SpeculativeConnect" code in Firefox to make sure there aren't any other cases of non-first-party isolated connections.https://gitlab.torproject.org/tpo/core/tor/-/issues/19421test-network-all target does not work with out-of-tree builds2020-06-27T13:58:45Zcypherpunkstest-network-all target does not work with out-of-tree buildsThis is caused by assuming the test-driver script is the build directory. The Automake variable `LOG_DRIVER` contains the correct path.This is caused by assuming the test-driver script is the build directory. The Automake variable `LOG_DRIVER` contains the correct path.Tor: 0.2.9.x-finalcypherpunkscypherpunkshttps://gitlab.torproject.org/tpo/core/tor/-/issues/19563Test: add unit test for tor_htonll() and tor_ntohll()2020-06-27T13:58:38ZDavid Gouletdgoulet@torproject.orgTest: add unit test for tor_htonll() and tor_ntohll()Added in commit `9744a40f`.Added in commit `9744a40f`.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21266test: Improve hs intropoints unit test with expected msg log.2020-06-27T13:57:20ZDavid Gouletdgoulet@torproject.orgtest: Improve hs intropoints unit test with expected msg log.Now that legacy/trac#20029 has been merged, during review there has been a request for improving the unit tests for the failure cases to expect a log message.Now that legacy/trac#20029 has been merged, during review there has been a request for improving the unit tests for the failure cases to expect a log message.Tor: 0.3.0.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/15759test_address_get_if_addrs_[ifaddrs,win32]() will assert instead of failing gr...2020-06-27T14:01:20ZYawning Angeltest_address_get_if_addrs_[ifaddrs,win32]() will assert instead of failing gracefully.Reported here: https://lists.torproject.org/pipermail/tor-talk/2015-April/037541.html
Passing in severity of `0`, instead of `LOG_ERR` causes the logging code to assert. Mostly harmless since the test was going to fail anyway, but shou...Reported here: https://lists.torproject.org/pipermail/tor-talk/2015-April/037541.html
Passing in severity of `0`, instead of `LOG_ERR` causes the logging code to assert. Mostly harmless since the test was going to fail anyway, but should be fixed to fail in a more graceful manner.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18096test_options_validate__control fails on Windows because there are no ControlS...2020-06-27T13:59:46Zteortest_options_validate__control fails on Windows because there are no ControlSocketsThis is another issue with legacy/trac#17076.
Windows does not have unix sockets, so the error message and return value should be different.
https://jenkins.torproject.org/job/tor-ci-mingwcross-test/501/ARCHITECTURE=amd64,SUITE=jessie/...This is another issue with legacy/trac#17076.
Windows does not have unix sockets, so the error message and return value should be different.
https://jenkins.torproject.org/job/tor-ci-mingwcross-test/501/ARCHITECTURE=amd64,SUITE=jessie/console
```
02:58:18 options/validate__control: [forking] fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot
02:58:18 fixme:toolhelp:Heap32ListFirst : stub
02:58:18 fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot
02:58:18 fixme:toolhelp:Heap32ListFirst : stub
02:58:18 fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot
02:58:18 fixme:toolhelp:Heap32ListFirst : stub
02:58:18
02:58:18 FAIL src/test/test_options.c:3230: assert(ret OP_EQ 0): -1 vs 0
02:58:18 [validate__control FAILED]
```Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9265test_pt_parsing doesn't check managed_proxy_t contents2020-06-27T14:04:09ZNick Mathewsontest_pt_parsing doesn't check managed_proxy_t contentsHave a look at test_pt_parsing(). It looks to see whether parse_*() succeed or fail... but it doesn't actually check that they store the right results in managed_proxy_t! That's not what a unit test should do.Have a look at test_pt_parsing(). It looks to see whether parse_*() succeed or fail... but it doesn't actually check that they store the right results in managed_proxy_t! That's not what a unit test should do.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25398tests fail if COMPAT_HAS_MMAN_AND_PAGESIZE is not set2020-06-27T13:54:00ZAlex Xutests fail if COMPAT_HAS_MMAN_AND_PAGESIZE is not set`tor_mmap_file` doesn't check for empty files if `COMPAT_HAS_MMAN_AND_PAGESIZE` is not set, causes `test_util_mmap` to fail`tor_mmap_file` doesn't check for empty files if `COMPAT_HAS_MMAN_AND_PAGESIZE` is not set, causes `test_util_mmap` to failTor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29573Tests fail without network interface configured2022-06-17T16:19:03ZTracTests fail without network interface configuredI build packages on Linux as an unprivileged user inside a network namespace with no interfaces configured (to catch packages that try to use Internet resources during the build process). With tor 0.3.5.7 and earlier, this worked fine an...I build packages on Linux as an unprivileged user inside a network namespace with no interfaces configured (to catch packages that try to use Internet resources during the build process). With tor 0.3.5.7 and earlier, this worked fine and the test suite passed completely.
With tor 0.3.5.8, three test cases fail:
```
address/get_if_addrs_list_internal: Feb 24 12:59:28.031 [err] connect() failed: Network is unreachable
[get_if_addrs_list_internal FAILED]
address/get_if_addrs_list_no_internal: Feb 24 12:59:28.040 [err] connect() failed: Network is unreachable
[get_if_addrs_list_no_internal FAILED]
address/get_if_addrs: Feb 24 12:59:28.309 [err] connect() failed: Network is unreachable
[get_if_addrs FAILED]
```
Here's strace output for one of the failures:
```
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_UDP) = 6
connect(6, {sa_family=AF_INET, sin_port=htons(9), sin_addr=inet_addr("18.0.0.1")}, 16) = -1 ENETUNREACH (Network is unreachable)
```
So this looks like get_interface_address6_via_udp_socket_hack failing - comments in the tests suggest that they ought to be getting an empty list rather than an error in this circumstance?
**Trac**:
**Username**: atsampsonhttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/45tests for gettor2022-10-25T11:27:01Zmeskiomeskio@torproject.orgtests for gettorAt least the usecases of the gettor distributor and updater should have some tests.At least the usecases of the gettor distributor and updater should have some tests.https://gitlab.torproject.org/tpo/core/tor/-/issues/6298Tests should not depend on localhost==127.0.0.1 (Test 'addr/basic' failure in...2020-06-27T14:06:07ZAndrea ShepardTests should not depend on localhost==127.0.0.1 (Test 'addr/basic' failure in tor master)I just built branch 'master' (revision 46434ecf5b6f1ad88deb86fdac044c41ae4b534b) from the tor.git repository with gcc 4.5.3 on x86_64-linux using this configure line:
CC="gcc -m64 -mtune=core2" PKG_CONFIG_LIBDIR=/usr/lib64/pkgconfig PKG...I just built branch 'master' (revision 46434ecf5b6f1ad88deb86fdac044c41ae4b534b) from the tor.git repository with gcc 4.5.3 on x86_64-linux using this configure line:
CC="gcc -m64 -mtune=core2" PKG_CONFIG_LIBDIR=/usr/lib64/pkgconfig PKG_CONFIG_PATH=/usr/share/pkgconfig ./configure --prefix=/usr --libdir=/usr/lib64 --libexecdir=/usr/libexec64 --sysconfdir=/etc --localstatedir=/var --build=x86_64-linux --host=x86_64-linux --disable-linker-hardening --disable-asciidoc
This causes a test suite failure I haven't seen before:
addr/basic:
FAIL test_addr.c:36: assert((u32) == (0x7f000001u)): 2851995905 vs 2130706433
[basic FAILED]
Turns out the DNS in this hotel *resolves localhost to 169.254.1.1*. This is horribly wrong, of course, and I should have had a proper /etc/hosts for it anyway (*lashes self with wet noodle*), but why does the test suite depend on stuff random machines elsewhere on the network do at all to pass? Shouldn't we mock this stuff somehow?Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/20378Text-to-speech doesn't work in TBB since El Capitan2022-12-09T11:56:59ZJens KubiezielText-to-speech doesn't work in TBB since El CapitanAt [Tor.SE](https://tor.stackexchange.com) there is a [question regarding text-to-speech and Tor Browser](https://tor.stackexchange.com/q/12915/88). The user is dyslexic and recently upgraded to El Capitan (10.11.6). Since then the text-...At [Tor.SE](https://tor.stackexchange.com) there is a [question regarding text-to-speech and Tor Browser](https://tor.stackexchange.com/q/12915/88). The user is dyslexic and recently upgraded to El Capitan (10.11.6). Since then the text-to-speech software stopped working with TBB. The software reads the entire webpage instead of the text the user had selected. It worked in previous version of Moc OS X and it also does work in Firefox and Safari. So it seems to be a TBB related bug.
Do you need more information? Can you help to fix this bug?Sponsor 131 - Phase 2 - Privacy Browserhenryhenryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22028The approved-routers file isn't documented anywhere2021-07-22T16:22:39ZteorThe approved-routers file isn't documented anywhereTor directory authorities load an approved-routers file, but it isn't documented in the man page.Tor directory authorities load an approved-routers file, but it isn't documented in the man page.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/web/tpo/-/issues/75The coverage list is too long in Press2022-01-11T19:58:40ZAntonelaantonela@torproject.orgThe coverage list is too long in Presshttps://www.torproject.org/press/ has a huge list of coverage list. We need to fix this, add a pager or an exclusive page for it.https://www.torproject.org/press/ has a huge list of coverage list. We need to fix this, add a pager or an exclusive page for it.HackerNCoderhackerncoder@encryptionin.spaceHackerNCoderhackerncoder@encryptionin.spacehttps://gitlab.torproject.org/tpo/web/tpo/-/issues/173The expert bundle doesn't actually support XP, 98, etc.2021-04-12T19:59:34ZpastlyThe expert bundle doesn't actually support XP, 98, etc.On the "download the source code" page https://www.torproject.org/download/tor/ ...
Windows Expert Bundle
Windows 10, 8, 7, Vista, XP, 2000, 2003 Server, ME, and Windows 98SE
The network team doesn't support Windows versions th...On the "download the source code" page https://www.torproject.org/download/tor/ ...
Windows Expert Bundle
Windows 10, 8, 7, Vista, XP, 2000, 2003 Server, ME, and Windows 98SE
The network team doesn't support Windows versions that are past EOL. https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/SupportedPlatformshttps://gitlab.torproject.org/tpo/web/tpo/-/issues/210The onion address mentioned in the footer is still v22021-08-30T12:05:31ZsmoutwortelThe onion address mentioned in the footer is still v2The reference to the onion version of FAQ is the v2 version instead of the v3.The reference to the onion version of FAQ is the v2 version instead of the v3.