Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2021-09-16T14:21:51Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33898Stop modifying addr on connections, and delete real_addr2021-09-16T14:21:51ZteorStop modifying addr on connections, and delete real_addrIn connection_or_check_canonicity(), we overwrite conn.addr with the canonical address of the relay in the consensus. That makes accurate logging impossible.
And so we also need channel.real_addr, to store the actual address of the remo...In connection_or_check_canonicity(), we overwrite conn.addr with the canonical address of the relay in the consensus. That makes accurate logging impossible.
And so we also need channel.real_addr, to store the actual address of the remote peer. And for some reason, we also have conn.address, a string copy of the peer's canonical address and port.
See:
https://github.com/torproject/tor/blob/7f9eaec538b7d01e0d1b130dc4cf2ec634252d46/src/core/or/connection_or.c#L920
This is... a mess.
Here's the high-level interface I'd like to see:
* use a function to format a connection or channel addresses for loogging
* use exactly as many address and port variables as needed in connection and channel (no extras!)
* qualify each address and port variable's name with its purpose
For example, here's one possible design:
* delete addr, port, address, and real_addr
* add remote_ap, a tor_addr_port_t that is the remote address and port of the TCP connection to the remote peer
* implement connection_describe(), which:
* formats remote_ap,
* formats is_canonical (and any other useful info), and
* calls node_describe() to format the canonical IPv4 and IPv6 addresses and ports of the remote peer.
We may also need separate fields for reverse proxied addresses, see the comment at:
https://github.com/torproject/tor/blob/7517e1b5d31aada1f594c2594737a231d9d8e116/src/core/or/channeltls.c#L1339
If we need separate variables or functions for channels, we can use a similar design. (But ideally, re-using as many functions and variables as possible.)
This is important for Sponsor 55: getting accurate connection information will make diagnosing bugs much easier.
Current subtasks:
* [x] #40040 Document behavior of addr/address/real_addr fields
* [x] #40041 Add "describe connection" and "describe peer" functions.
* [ ] #40042 Give `or_connection_t` "canonical addr" instead of "real addr"Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33883Fix typo in router_build_fresh_unsigned_routerinfo() comment2020-06-27T13:47:53ZNeel Chauhanneel@neelc.orgFix typo in router_build_fresh_unsigned_routerinfo() commentThis comment in `router_build_fresh_unsigned_routerinfo()`:
```
/* If there is no valud IPv6 ORPort, the address and port are null. */
```
should be:
```
/* If there is no valid IPv6 ORPort, the address and port are null. */
```This comment in `router_build_fresh_unsigned_routerinfo()`:
```
/* If there is no valud IPv6 ORPort, the address and port are null. */
```
should be:
```
/* If there is no valid IPv6 ORPort, the address and port are null. */
```Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33880Confusing "Your relay has a very large number of connections to other relays"...2021-07-09T17:22:52ZRoger DingledineConfusing "Your relay has a very large number of connections to other relays" relay messageA new relay operator reports this complaint in their logs, showing up hourly:
```
Your relay has a very large number of connections to other relays. Is your
outbound address the same as your relay address? Found 13 connections to 8
relay...A new relay operator reports this complaint in their logs, showing up hourly:
```
Your relay has a very large number of connections to other relays. Is your
outbound address the same as your relay address? Found 13 connections to 8
relays. Found 13 current canonical connections, in 0 of which we were a
non-canonical peer. 5 relays had more than 1 connection, 0 had more than 2, and
0 had more than 4 connections.
```
I checked, and their outbound address was the same as their relay address.
Upon investigation, it looks like the redundant connections are to directory authorities.
My theory is that the change from legacy/trac#17592 (which went into 0.3.1.1-alpha, commit d5a151a0) is responsible: while before that canonical relay-to-relay connections would expire after either side first reached its randomized "15 to 22.5 minute" timeout, now they expire after either side reaches its "45 to 75 minute" timeout. And since directory authorities test reachability every 1280 seconds (around 21.3 minutes), that means it is expected that most relays will have duplicate canonical connections with directory authorities.
Possible fixes:
(A) Change the notice-level log to make it clearer that it's not scary, or at least it's not actionable. Maybe that means making it info-level so nobody will see it. Probably not the best option, assuming there *are* cases where we do want relay operators to hear it.
(B) In channel_check_for_duplicates(), change `MIN_RELAY_CONNECTIONS_TO_WARN 5` to a high enough number that even if we have 2 canonical conns per authority, plus a bit more, the log message still doesn't trigger.
(C) In channel_check_for_duplicates(), skip over connections to directory authorities in some way, since we know they will be special.
(D) Make connections to or from directory authorities expire quicker, on the theory that they don't really need the same level of padding protection as other connections.
(E) Your idea here?
I'd be fine with any of B,C,D. Whichever one can be done with an easy, short, and non-invasive patch is my favorite. Maybe that's "B, raise it to 30"? That would make the message trigger when we have connections to more than 30 relays and also we have more than 45 connections open. Or we could pick the more conservative "raise it to 40", on the theory that small numbers are more likely to have edge cases and less indicative of major network problems anyway.
And while we're at it, it might be smart to say in the log message what action we want the relay operator take, e.g. "Please report:".Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33873client: Send back SOCKS extended error F6 in case of bad hostname2021-06-23T17:22:42ZDavid Gouletdgoulet@torproject.orgclient: Send back SOCKS extended error F6 in case of bad hostnameWith the new awesome TB 9.5a11, the SocksPort `ExtendedErrors` are being handled.
Passing an invalid v3 address that is of the right length in bytes, will send back the `F6` error but not for an invalid address like: `asijdijasdoijqwoie...With the new awesome TB 9.5a11, the SocksPort `ExtendedErrors` are being handled.
Passing an invalid v3 address that is of the right length in bytes, will send back the `F6` error but not for an invalid address like: `asijdijasdoijqwoieqw.onion`.
Problem is that we only send back the `F6` code if the address was identified, by length, as a v3. We should handle the `BAD_HOSTNAME` error code from `parse_extended_hostname()` and thus send back that extended error.Tor: 0.4.4.x-finalGuinnessGuinnesshttps://gitlab.torproject.org/tpo/core/tor/-/issues/33870vanguards: Vanguards silently fail on certain condition2020-07-30T18:47:31Zcypherpunksvanguards: Vanguards silently fail on certain condition1. Configure torrc file (add some HiddenService lines)
2. Edit vanguards.conf like below:
```
# IP address that the Tor control port is listening on:
control_ip =
# TCP port the control port is listening on:
control_port =
# If set,...1. Configure torrc file (add some HiddenService lines)
2. Edit vanguards.conf like below:
```
# IP address that the Tor control port is listening on:
control_ip =
# TCP port the control port is listening on:
control_port =
# If set, use this filesystem control socket instead of IP+Port:
control_socket = /run/tor/control
# If set, use this as the control port password:
control_pass =
```
```
# The current loglevel:
loglevel = NOTICE
# If specified, log to this file instead of stdout:
logfile = /tmp/vandebugger
```
3. Restart vanguards (service vanguards stop;service vanguards start)
4. Run 'ps axu|grep pypy' - you'll find vanguards is running
5. Now wait 1 minute
---
What will happen:
1. Vanguards silently exit itself. /tmp/vandebugger logged nothing.
2. However if you read syslog you'll find this line:
```
Specified config file /meow/vanguards.conf can't be read: invalid literal for int() with base 10: ''
```
How to fix:
Setting 'control_port = ' to 'control_port = 9876' fixed this.
What do I want:
Error should not be raised if the user set 'control_port' empty string.
#NoGithub #ILikeYourAddonMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33850log rotation for /var/log/tor/debug.log did not close handle to old file afte...2020-10-29T15:21:31ZTraclog rotation for /var/log/tor/debug.log did not close handle to old file after compressionso / ran full after a week or so. I found the culprits with:
find /proc/*/fd -ls | grep '(deleted)'
Version: tor 0.4.2.7-1~d8.jessie+1
Config:
Standard torrc with one Hidden service, using an HTTPSProxy and notice+debug logging enabl...so / ran full after a week or so. I found the culprits with:
find /proc/*/fd -ls | grep '(deleted)'
Version: tor 0.4.2.7-1~d8.jessie+1
Config:
Standard torrc with one Hidden service, using an HTTPSProxy and notice+debug logging enabled:
Log notice file /var/log/tor/notices.log
Log debug file /var/log/tor/debug.log
**Trac**:
**Username**: MaKoTorTor: 0.4.5.x-stablehttps://gitlab.torproject.org/tpo/core/tor/-/issues/33843Write detailed priority queue scheduler design on the proposal2022-10-11T23:39:34ZGeorge KadianakisWrite detailed priority queue scheduler design on the proposalTor: unspecifiedDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33839Correct 'was not internal' to 'was internal' in test_external_ip()2020-06-27T13:47:55ZTracCorrect 'was not internal' to 'was internal' in test_external_ip()source: https://github.com/torproject/tor/pull/1856
Fixing a typo in a string that is printed on event of a test failing, in `src/test/test_addr.c`.
**Trac**:
**Username**: kimimarosource: https://github.com/torproject/tor/pull/1856
Fixing a typo in a string that is printed on event of a test failing, in `src/test/test_addr.c`.
**Trac**:
**Username**: kimimaroTor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33837Tor.framework Unknown type name 'dispatch_queue_t'2020-06-27T13:47:55ZteorTor.framework Unknown type name 'dispatch_queue_t'From https://trac.torproject.org/projects/tor/ticket/33522#comment:2
>
> Replying to [tla](legacy/trac#33522):
> > It has a Travis-CI configuration, which I just updated to work on the latest macOS/Xcode image:
> >
> > https://github.c...From https://trac.torproject.org/projects/tor/ticket/33522#comment:2
>
> Replying to [tla](legacy/trac#33522):
> > It has a Travis-CI configuration, which I just updated to work on the latest macOS/Xcode image:
> >
> > https://github.com/iCepa/Tor.framework/blob/master/.travis.yml
> >
> >
> > Currently, we have issues in getting past Tor 0.4.0.6 on iOS. When I try to use a newer core, I get this error message:
> >
> > > Unknown type name 'dispatch_queue_t'
> >
> > in CFStream of Apple's CoreFoundation framework.
> >
> >
> > But "dispatch_queue_t" is actually a valid symbol from Apple's Foundation libraries.
> >
> > So somehow, it gets cancelled out through something which changed in Tor recently.
>
> This looks like a bug in tor's code, or perhaps in the Tor.framework embedding scripts.
>
> We'd be happy to help you diagnose this issue.
>
> Can you tell us the first release that has this issue? Is it 0.4.1, 0.4.2, or 0.4.3 ?
> Have you done a git bisect, to track down the commit that introduced the issue?
>
> Let's open a separate ticket, so we can fix this bug in tor's code.
> Or help you find a workaround when you embed tor.
I can't see dispatch_queue_t in Tor's code.
Perhaps we're defining some preprocessor symbols, or including a header that conflicts with dispatch_queue_t's header.
We don't know which release this bug was introduced in. But Tor 0.4.0.6 does not have this error.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33804Defer "PreferIPv6 by default" to 0.4.42020-06-27T13:47:56ZteorDefer "PreferIPv6 by default" to 0.4.4In legacy/trac#32637, we made clients default to "PreferIPv6" on SOCKSPorts (and other client ports).
But in legacy/trac#33796, we discovered that this change broke torsocks.
We want to defer this change to 0.4.4, so tor can implement ...In legacy/trac#32637, we made clients default to "PreferIPv6" on SOCKSPorts (and other client ports).
But in legacy/trac#33796, we discovered that this change broke torsocks.
We want to defer this change to 0.4.4, so tor can implement IPv4-only and IPv6-only resolves for torsocks.
Since legacy/trac#32637, we have also merged:
* legacy/trac#33608, which removes a forced PreferIPv6 for non-SOCKSPorts
* legacy/trac#32994, which puts the PreferIPv6 default in port_parse_config(), rather than in 2 different places in the code
So it should be very easy to change the default for PreferIPv6.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33796socks: Prefer IPv6 by default on SOCKS port broke torsocks: re-enable a bette...2021-09-07T20:13:48ZDavid Gouletdgoulet@torproject.orgsocks: Prefer IPv6 by default on SOCKS port broke torsocks: re-enable a better version after 0.4.4?In commit `bf2a399fc0d90df76e091fa3259f7c1b8fb87781` we made all SocksPort to prefer IPv6 which means that any DNS resolution answer will pick IPv6, if exists, over IPv4.
For torsocks, this is a problem because by default it tries to re...In commit `bf2a399fc0d90df76e091fa3259f7c1b8fb87781` we made all SocksPort to prefer IPv6 which means that any DNS resolution answer will pick IPv6, if exists, over IPv4.
For torsocks, this is a problem because by default it tries to resolve an IPv4. This can be fixed _except_ when the libc call (ex: `getaddrinfo()`) is specifically requesting an IPv4 (`hints.ai_family = AF_INET`).
There is currently no way for torsocks to ask tor, via the SocksPort, a specific INET family and thus torsocks receives back the IPv6 and can't handle it because the application was expecting an IPv4.
So this example fails often as we have more and more Exits are able to resolve IPv6:
```
wget -4 some.url
```
And still many applications by default will request an IPv4 because they don't handle IPv6.
Bottom line is that torsocks use case is broken for when an application is specifically requesting an INET family...
As a reminder, torsocks can _not_ pass the hostname directly in the SOCKS connection because it hijacks libc calls and thus flow can only be 1) DNS resolution, 2) `connect()` with an IP address.
I'm not sure what to do here... I think the ideal scenario would be to have a way for our "resolve" SOCKS extension to specify an address family value.
For instance, the `F0` (`RESOLVE` command) would be "return whatever" and then we could extend to have `RESOLVE4` and `RESOLVE6`..... HACK-ish but those extensions are already a hack so...
(That prefer IPv6 change went in 043)David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33794hs-v3: OnionBalance backend instances all fail after more introductions by hi...2021-06-23T17:22:42Zs7rhs-v3: OnionBalance backend instances all fail after more introductions by hitting descriptor upload time limitsWe fixed legacy/trac#33762 and thought that was the problem (which it also was) but after fixing that I have discovered that all onionbalance backend instances continue to die after testing and testing (establishing successful RP circuit...We fixed legacy/trac#33762 and thought that was the problem (which it also was) but after fixing that I have discovered that all onionbalance backend instances continue to die after testing and testing (establishing successful RP circuits with the frontend) and never heal unless Tor processes of the backends are restarted.
I was instructed by asn on IRC to look between the time of SIGHUP (logrotate log file change) and time of:
```
[warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_circuit.c:987: get_subcredential_for_handling_intro2_cell: Non-fatal assertion !(!service->ob_subcreds) failed. (on Tor 0.4.4.0-alpha-dev )
```
for the message
```
log_info(LD_REND, "Hidden service %s next descriptor successfully "
"built. Now scheduled for upload.",
```
Which meant that it eventually recovered by itself. I can see two of those messages in ~24 hours, but the backend instances continue to be unavailable. Frontend does not work, and even if you try to connect to the backend address directly instead of the frontend one it does not work.
It looks like it is never able to upload further descriptors at some point, flooding the log file with:
```
[info] log_cant_upload_desc(): Service [scrubbed] can't upload its current descriptor: Next upload time is 1585751537, it is now 1585748071. [598 similar message(s) suppressed in last 600 seconds]
[info] log_cant_upload_desc(): Service [scrubbed] can't upload its next descriptor: Next upload time is 1585751987, it is now 1585748071. [598 similar message(s) suppressed in last 600 seconds]
[info] log_cant_upload_desc(): Service [scrubbed] can't upload its current descriptor: Next upload time is 1585751537, it is now 1585748671. [598 similar message(s) suppressed in last 600 seconds]
[info] log_cant_upload_desc(): Service [scrubbed] can't upload its next descriptor: Next upload time is 1585751987, it is now 1585748671. [598 similar message(s) suppressed in last 600 seconds]
[info] log_cant_upload_desc(): Service [scrubbed] can't upload its current descriptor: Next upload time is 1585751537, it is now 1585749271. [598 similar message(s) suppressed in last 600 seconds]
[info] log_cant_upload_desc(): Service [scrubbed] can't upload its next descriptor: Next upload time is 1585751987, it is now 1585749271. [598 similar message(s) suppressed in last 600 seconds]
[info] log_cant_upload_desc(): Service [scrubbed] can't upload its current descriptor: Next upload time is 1585751537, it is now 1585749871. [598 similar message(s) suppressed in last 600 seconds]
[info] log_cant_upload_desc(): Service [scrubbed] can't upload its next descriptor: Next upload time is 1585751987, it is now 1585749871. [598 similar message(s) suppressed in last 600 seconds]
```
I have info log level files from 2 backend instances of like ~47 MB each.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33788Check the return value of tor_inet_ntop() and tor_inet_ntoa()2021-08-23T15:12:44ZteorCheck the return value of tor_inet_ntop() and tor_inet_ntoa()The following functions don't check the return value of tor_inet_ntop() or tor_inet_ntoa():
IPv6, could be serious:
* evdns_callback(), multiple times
IPv4 only, unlikely to be a serious bug:
* tor_dup_ip()
* fmt_addr32()
* evdns_wildc...The following functions don't check the return value of tor_inet_ntop() or tor_inet_ntoa():
IPv6, could be serious:
* evdns_callback(), multiple times
IPv4 only, unlikely to be a serious bug:
* tor_dup_ip()
* fmt_addr32()
* evdns_wildcard_check_callback()
These functions should log a bug log using BUG() or tor_assert_nonfatal(), and return an error. (Or for the formatting functions, a sensible placeholder string.)
We will also need to make their callers check for the error.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33782Increases TEST_CONN_FD_INIT to make tests working on GitHub Actions2020-06-27T13:47:57ZTracIncreases TEST_CONN_FD_INIT to make tests working on GitHub ActionsWith the current value, which is 50; it will cause some tests to fail on GitHub Actions:
```
hs_client/e2e_rend_circuit_setup_legacy: [forking] Mar 31 17:01:17.348 [warn] tor_bug_occurred_(): Bug: src/lib/net/socket.c:237: tor_close_soc...With the current value, which is 50; it will cause some tests to fail on GitHub Actions:
```
hs_client/e2e_rend_circuit_setup_legacy: [forking] Mar 31 17:01:17.348 [warn] tor_bug_occurred_(): Bug: src/lib/net/socket.c:237: tor_close_socket__real: Non-fatal assertion n_sockets_open >= 0 failed. (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: Tor 0.4.2.5: Non-fatal assertion n_sockets_open >= 0 failed in tor_close_socket__real at src/lib/net/socket.c:237. Stack trace: (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(log_backtrace_impl+0x56) [0x55d2831c7696] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(tor_bug_occurred_+0x17f) [0x55d2831c2fcf] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(tor_close_socket__real+0xd7) [0x55d2831ba3f7] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(connection_free_minimal+0x1c7) [0x55d28302a507] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(+0x2d5dff) [0x55d282e91dff] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(+0x444c66) [0x55d283000c66] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(testcase_run_one+0x2f1) [0x55d283000fb1] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(tinytest_main+0x10c) [0x55d28300156c] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(main+0x2a0) [0x55d282cad9f0] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f65fdf83b97] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(_start+0x2a) [0x55d282cadb1a] (on Tor 0.4.2.5 )
[e2e_rend_circuit_setup_legacy FAILED]
```
The reason is because of a process running in GitHub Actions doing something that caused a lot of file descriptors to open. So, when Tor is trying to close a fake socket it ends up closing a real one that was opened by GitHub Actions.
I already tried with 100 and it does not work. So I tried 200 and it works.
**Trac**:
**Username**: ultimaweaponTor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33781DocTor chokes on malformed dirreq-stats-end line2021-01-28T17:53:37ZGeorg KoppenDocTor chokes on malformed dirreq-stats-end lineI started to get a bunch of emails going like this:
```
Unable to retrieve the present extrainfo descriptors...
source: http://171.25.193.9:443/tor/extra/all
time: 04/01/2020 11:35
error: Malformed dirreq-stats-end line: dirreq-stats-en...I started to get a bunch of emails going like this:
```
Unable to retrieve the present extrainfo descriptors...
source: http://171.25.193.9:443/tor/extra/all
time: 04/01/2020 11:35
error: Malformed dirreq-stats-end line: dirreq-stats-end 2020-03-30 21:23:53 (86400 s)
```
Upon inspection it turns out that the lines in question contain an `^M` at the end which is likely to cause the problem.
It's not clear to me where the bug exactly is, meaning where it should get fixed. I thought maybe `stem` is not lenient enough here and teor suggested it's a `tor` bug. Thus, I am filing it here. Attached is the extra info descriptor DocTor is choking on. For some reason not all lines end on a `^M` which is kind of surprising.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33780hs-v3: Change to log notice the registration of an OB instance2021-06-23T17:22:41ZDavid Gouletdgoulet@torproject.orghs-v3: Change to log notice the registration of an OB instanceChange this info to notice:
```
Mar 29 15:59:12.000 [info] ob_option_parse(): OnionBalance: MasterOnionAddress *******.onion registered
```Change this info to notice:
```
Mar 29 15:59:12.000 [info] ob_option_parse(): OnionBalance: MasterOnionAddress *******.onion registered
```Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33779Fix incorrect PublishHidServDescriptors value in logs2021-06-23T17:22:41ZteorFix incorrect PublishHidServDescriptors value in logsThis code should say:
"PublishHidServDescriptors is set to 0."
But it says:
```
/* Let's avoid doing that if tor is configured to not publish. */
if (!get_options()->PublishHidServDescriptors) {
log_info(LD_REND, "Service %s not...This code should say:
"PublishHidServDescriptors is set to 0."
But it says:
```
/* Let's avoid doing that if tor is configured to not publish. */
if (!get_options()->PublishHidServDescriptors) {
log_info(LD_REND, "Service %s not publishing descriptor. "
"PublishHidServDescriptors is set to 1.",
safe_str_client(service->onion_address));
goto end;
}
```
I'll leave it to dgoulet and asn to fix, and decide how far it needs to be backported.Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33778TestingTorNetwork options in the man page are out of date2021-07-22T16:18:20ZoparaTestingTorNetwork options in the man page are out of dateA few of the values under `TestingTorNetwork` in `doc/tor.1.txt` are out of date compared to the options in `src/app/config/testnet.inc`. Also, some of the units listed for options only state 'minutes|hours' when they actually support 's...A few of the values under `TestingTorNetwork` in `doc/tor.1.txt` are out of date compared to the options in `src/app/config/testnet.inc`. Also, some of the units listed for options only state 'minutes|hours' when they actually support 'seconds' as well. I only fixed the ones that were relevant to `TestingTorNetwork`, but there are probably others as well. Will add a PR shortly.
In addition, many of the options that are of type `INTERVAL` use different units in the man page. For example:
```
ShutdownWaitLength NUM
V3AuthVotingInterval N minutes|hours
TestingV3AuthVotingStartOffset N seconds|minutes|hours
DormantClientTimeout N minutes|hours|days|weeks
```
Since these are all of type `INTERVAL`, is there a reason why these units are different when all of them support any unit in `unitparse.c` (seconds, minutes, hours, days, weeks)? One reason could be that some options have lower bounds (for example `V3AuthVotingInterval` must be greater than 300 seconds which is of the order of minutes), but the user can just specify 300 seconds rather than 5 minutes.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33768Make tor_inet_pton() handle bad addresses consistently on Windows2020-07-09T17:42:27ZteorMake tor_inet_pton() handle bad addresses consistently on Windowstor_inet_pton() handles bad addresses differently on Windows and Linux/macOS.
For example, the address: "2000::1a00::1000:fc098" (two "::") fails this test on Windows, but succeeds on Linux and macOS:
https://github.com/torproject/tor/p...tor_inet_pton() handles bad addresses differently on Windows and Linux/macOS.
For example, the address: "2000::1a00::1000:fc098" (two "::") fails this test on Windows, but succeeds on Linux and macOS:
https://github.com/torproject/tor/pull/1831/commits/05f4f93722d46c0e8f1d09b4dea4bf5d1743d93f#diff-048243cd6d9ed36dda0944181d8ec8abR1729
Let's fix this bug and backport it.
In general, we should make all the functions in this file behave identically:
* zero any out parameters at the start of the function
* zero any out parameters on failureTor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33767consider using a GitHub mirror for tor-rust-dependencies2021-02-05T21:09:48ZTaylor Yuconsider using a GitHub mirror for tor-rust-dependenciesDuring a recent IP address change of the host of git.torproject.org (legacy/trac#33730), a few Travis CI builds errored due to the unreachability of that host. (I think there were around five errored pull request builds? I restarted abou...During a recent IP address change of the host of git.torproject.org (legacy/trac#33730), a few Travis CI builds errored due to the unreachability of that host. (I think there were around five errored pull request builds? I restarted about three of them, ignoring the builds that were obsolete due to more recent changes.) I think this has happened before due to transient network faults.
We should consider making a GitHub mirror of the tor-rust-dependencies repository, and use that instead of the more canonical git.torproject.org location during Travis builds. (I'm guessing that the github.com repositories are very likely reachable if a Travis build starts successfully.) We might lose the ability to use the default git submodule setup done by Travis, though.
```
$ git submodule update --init --recursive
Submodule 'src/ext/rust' (https://git.torproject.org/tor-rust-dependencies) registered for path 'src/ext/rust'
Cloning into '/home/travis/build/torproject/tor/src/ext/rust'...
fatal: unable to access 'https://git.torproject.org/tor-rust-dependencies/': Failed to connect to git.torproject.org port 443: No route to host
fatal: clone of 'https://git.torproject.org/tor-rust-dependencies' into submodule path '/home/travis/build/torproject/tor/src/ext/rust' failed
Failed to clone 'src/ext/rust'. Retry scheduled
Cloning into '/home/travis/build/torproject/tor/src/ext/rust'...
fatal: unable to access 'https://git.torproject.org/tor-rust-dependencies/': Failed to connect to git.torproject.org port 443: No route to host
fatal: clone of 'https://git.torproject.org/tor-rust-dependencies' into submodule path '/home/travis/build/torproject/tor/src/ext/rust' failed
Failed to clone 'src/ext/rust' a second time, aborting
```Tor: unspecified