The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-09-01T21:29:26Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26076test_keygen.sh and test_key_expiration.sh fail on Windows2022-09-01T21:29:26ZTractest_keygen.sh and test_key_expiration.sh fail on Windows```
FAIL: src/test/test_keygen.sh
=============================
May 11 01:50:30.175 [warn] Path for GeoIPFile (<default>) is relative and will resolve to C:\projects\appveyor\i686-w64-mingw32\<default>. Is this what you wanted?
May 11 01...```
FAIL: src/test/test_keygen.sh
=============================
May 11 01:50:30.175 [warn] Path for GeoIPFile (<default>) is relative and will resolve to C:\projects\appveyor\i686-w64-mingw32\<default>. Is this what you wanted?
May 11 01:50:30.175 [warn] Path for GeoIPv6File (<default>) is relative and will resolve to C:\projects\appveyor\i686-w64-mingw32\<default>. Is this what you wanted?
Tor didn't declare that there would be no encryption
FAIL src/test/test_keygen.sh (exit status: 5)
SKIP: src/test/fuzz_static_testcases.sh
```
Edit: when we fix this bug, we should revert legacy/trac#26830 and legacy/trac#26853, which skips these tests on Windows
**Trac**:
**Username**: saperhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26072Malformed connected cell closes connection but code continues2020-06-27T13:53:27ZMike PerryMalformed connected cell closes connection but code continuesIn connection_edge_process_relay_cell_not_open(), there is a clause that closes the connection if the connected cell is malformed. However, it does not return from the function. Every other clause where the connection is closed does retu...In connection_edge_process_relay_cell_not_open(), there is a clause that closes the connection if the connected cell is malformed. However, it does not return from the function. Every other clause where the connection is closed does return.
This looks like a bug. I couldn't immediately find any issues with this, though. Perhaps an assert if the connection gets marked twice..Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26070Remove remaining items from second_elapsed_callback and run_scheduled_events.2022-06-17T17:33:59ZNick MathewsonRemove remaining items from second_elapsed_callback and run_scheduled_events.In legacy/trac#25375 we removed a bunch of stuff from these once-a-second functions, to the point where it's safe to disable them when the net is off.
Still, though, it would be cool to remove even more stuff, since we have better mecha...In legacy/trac#25375 we removed a bunch of stuff from these once-a-second functions, to the point where it's safe to disable them when the net is off.
Still, though, it would be cool to remove even more stuff, since we have better mechanisms to handle most of these, and since it would help us use less CPU in the non-disablenetwork case.https://gitlab.torproject.org/tpo/core/tor/-/issues/26069hs-v3: Descriptor signature parsing should have a trailing white-space2021-09-30T13:46:30ZDavid Gouletdgoulet@torproject.orghs-v3: Descriptor signature parsing should have a trailing white-spaceFrom ticket legacy/trac#25552, nickm's comment:
I've reviewed the PR. The biggest issue is related to the use of "\n" signature_str, which I believe should be "\n" signature_str " " instead.
We'll fix it in legacy/trac#25552 for 034 b...From ticket legacy/trac#25552, nickm's comment:
I've reviewed the PR. The biggest issue is related to the use of "\n" signature_str, which I believe should be "\n" signature_str " " instead.
We'll fix it in legacy/trac#25552 for 034 but we need to backport it back to 030 when it was first introduced. It won't affect any tor version on the ability to parse service descriptors. It will just reinforce the security and correctness.Tor: 0.3.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/26064Use a mainloop timer to wake up from hibernation.2020-06-27T13:53:28ZNick MathewsonUse a mainloop timer to wake up from hibernation.In lieu of legacy/trac#25950, we can do a much simpler version: when we go dormant, schedule a timer to wake up at a later time.In lieu of legacy/trac#25950, we can do a much simpler version: when we go dormant, schedule a timer to wake up at a later time.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26063Disable the per-second timer when we can2020-06-27T13:53:28ZNick MathewsonDisable the per-second timer when we canOnce the children of legacy/trac#25375 are merged, there will be nothing left in second_elapsed_callback that needs to happen once per second when Tor isn't running. Once we're in that position, we can disable this callback whenever..
...Once the children of legacy/trac#25375 are merged, there will be nothing left in second_elapsed_callback that needs to happen once per second when Tor isn't running. Once we're in that position, we can disable this callback whenever..
1. we are completely hibernating (state == DORMANT) OR the network is disabled.
2. The controller is not waiting for any per-second events.
This change will require some related refactoring.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26062client: ControlPort set doesn't mean you're a client2020-06-27T13:53:28ZDavid Gouletdgoulet@torproject.orgclient: ControlPort set doesn't mean you're a clientSplitting from legacy/trac#19665 to avoid confusion.
This ticket is solely to make a patch so that when the ControlPort is set (Unix or not), we do *not* consider it as a client with `any_client_port_set()`.Splitting from legacy/trac#19665 to avoid confusion.
This ticket is solely to make a patch so that when the ControlPort is set (Unix or not), we do *not* consider it as a client with `any_client_port_set()`.Tor: 0.3.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/26052man page still says CacheIPv4DNS is on by default2020-06-27T13:53:28ZRoger Dingledineman page still says CacheIPv4DNS is on by defaultin legacy/trac#24050 we made the SocksPort CacheIPv4DNS flag off by default, but we never fixed the man page to say it's off by default.in legacy/trac#24050 we made the SocksPort CacheIPv4DNS flag off by default, but we never fixed the man page to say it's off by default.Tor: 0.3.3.x-finalRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/core/tor/-/issues/26042Add a new option "RouteDNSTraffic" to prevent noobs from insecure way to use ...2020-06-27T13:53:28ZcypherpunksAdd a new option "RouteDNSTraffic" to prevent noobs from insecure way to use Tor.RouteDNSTraffic 1
(default: 1, enabled.)
Analyzed my exit node's traffic, I noticed many users is sending DNS traffic over Tor, expecially targeting 8.8.8.8.
Tor itself should reroute the tcp port 53 request to TorDNS system
to preven...RouteDNSTraffic 1
(default: 1, enabled.)
Analyzed my exit node's traffic, I noticed many users is sending DNS traffic over Tor, expecially targeting 8.8.8.8.
Tor itself should reroute the tcp port 53 request to TorDNS system
to prevent linking.
https://nakedsecurity.sophos.com/2016/10/05/unmasking-tor-users-with-dns/
https://lists.torproject.org/pipermail/tor-relays/2016-May/009255.html
Before:
User === Tor ----- Tor node ---> 8.8.8.8
After:
User === Tor[ --reroute-to-TorDNS-system ]<--->Tor nodeTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26041Set Default version to 3 for new onion; V2 onion can be cracked easily2020-06-27T13:53:28ZcypherpunksSet Default version to 3 for new onion; V2 onion can be cracked easilyCurrently, the user should add 'Version 3' to torrc to generate V3 onion.
I want you to use V3 by default.
e.g.: HidServ /keys/onion/
Scan /keys/onion/,
a1. Is V3 hostname file exist? ===> use V3 only and ignore V2 onion
a2. Is V2 host...Currently, the user should add 'Version 3' to torrc to generate V3 onion.
I want you to use V3 by default.
e.g.: HidServ /keys/onion/
Scan /keys/onion/,
a1. Is V3 hostname file exist? ===> use V3 only and ignore V2 onion
a2. Is V2 hostname file exist? ===> use V2 only (and ignore V3)
a3. Both file is not exist ===> Then, generate V3 onion.
I've successfully generated "already-exist onion's private key".
-----BEGIN RSA PRIVATE KEY-----
MIICXgIBAAKBgQDPquVHKOacJ/fgY6G3vzbO4KgUYxRN5qlaysnKsApWBuGKWyoE
irps1kmiPG1ewAxDYzrQtFzC14f94z8urN64SY8IaRgu76FHS5XeRDQ5AzIi54FH
gHMEhbEReM5gRdxftgMto9Jhi+AoKO/VPhVlaIZyB7C223CiVyc299Qe7QIDAQAB
AoGAalUSAybBNhINDRtW0fQZx0InLhExc1X5P2D4hE0xba0mTSay1BKItHPgzi5s
vghN/y9PDVBc8vNTUb/LOUYQ35SBaEZKw0/TM+rnv/cHvnelPsrkyZmkr5HiQiUM
p4cIwYO3VlF6NsGjhwZ3d0VJXSrsy6lUIYFjZFMB1OJ0H80CQQD/n76S6MHFKv6N
9Imx2NCtQxYU/pbHMdUZOuG2MvpwmbkIYxO85AWxbp+9OMgr1s04kKtT9fhSM1iK
R5/ZSqPDAkEAz/kX1viCd/l2qGD9bfJsd6+TNdsoaply7y7B/pgJZan4tQyi0Vha
CexMW/M+j64hwWdTmP34ewcYbG+45cF3jwJBAPcs9W9C6BOKdmi3m+m/2FChfRnB
7/QfSIrD9/thIe99hYEJpM1Sw/qFGKs028IgS4K1ySU/w+VgRu43QecwGFcCQQCd
ziSIuYhGAMRIf0/NXWVwa4kIFINWX5kWZCRPSo3W1mIg/rWMo72uSd6m5qtR2o9C
cWS9cfhZYcjmft+Ndn+BAkEArSW4oN9RibSh3JG0zstWTF6al6zPuhNxfB57MLaE
HCS2yJf2vvWVTs9ZYBUEZUNX0OJ5doW5kl20gkXrsY4RKw==
-----END RSA PRIVATE KEY-----
I used 4 nvidia GPU and this took about 1 week.
All V2 hosting admins should use V3.https://gitlab.torproject.org/tpo/core/tor/-/issues/26040Improve getrandom handling2020-06-27T13:53:28ZAlex XuImprove getrandom handlinghttps://cgit.alxu.ca/tor.git/commit/?h=better-getrandom
Improve getrandom handling.
Do not check for EINTR and EAGAIN because getrandom is documented to
never return those if size < 256 and flags = 0.
Also revise obsolete and inaccura...https://cgit.alxu.ca/tor.git/commit/?h=better-getrandom
Improve getrandom handling.
Do not check for EINTR and EAGAIN because getrandom is documented to
never return those if size < 256 and flags = 0.
Also revise obsolete and inaccurate comment.Tor: unspecifiedAlex XuAlex Xuhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26038Misc Rust/Cargo improvements (incl. use global cargo cache)2020-06-27T13:53:29ZAlex XuMisc Rust/Cargo improvements (incl. use global cargo cache)https://cgit.alxu.ca/tor.git/log/?h=misc-rust
for discussion (since nobody cared on #tor-dev): should we use the global cargo cache? I think most C+Rust projects still use the global cache. I tried searching GitHub (https://github.com/s...https://cgit.alxu.ca/tor.git/log/?h=misc-rust
for discussion (since nobody cared on #tor-dev): should we use the global cargo cache? I think most C+Rust projects still use the global cache. I tried searching GitHub (https://github.com/search?q=%22CARGO_HOME%22+extension%3Aam&type=Code). I found that tor is the only project that does not. for users who do not care, using the global cache will save download time and bandwidth on repeat builds, and for those who do care, my patch prints a warning so they will know. (maybe it should be downgraded to NOTICE?)Tor: unspecifiedAlex XuAlex Xuhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26036macOS regression in crypto_rand.c refactor2021-09-16T14:30:52ZTaylor YumacOS regression in crypto_rand.c refactorThe refactoring that created crypto_rand.c is missing includes of sys/syscall.h and sys/random.h. sys/random.h is needed for `getentropy()` on macOS 10.12 Sierra. Omitting sys/syscall.h might also cause us to fail to detect a `getrando...The refactoring that created crypto_rand.c is missing includes of sys/syscall.h and sys/random.h. sys/random.h is needed for `getentropy()` on macOS 10.12 Sierra. Omitting sys/syscall.h might also cause us to fail to detect a `getrandom()` syscall on Linux when that's supported.Tor: 0.3.4.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26034LibreSSL 2.7.x supports some OpenSSL 1.1 APIs?2020-07-28T19:13:08ZNick MathewsonLibreSSL 2.7.x supports some OpenSSL 1.1 APIs?Toralf points me towards this Python patch:
https://github.com/gentoo/gentoo/blob/master/dev-lang/python/files/python-3.5.5-libressl-compatibility.patch
It implies that for Python's purposes at least, LibreSSL 2.7.x supports the newer ...Toralf points me towards this Python patch:
https://github.com/gentoo/gentoo/blob/master/dev-lang/python/files/python-3.5.5-libressl-compatibility.patch
It implies that for Python's purposes at least, LibreSSL 2.7.x supports the newer openssl APIs. We should test that out, and if so, support it.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26025make distcheck failing for rust builds due to missing include2020-06-27T13:53:29ZIsis Lovecruftmake distcheck failing for rust builds due to missing includeThe `src/rust/external/crypto_rand.rs` file added in legacy/trac#24660 is missing from `src/rust/include.am` [causing make distcheck to fail](https://travis-ci.org/isislovecruft/tor/builds/375098348).The `src/rust/external/crypto_rand.rs` file added in legacy/trac#24660 is missing from `src/rust/include.am` [causing make distcheck to fail](https://travis-ci.org/isislovecruft/tor/builds/375098348).Tor: 0.3.4.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/core/tor/-/issues/26024cargo vendor rand-0.5.0-pre.1 dependency2020-06-27T13:53:29ZIsis Lovecruftcargo vendor rand-0.5.0-pre.1 dependencyI think we can also remove the `src/ext/rust/vendor/rand-8c5b0ac51d` manually vendored dependency (and if not, we can at least definitely remove `src/ext/rust/vendor/rand-8c5b0ac51d/master.zip`).
This is currently [breaking Travis build...I think we can also remove the `src/ext/rust/vendor/rand-8c5b0ac51d` manually vendored dependency (and if not, we can at least definitely remove `src/ext/rust/vendor/rand-8c5b0ac51d/master.zip`).
This is currently [breaking Travis builds](https://travis-ci.org/torproject/tor/jobs/374671123), and doing this [fixes the builds](https://travis-ci.org/isislovecruft/tor/builds/375039767).Tor: 0.3.4.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/core/tor/-/issues/26016Replace n_libevent_errors logic with a rate-limiter.2020-06-27T13:53:30ZNick MathewsonReplace n_libevent_errors logic with a rate-limiter.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26014Fix two cases of nondeterminism in voting_schedule.c coverage2020-06-27T13:53:30ZNick MathewsonFix two cases of nondeterminism in voting_schedule.c coverageAfter another set of coverage-comparison testing, I found the following to cases of nondeterminism in the tests for voting_schedule.c:
```
--- a/voting_schedule.c.gcov
+++ b/voting_schedule.c.gcov
@@ -61,7 +61,7 @@
-:
...After another set of coverage-comparison testing, I found the following to cases of nondeterminism in the tests for voting_schedule.c:
```
--- a/voting_schedule.c.gcov
+++ b/voting_schedule.c.gcov
@@ -61,7 +61,7 @@
-:
1: next += offset;
1: if (next - interval > now)
- #####: next -= interval;
+ 1: next -= interval;
-:
1: return next;
-:}
```
```
--- a/voting_schedule.c.gcov
+++ b/voting_schedule.c.gcov
@@ -52,7 +52,7 @@
-:
-: /* Intervals never cross midnight. */
1: if (next > midnight_tomorrow)
- #####: next = midnight_tomorrow;
+ 1: next = midnight_tomorrow;
-:
-: /* If the interval would only last half as long as it's supposed to, then
-: * skip over to the next day. */
```
I think that these changes are probably dependent on using clock time for our tests, since they all happened around 0:00 UTC.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26011Alias GETINFO config-can-saveconf to config/can-saveconf2020-06-27T13:53:30ZteorAlias GETINFO config-can-saveconf to config/can-saveconfBecause we have a config/ hierarchy, so we should use it.
This will also need a control spec patch.Because we have a config/ hierarchy, so we should use it.
This will also need a control spec patch.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26009Remove management of approx_time() from second_elapsed_callback2020-06-27T13:53:30ZNick MathewsonRemove management of approx_time() from second_elapsed_callbackTor: 0.3.4.x-finalNick MathewsonNick Mathewson