The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:56:02Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23026Rename hybrid_encrypt functions to prevent accidental use2020-06-27T13:56:02ZNick MathewsonRename hybrid_encrypt functions to prevent accidental useThe old hybrid_encrypt functions are necessary for implementing TAP and old-style hidden services, but they're also obsolete, since they produce malleable output. We shouldn't encourage anybody to use them. We should add a comment to t...The old hybrid_encrypt functions are necessary for implementing TAP and old-style hidden services, but they're also obsolete, since they produce malleable output. We shouldn't encourage anybody to use them. We should add a comment to this effect, and rename them to something less general-sounding.
See also legacy/trac#22987Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23030Review coverity build warnings2020-06-27T13:56:02ZNick MathewsonReview coverity build warningsCoverity emits a big pile of build warnings because of our BUG macro. Let's see if we can fix that. They look like this:
```
"/home/torcoverity/src/tor/cov-int/emit/totoro.wangafu.net/config/fc74ea42bbd56
ee35d2b17ca574b8e9b/...Coverity emits a big pile of build warnings because of our BUG macro. Let's see if we can fix that. They look like this:
```
"/home/torcoverity/src/tor/cov-int/emit/totoro.wangafu.net/config/fc74ea42bbd56
ee35d2b17ca574b8e9b/gcc-config-0/coverity-compiler-compat.h", line
1627: warning #41: expression must have arithmetic or pointer type
#nodef BUG() __coverity_panic__()
```
Also, there are quite a few of these:
```
"src/common/util.c", line 1169: warning #1563: function "tor_parse_long" not
emitted, consider modeling it or review parse diagnostics to improve
fidelity
tor_parse_long(const char *s, int base, long min, long max,
```Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23036'SETCONF ORPort' crashes tor without network2020-06-27T13:56:02ZDamian Johnson'SETCONF ORPort' crashes tor without networkHi Nick, on my bus commute home ran into an issue with the present git tip (tor commit bb66a48).
**Repro steps:**
* Start system without a network connection.
* Start tor, torrc I used was...
```
% cat ~/.tor/torrc
ControlPort 9051
...Hi Nick, on my bus commute home ran into an issue with the present git tip (tor commit bb66a48).
**Repro steps:**
* Start system without a network connection.
* Start tor, torrc I used was...
```
% cat ~/.tor/torrc
ControlPort 9051
ExitPolicy reject *:*
```
* Set the ORPort with "SETCONF ORPort=9090".
**Result:**
Tor process terminates with...
```
Jul 25 19:21:33.000 [warn] ControlPort is open, but no authentication method has been configured. This means that any program on your computer can reconfigure your Tor. That's bad! You should upgrade your Tor controller as soon as possible.
Jul 25 19:21:33.000 [notice] Opening OR listener on 0.0.0.0:9090
Jul 25 19:21:33.000 [notice] You are running a new relay. Thanks for helping the Tor network! If you wish to know what will happen in the upcoming weeks regarding its usage, have a look at https://blog.torproject.org/blog/lifecycle-of-a-new-relay
Jul 25 19:21:33.000 [notice] It looks like I need to generate and sign a new medium-term signing key, because I don't have one. To do that, I need to load (or create) the permanent master identity key. If the master identity key was not moved or encrypted with a passphrase, this will be done automatically and no further action is required. Otherwise, provide the necessary data using 'tor --keygen' to do it manually.
Jul 25 19:21:33.000 [notice] Your Tor server's identity key fingerprint is 'Unnamed 4853AB6F9215A837EA3562CF4AF00713737FDF01'
Jul 25 19:21:33.000 [warn] Unable to parse '/etc/resolv.conf', or no nameservers in '/etc/resolv.conf' (6)
Jul 25 19:21:33.000 [err] set_options(): Bug: Acting on config options left us in a broken state. Dying. (on Tor 0.3.2.0-alpha-dev bb66a48541aa5110)
```
Not a big whoop. Gonna disable a stem integ test tripping over this for now though.
Thanks!https://gitlab.torproject.org/tpo/core/tor/-/issues/23053Memory leak of unix_socket_path when validating multiple unix sockets2020-06-27T13:56:02ZNick MathewsonMemory leak of unix_socket_path when validating multiple unix socketsThis is CID 1415725This is CID 1415725Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23054BUG() macros shouldn't be warned as dead-code under coverity.2020-06-27T13:56:02ZNick MathewsonBUG() macros shouldn't be warned as dead-code under coverity.It's fine for our BUG() checks to be dead code: they're functionally equivalent to nonfatal assertions. Leaving them in is good defensive programming, since they prevent us from introducing bugs later on.It's fine for our BUG() checks to be dead code: they're functionally equivalent to nonfatal assertions. Leaving them in is good defensive programming, since they prevent us from introducing bugs later on.Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23055Y2106 bug in certificate expiration parsing.2020-06-27T13:56:02ZNick MathewsonY2106 bug in certificate expiration parsing.In this code:
```
const uint32_t expiration_date = rsa_ed_crosscert_get_expiration(cc);
const uint64_t expiration_time = expiration_date * 3600;
```
Coverity caught this as CID 1415728.
No backport, since all current Tor releases w...In this code:
```
const uint32_t expiration_date = rsa_ed_crosscert_get_expiration(cc);
const uint64_t expiration_time = expiration_date * 3600;
```
Coverity caught this as CID 1415728.
No backport, since all current Tor releases will be obsolete by the time anyone hits this bug.Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23056prop224: Intro point aren't transfered between services on HUP2020-06-27T13:56:01ZDavid Gouletdgoulet@torproject.orgprop224: Intro point aren't transfered between services on HUPFor the current prop224 upstream code, the `move_intro_points()` function doesn't work as expected, actually it's very broken.
First of all, it is impossible to move intro points with the current condition because the newly created serv...For the current prop224 upstream code, the `move_intro_points()` function doesn't work as expected, actually it's very broken.
First of all, it is impossible to move intro points with the current condition because the newly created service (`dst`) doesn't have any descriptor. Thus, this if() is basically dead code and we never move intro points.
```
if (src->desc_current && dst->desc_current) {
move_descriptor_intro_points(src->desc_current, dst->desc_current);
...
```
The fix is to move the *descriptor(s)* and not only the intro points because the service needs the descriptor signing key that cross certify every IP authentication key. So, we really need to move the full thing from one service to the other else we would have to re-sign everything.Tor: 0.3.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/23061crypto_rand_double() should produce all possible outputs on platforms with 32...2022-06-17T13:46:12Zteorcrypto_rand_double() should produce all possible outputs on platforms with 32-bit intOn 32-bit platforms, crypto_rand_double() only produces 1 in every 2 million possible values between 0 and 1.
This happens because:
* crypto_rand_double() divides a random unsigned int by UINT_MAX
* an unsigned int on 32-bit platforms i...On 32-bit platforms, crypto_rand_double() only produces 1 in every 2 million possible values between 0 and 1.
This happens because:
* crypto_rand_double() divides a random unsigned int by UINT_MAX
* an unsigned int on 32-bit platforms is 32 bits
* the mantissa on a double is 53 bits
So crypto_rand_double() doesn't fill the lower 21 bits with random values.
This makes the rep_hist_format_hs_stats() noise more predictable on 32-bit platforms.
This fix shouldn't affect the unit tests, because they pass on 64-bit.https://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/23071test_hs_ntor.sh fails with recent pysha32020-06-27T13:56:01ZNick 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/tpo/core/tor/-/issues/23076Should HSes use Stable nodes for services on long lived ports?2022-06-17T16:36:56ZGeorge KadianakisShould HSes use Stable nodes for services on long lived ports?When a hidden service sets up its circuits, it uses `rend_service_requires_uptime()` to check the type of service it's setting up, and if it's setting up a long-lived service (e.g. SSH, etc.) it will only use Stable nodes for its rendezv...When a hidden service sets up its circuits, it uses `rend_service_requires_uptime()` to check the type of service it's setting up, and if it's setting up a long-lived service (e.g. SSH, etc.) it will only use Stable nodes for its rendezvous circuits.
We should consider if this is a good idea wrt security, and potentially kill this feature if we think it restricts our path selection too much or reveals too much info to the RPs.https://gitlab.torproject.org/tpo/core/tor/-/issues/23077Channelpadding tests rely on actual time; can fail2020-06-27T13:56:00ZNick MathewsonChannelpadding tests rely on actual time; can failWe're seeing an intermittent failure on Jenkins:
```
14:46:53 channelpadding/channelpadding_consensus: [forking]
14:46:53 FAIL ../tor/src/test/test_channelpadding.c:445: assert(decision OP_EQ CHANNELPADDING_PADDING_SCHEDULED): 4 vs 2...We're seeing an intermittent failure on Jenkins:
```
14:46:53 channelpadding/channelpadding_consensus: [forking]
14:46:53 FAIL ../tor/src/test/test_channelpadding.c:445: assert(decision OP_EQ CHANNELPADDING_PADDING_SCHEDULED): 4 vs 2
14:46:53 [channelpadding_consensus FAILED]
```
Looking at the code, it seems that the underlying channelpadding code depends on the actual time (from `monotime_coarse_abosolute_*()`) to make its decisions. But we aren't doing anything to mock those functions from inside the test case, which may be making the outcome of this test dependent on the code running fast enough.Tor: 0.3.1.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23078hs: Forgotten log_warn for prop224 intro point2020-06-27T13:56:00ZDavid Gouletdgoulet@torproject.orghs: Forgotten log_warn for prop224 intro pointTurns out we forgot to remove that log statement from `hs_intropoint.c`:
```
log_warn(LD_GENERAL, "Established prop224 intro point on circuit %" PRIu32,
circ->p_circ_id);
```
It has been reported here: https://lists.torpr...Turns out we forgot to remove that log statement from `hs_intropoint.c`:
```
log_warn(LD_GENERAL, "Established prop224 intro point on circuit %" PRIu32,
circ->p_circ_id);
```
It has been reported here: https://lists.torproject.org/pipermail/tor-relays/2017-August/012689.html
As far as I can tell, it seems the only warning that is misplaced and that one is unneeded.
However, I might want to take the opportunity to change 3 `log_warn()` and put them to protocol warning level instead.
```
log_warn(LD_REND, "Unable to send INTRODUCE2 cell to the service.");
...
log_warn(LD_REND, "Unable to send an INTRODUCE ACK status %d to client.",
status);
...
log_warn(LD_BUG, "Couldn't send INTRO_ESTABLISHED cell.");
```
They've been introduced in `tor-0.3.0.1-alpha` and `tor-0.3.0.2-alpha`.Tor: 0.3.0.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/23079Support 80-bit Onion Model In Perpetuity2020-06-27T13:56:00ZcypherpunksSupport 80-bit Onion Model In PerpetuityAs has been outlined by various persons on IRC, the email lists, onion services and even clearnet blogs, over the recent years ever since prop224 came to be proposed...
The current 80-bit model of onion addressing needs to be continued ...As has been outlined by various persons on IRC, the email lists, onion services and even clearnet blogs, over the recent years ever since prop224 came to be proposed...
The current 80-bit model of onion addressing needs to be continued in perpetuity[1] as a legacy compatibility mode of onion addressing.
This mode has proven critical to users and communities in onionland that use OnionCat, OnionVPN, and other tools to achieve various communication models and application support, including interoperation with other networks, that is highly relavant to them.
It is expressly understood by this userbase that this legacy, perhaps even parallel, mode of operation will entail tradeoffs to prop224, including potentially enhanced anonymity risks, among other risks, and that code and bug support may be delayed vs prop224, and that those and other tradeoffs and issues are deemed acceptable to the legacy community.
[1] Or at least until a formal bi-directional resolution layer / registry / DHT or other mechanism is developed for prop224 (or any subsequent addressing proposal), for which in part, at least a deterministic 40+80 = resultant 128-bit IPV6 network stack interface compatible mode of operation is available that can supply what OnionCat/OnionVPN do today.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23080connection_ext_or_handle_cmd_useraddr and proposal 196 disagree on the format...2020-06-27T13:56:00ZDavid Fifielddcf@torproject.orgconnection_ext_or_handle_cmd_useraddr and proposal 196 disagree on the format of ExtORPort USERADDR(Originally noticed in comment:3:ticket:18628.)
Proposal 196, which defines the ExtORPort protocol, implies that the USERADDR command must include a port number, [here](https://gitweb.torproject.org/torspec.git/tree/proposals/196-transp...(Originally noticed in comment:3:ticket:18628.)
Proposal 196, which defines the ExtORPort protocol, implies that the USERADDR command must include a port number, [here](https://gitweb.torproject.org/torspec.git/tree/proposals/196-transport-control-ports.txt?id=f59e8f5b2819842fe6cb5b162a9226a4f1891b4d#n72):
```
[0x0001] USERADDR: an address:port string that represents the
client's address.
```
and [here](https://gitweb.torproject.org/torspec.git/tree/proposals/196-transport-control-ports.txt?id=f59e8f5b2819842fe6cb5b162a9226a4f1891b4d#n97):
```
3.1.2.1. USERADDR
An ASCII string holding the TCP/IP address of the client of the
pluggable transport proxy.
```
But [connection_ext_or_handle_cmd_useraddr](https://gitweb.torproject.org/tor.git/tree/src/or/ext_orport.c?h=tor-0.3.0.9#n434) calls [tor_addr_port_split](https://gitweb.torproject.org/tor.git/tree/src/common/address.c?h=tor-0.3.0.9#n1895), which makes the port number optional.
It seems that connection_ext_or_handle_cmd_useraddr in fact accepts all these formats for USERADDR:
* `1.2.3.4` (implied port=0)
* `1.2.3.4:5678`
* `1:2::3:4` (implied port=0)
* `[1:2::3:4]` (implied port=0)
* `[1:2::3:4]:5678`
If this is intended, then I'd like proposal 196 to say that the port is optional, and square brackets are optional in the case of IPv6.
For what it's worth, [obfs4proxy](https://gitweb.torproject.org/pluggable-transports/obfs4.git/tree/obfs4proxy/obfs4proxy.go?h=obfs4proxy-0.0.7#n254) and [meek-server](https://gitweb.torproject.org/pluggable-transports/meek.git/tree/meek-server/meek-server.go?h=0.28#n142) take proposal 196 at face value and always include a port in USERADDR (meek-server always uses the fictitious port number 1 because it doesn't know the true remote port).Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/community/l10n/-/issues/40059Translate to Russian the 'Relay Post-install and good practices' page in com...2022-05-24T17:45:02ZemmapeelTranslate to Russian the 'Relay Post-install and good practices' page in community portalThis page: https://community.torproject.org/relay/setup/post-install/
Russian preview: https://review.torproject.net/tpo/web/community/l10n/ru/relay/setup/post-install/
It has 97 strings (1379 words).
I have added it to the tag `cens...This page: https://community.torproject.org/relay/setup/post-install/
Russian preview: https://review.torproject.net/tpo/web/community/l10n/ru/relay/setup/post-install/
It has 97 strings (1379 words).
I have added it to the tag `censorship-docs`
Can be found in Transifex with this link: https://www.transifex.com/otf/tor-project-support-community-portal/translate/#ru/communitytpo-contentspot/187579968?q=occurrence%3Arelay%2Fsetup%2Fpost-install%2FSponsor 125: Rapid Response Fund for Russia censorship circumventionemmapeelemmapeelhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23081Tor relay crashes at consensus_diff_queue_diff_work() with assertion in_main_...2020-06-27T13:56:00ZTracTor relay crashes at consensus_diff_queue_diff_work() with assertion in_main_thread() failedWhen I start a relay with latest Tor version, it almost instantly crashes:
```
Aug 02 11:04:45.000 [err] tor_assertion_failed_(): Bug: consdiffmgr.c:1601: consensus_diff_queue_diff_work: Assertion in_main_thread() failed; aborting. (on ...When I start a relay with latest Tor version, it almost instantly crashes:
```
Aug 02 11:04:45.000 [err] tor_assertion_failed_(): Bug: consdiffmgr.c:1601: consensus_diff_queue_diff_work: Assertion in_main_thread() failed; aborting. (on Tor 0.3.1.5-alpha )
Aug 02 11:04:45.000 [err] Bug: Assertion in_main_thread() failed in consensus_diff_queue_diff_work at consdiffmgr.c:1601. (Stack trace not available) (on Tor 0.3.1.5-alpha )
```
OS: Windows 7 SP1 x64
Tor: 0.3.1.5-alpha x64 (custom MSYS2 build)
**Trac**:
**Username**: VortTor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23082tor_addr_parse is overly permissive2020-06-27T13:56:00ZDavid Fifielddcf@torproject.orgtor_addr_parse is overly permissivetor_addr_parse allows these surprising address formats:
* `[192.0.2.1]` (IPv4 in square brackets) → 192.0.2.1
* `[11.22.33.44` (IPv4 with left square bracket only) → 11.22.33.4
* `[11:22::33:44` (IPv6 with left square bracket only) → ...tor_addr_parse allows these surprising address formats:
* `[192.0.2.1]` (IPv4 in square brackets) → 192.0.2.1
* `[11.22.33.44` (IPv4 with left square bracket only) → 11.22.33.4
* `[11:22::33:44` (IPv6 with left square bracket only) → 11:22::33:4
* `11:22::33:44:` (IPv6 with trailing colon) → 11:22::33:44Tor: 0.4.0.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/23090Sandbox failure on Debian 8.9 under OpenVZ with kernel version 2.6.322020-06-27T13:55:59ZteorSandbox failure on Debian 8.9 under OpenVZ with kernel version 2.6.32A relay operator reports a sandbox failure on Tor 0.3.0.9 with the following log lines:
```
sandbox_getaddrinfo(): (Sandbox) getaddrinfo succeeded.
sandbox_getaddrinfo(): (Sandbox) getaddrinfo failed.
sandbox_getaddrinfo(): (Sandbox) get...A relay operator reports a sandbox failure on Tor 0.3.0.9 with the following log lines:
```
sandbox_getaddrinfo(): (Sandbox) getaddrinfo succeeded.
sandbox_getaddrinfo(): (Sandbox) getaddrinfo failed.
sandbox_getaddrinfo(): (Sandbox) getaddrinfo succeeded.
install_syscall_filter(): Bug: (Sandbox) failed to load: -22 (Invalid argument)! (on Tor 0.3.0.9 )
tor_main(): Bug: Failed to create syscall sandbox filter (on Tor 0.3.0.9 )
main process exited, code=exited, status=1/FAILURE
```
See https://lists.torproject.org/pipermail/tor-relays/2017-August/012694.htmlTor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23091Broken condition in check_expired_networkstatus_callback()2020-06-27T13:55:59ZDavid Gouletdgoulet@torproject.orgBroken condition in check_expired_networkstatus_callback()Turns out that this condition in `check_expired_networkstatus_callback()`:
```
if (ns && ns->valid_until < now+NS_EXPIRY_SLOP &&
router_have_minimum_dir_info()) {
router_dir_info_changed();
}
```
... is always true if we ...Turns out that this condition in `check_expired_networkstatus_callback()`:
```
if (ns && ns->valid_until < now+NS_EXPIRY_SLOP &&
router_have_minimum_dir_info()) {
router_dir_info_changed();
}
```
... is always true if we have all our needed directory info which means that `router_dir_info_changed()` is called every 2 minutes (the callback interval).
Nick suggested that it should be `now - NS_EXPIRY_SLOP` which goes like this:
If `valid_until` is 6am today, then `now - 24h` == 1pm yesterday, and `valid_until < (now - 24h)` is false. But at 6:01am tomorrow, `valid_until < now - 24h` becomes true.Tor: 0.3.2.x-final