Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2022-06-17T18:25:28Zhttps://gitlab.torproject.org/legacy/trac/-/issues/572fallback-consensus file impractical to use2022-06-17T18:25:28ZRoger Dingledinefallback-consensus file impractical to useWe can put the fallback-consensus in the tarball that results from 'make dist',
but it breaks 'make dist-rpm'.
Right now (0.2.0.12-alpha) it's commented out of src/config/Makefile.am
We need whatever voodoo it takes to let make dist-rp...We can put the fallback-consensus in the tarball that results from 'make dist',
but it breaks 'make dist-rpm'.
Right now (0.2.0.12-alpha) it's commented out of src/config/Makefile.am
We need whatever voodoo it takes to let make dist-rpm do its thing too, before
we can reenable it.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1031reserved identifier violation2020-06-13T14:23:38ZTracreserved identifier violationI suggest to try the search pattern "_[A-Z]+" on the source files. You will find some places where names begin with an underscore and an uppercase letter.
Examples:
- _TOR_ADDRESS_H
https://svn.torproject.org/cgi-bin/viewvc.cgi/tor/tr...I suggest to try the search pattern "_[A-Z]+" on the source files. You will find some places where names begin with an underscore and an uppercase letter.
Examples:
- _TOR_ADDRESS_H
https://svn.torproject.org/cgi-bin/viewvc.cgi/tor/trunk/src/common/address.h?revision=17867&view=markup
- _SHORT_FILE_
https://svn.torproject.org/cgi-bin/viewvc.cgi/tor/trunk/src/common/compat.h?revision=18743&view=markup
This does not fit to the expected naming conventions of the C language standard.
http://en.wikipedia.org/wiki/Reserved_identifier
See also section "7.1.3 Reserved identifiers".
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: elfringTor: 0.2.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/1035Relay on dynamic IP marked as stable and guard2020-06-13T14:02:22ZTracRelay on dynamic IP marked as stable and guardHi,
I'm running a Tor relay on a dynamic IP which changes every day. At the moment
my node is marked as stable and guard which AFAIK shouldn't happen as it isn't
stable. I got the information from https://trunk.torstatus.kgprog.com:444/...Hi,
I'm running a Tor relay on a dynamic IP which changes every day. At the moment
my node is marked as stable and guard which AFAIK shouldn't happen as it isn't
stable. I got the information from https://trunk.torstatus.kgprog.com:444/.
This may be related to bug #969 which was marked as fixed.
Thanks,
Simon
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: rudisTor: 0.2.4.x-finalSebastian HahnSebastian Hahnhttps://gitlab.torproject.org/legacy/trac/-/issues/1690Consensus Bandwidth Lacks Indication of Type2020-06-13T14:05:08ZDamian JohnsonConsensus Bandwidth Lacks Indication of TypeOn the client side there currently isn't a way of telling what type of measurement was used for the bandwidth value. For instance if it reads "w Bandwidth=65700" there's no way to definitively tell if this is observed, measured, or weigh...On the client side there currently isn't a way of telling what type of measurement was used for the bandwidth value. For instance if it reads "w Bandwidth=65700" there's no way to definitively tell if this is observed, measured, or weighted measured.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1992relays resolve hostname every time they compute dir fetch schedule; but bridg...2020-06-13T14:06:49ZRoger Dingledinerelays resolve hostname every time they compute dir fetch schedule; but bridges resolve too seldomdirectory_fetches_from_authorities() calls router_pick_published_address() whenever server_mode(options) is true.
This happens during directory_get_from_dirserver(), directory_command_should_use_begindir(), dir_routerdesc_download_faile...directory_fetches_from_authorities() calls router_pick_published_address() whenever server_mode(options) is true.
This happens during directory_get_from_dirserver(), directory_command_should_use_begindir(), dir_routerdesc_download_failed(), directory_info_has_arrived(), update_consensus_networkstatus_fetch_time(), launch_router_descriptor_downloads(), update_router_descriptor_downloads(), etc.
Sounds like we should refactor things so it writes its guessed address to a variable and just reads that variable, and then have a periodic event (scheduled when we want it, rather than scheduled by accident because we think about doing a directory fetch) that writes an address into the variable.Tor: 0.2.4.x-finalRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/2267resolve_my_address() resolves incorrect address.2020-06-13T14:07:46ZTracresolve_my_address() resolves incorrect address.I have tried tor 0.2.1.26, 0.2.1.27, and 0.2.2.19-alpha. They all detect my IP address as either 8.15.7.117 or 63.251.179.13. Neither is correct. Every 10 minutes or so, tor will switch between the two incorrect IP addresses. Tor seems t...I have tried tor 0.2.1.26, 0.2.1.27, and 0.2.2.19-alpha. They all detect my IP address as either 8.15.7.117 or 63.251.179.13. Neither is correct. Every 10 minutes or so, tor will switch between the two incorrect IP addresses. Tor seems to be working correctly has a client, but not as a relay. I have set the correct Address in my torrc, and then tor displays the correct address, but is not any more functional.
My network is pretty standard. I am behind a NAT router, but all ports are forwarded to my computer running tor. Other networking programs like bittorrent, edonkey, and freenet all work correctly. Nothing interesting shows up in the logs.
**Trac**:
**Username**: eric225125Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/2286We still use self-published relay bandwidth sometimes2022-02-17T19:36:19ZRoger DingledineWe still use self-published relay bandwidth sometimesThere's a gap between when a new relay shows up and when there are enough Measured votes from the directory authorities that we use the measured bandwidth in the consensus. So all the various papers that talk about "just run a tiny relay...There's a gap between when a new relay shows up and when there are enough Measured votes from the directory authorities that we use the measured bandwidth in the consensus. So all the various papers that talk about "just run a tiny relay and advertise it as a huge relay" are not actually solved yet -- their algorithm should just be modified to add "for a few days".
(Actually, this bug isn't quite as bad as it could be, since you need to be around for 3 or 5 days in order to get the Guard flag. I wonder how quickly measurements are ready in general, i.e. who wins the race here.)
I suggest three fixes:
A) There should be a quite low cap (e.g. 50KB) for bandwidth weightings in the consensus if there aren't enough Measured votes. I wonder if the 50KB should be a fixed number (in which case we could just have the directory authorities vote it, and not need to change the consensus method), or a function of the overall numbers in the consensus (which would require a new consensus method, but could pick a smarter cap given that some relays have really bloated bandwidth weights).
A') Somebody should evaluate how much of our overall capacity we'd be cutting, and what effect this cutting has on our entropy.
B) To reduce the harm to the network (since new relays would be contributing much less), we should teach the bwauth scripts to measure new relays more aggressively, to shorten this window.
C) The longer term solution is that we need to integrate Robin and Nikita's secure bandwidth estimation stuff -- right now Mike's bwauth scripts believe your self-advertised number and then tweak it based on what they see, so you'll still get a much higher number if you self-advertise a much higher number. Open research question how to improve security here without sacrificing too much accuracy and without adding too much load to the network.
Added with 0.2.3.x as the milestone, since we should do it pretty soon but we can make the change in the directory authorities so timing isn't critical.Tor: 0.2.4.x-finalAndrea ShepardAndrea Shepardhttps://gitlab.torproject.org/legacy/trac/-/issues/2385rendservice.c: cleanup stack stored key material2020-06-13T14:08:17Zcypherpunksrendservice.c: cleanup stack stored key materialNon complete list:
rend_service_introduce(): char keys[DIGEST_LEN+CPATH_KEY_MATERIAL_LEN]
The same for rendclient.c.Non complete list:
rend_service_introduce(): char keys[DIGEST_LEN+CPATH_KEY_MATERIAL_LEN]
The same for rendclient.c.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/2410Long Runtime for 'GETINFO address' queries2020-06-13T14:08:21ZDamian JohnsonLong Runtime for 'GETINFO address' queriesHi. Most attributes, the address included, are quick to query (averaging 0.0004 seconds on my system). However, if the user sets an address attribute, ex:
Address tor.spider007.net
the address query takes *far* longer (between 0.15 - 5...Hi. Most attributes, the address included, are quick to query (averaging 0.0004 seconds on my system). However, if the user sets an address attribute, ex:
Address tor.spider007.net
the address query takes *far* longer (between 0.15 - 5 seconds). Having getinfo queries block for several seconds is a substantial problem for controllers, in arms case causing a very long startup time and intermittently freezing the interface (though I'm still not sure of the root cause behind this later symptom... probably something tangential to setting the address since I cache that particular value).
This is courtesy of Sjon who helped discovered this issue. Cheers! -DamianTor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/3155Single Underscore in Option Name2020-06-13T14:10:30ZDamian JohnsonSingle Underscore in Option NameConfig options either start with zero or double underscores with a single exception...
```
>>> conn.getInfo("version")
'0.2.2.23-alpha (git-b85eb949b528f4d7)'
>>> print "\n".join(sorted(conn.getInfo("config/names", "").split("\n")))
......Config options either start with zero or double underscores with a single exception...
```
>>> conn.getInfo("version")
'0.2.2.23-alpha (git-b85eb949b528f4d7)'
>>> print "\n".join(sorted(conn.getInfo("config/names", "").split("\n")))
...
WarnPlaintextPorts CommaList
WarnUnsafeSocks Boolean
_UsingTestNetworkDefaults Boolean
__AllDirActionsPrivate Boolean
__DisablePredictedCircuits Boolean
__HashedControlSessionPassword LineList
__LeaveStreamsUnattached Boolean
__ReloadTorrcOnSIGHUP Boolean
```
I asked about this on irc, but I'm not clear from Robert's response if this means that '_UsingTestNetworkDefaults' actually shouldn't be exposed to the controller.
08:12 < atagar> I'm finding that most private options start with a double underscore, but in one case it's a single underscore... [bit removed since trac chokes on the double underscores]
08:12 < atagar> is this a mistake?
08:13 < rransom> _UsingTestNetworkDefaults is a fake option.
08:13 < rransom> The double-underscore options are for use by controllers.
08:18 < atagar> Fake option? Not following - the single underscore has some special meaning?
08:18 < rransom> atagar: _UsingTestNetworkDefaults is clobbered within Tor every time it processes its options.
08:19 < rransom> The double-underscore options are actual options that can be set from outside Tor.
08:20 < atagar> Is it right then for _UsingTestNetworkDefaults to be presented via 'GETINFO config/names'? I'm pretty sure this makes it user setable.
08:20 < atagar> yup, it does
Feel free to close if presenting the _UsingTestNetworkDefaults option this way is intended (though I'd be a little curious then what the single underscore should signify for controllers).
Cheers! -DamianTor: 0.2.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/3443Client with low CBT can't establish any circuits2020-06-13T14:27:56ZRoger DingledineClient with low CBT can't establish any circuitsI ran my Tor client on my laptop for a while in a stable place. It ended up thinking my connection is super-fast:
```
Jun 21 01:49:15.786 [info] circuit_build_times_parse_state(): Loaded 1000/1000 values from 136 lines in circuit time hi...I ran my Tor client on my laptop for a while in a stable place. It ended up thinking my connection is super-fast:
```
Jun 21 01:49:15.786 [info] circuit_build_times_parse_state(): Loaded 1000/1000 values from 136 lines in circuit time histogram
Jun 21 01:49:15.786 [info] circuit_build_times_get_xm(): Xm mode #0: 575 55
Jun 21 01:49:15.786 [info] circuit_build_times_get_xm(): Xm mode #1: 625 51
Jun 21 01:49:15.786 [info] circuit_build_times_get_xm(): Xm mode #2: 575 55
Jun 21 01:49:15.786 [notice] Based on 1000 circuit times, it looks like we don't need to wait so long for circuits to finish. We will now assume a circuit is too slow to use after waiting 2 seconds.
Jun 21 01:49:15.786 [info] circuit_build_times_set_timeout(): Circuit timeout data: 2025.978516ms, 60000.000000ms, Xm: 590, a: 1.304577, r: 0.199000
```
But then I restarted my Tor, this time with a bridge that is in .za:
```
Jun 21 01:49:16.968 [debug] onion_pick_cpath_exit(): Launching a one-hop circuit for dir tunnel.
...
Jun 21 01:49:16.968 [notice] Bootstrapped 5%: Connecting to directory server.
...
Jun 21 01:49:16.968 [debug] circuit_handle_first_hop(): connecting in progress (or finished). Good.
...
Jun 21 01:49:17.256 [debug] connection_or_finished_connecting(): OR connect() to router at 196.x.x.x:10000 finished.
Jun 21 01:49:17.256 [notice] Bootstrapped 10%: Finishing handshake with directory server.
...
Jun 21 01:49:17.851 [debug] connection_tls_continue_handshake(): Done with initial SSL handshake (client-side). Requesting renegotiation.
...
Jun 21 01:49:18.448 [debug] connection_tls_finish_handshake(): tls handshake with 196.x.x.x done. verifying.
...
Jun 21 01:49:18.741 [info] command_process_versions_cell(): Negotiated version 2 with 196.x.x.x:10000; sending NETINFO.
...
Jun 21 01:49:18.741 [debug] circuit_send_next_onion_skin(): First skin; sending create cell.
Jun 21 01:49:18.741 [notice] Bootstrapped 15%: Establishing an encrypted directory connection.
...
Jun 21 01:49:18.969 [info] circuit_expire_building(): Abandoning circ 196.x.x.x:10000:54967 (state 0:doing handshakes, purpose 5)
Jun 21 01:49:18.969 [info] exit circ (length 1, last hop 0000000000000000000000000000000000000000): $0000000000000000000000000000000000000000(waiting for keys)
Jun 21 01:49:18.969 [info] circuit_build_failed(): Our circuit failed to get a response from the first hop (196.x.x.x:10000). I'm going to try to rotate to a better connection.
Jun 21 01:49:18.969 [info] connection_ap_fail_onehop(): Closing one-hop stream to '$0000000000000000000000000000000000000000/196.x.x.x' because the OR conn just failed.
...
Jun 21 01:49:18.970 [info] connection_dir_request_failed(): Giving up on directory server at '196.x.x.x'; retrying
...
Jun 21 01:49:27.978 [info] should_delay_dir_fetches(): delaying dir fetches (no running bridges known)
```
And now my Tor client is dead in the water.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/3562Tor exit support for ipv62020-06-13T14:11:48ZNick MathewsonTor exit support for ipv6We'd like to have exit support for IPv6; we've wanted it for a long time.
See proposal 117 for an older design here; updates will be needed.We'd like to have exit support for IPv6; we've wanted it for a long time.
See proposal 117 for an older design here; updates will be needed.Tor: 0.2.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/3589Advertise bridge pluggable transports using extra-info lines2020-06-13T17:50:01ZGeorge KadianakisAdvertise bridge pluggable transports using extra-info linesWe should implement the "Advertising bridge methods" section of proposal 180.We should implement the "Advertising bridge methods" section of proposal 180.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/3842Missing signal/names option2020-06-13T14:12:47ZDamian JohnsonMissing signal/names optionWe have GETINFO options for the recognized input of just about all the controller commands via...
info/names
config/names
events/names
features/names
The only thing missing is the SIGNAL values (ie, a "GETINFO signal/names").We have GETINFO options for the recognized input of just about all the controller commands via...
info/names
config/names
events/names
features/names
The only thing missing is the SIGNAL values (ie, a "GETINFO signal/names").Tor: 0.2.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/3894Fix compilation on FreeBSD 42020-06-13T14:30:27ZNick MathewsonFix compilation on FreeBSD 4Grarpamp reports on tor-talk that Tor 0.2.2 doesn't build on freebsd 4, whereas 0.2.1 did. I've got a partial patch series at branch called "gcc-295-fix" in my public repository; I should get him to test it, test it more on other platf...Grarpamp reports on tor-talk that Tor 0.2.2 doesn't build on freebsd 4, whereas 0.2.1 did. I've got a partial patch series at branch called "gcc-295-fix" in my public repository; I should get him to test it, test it more on other platforms, and make sure that it covers all the issues he mentioned in his emails.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/4020Tor doesn't log the public address it is warning about2020-06-13T14:13:18ZRobert RansomTor doesn't log the public address it is warning about```
Sep 14 04:11:29.519 [warn] You specified a public address for SocksPort. Other people on the Internet might find your computer and use it as an open proxy. Please don't allow this unless you have a good reason.
```
Tor 0.2.2.x print...```
Sep 14 04:11:29.519 [warn] You specified a public address for SocksPort. Other people on the Internet might find your computer and use it as an open proxy. Please don't allow this unless you have a good reason.
```
Tor 0.2.2.x printed the address it was complaining about. Tor 0.2.3.x doesn't, because the original string which the user specified in the config file is not available to the function which complains now.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/4195Stop using sscanf in rephist2020-06-13T14:13:40ZNick MathewsonStop using sscanf in rephistTo avoid well-known pitfalls, we use tor_sscanf in lieu of the system libc's sscanf.... everywhere except for 3 calls in rephist.c.
To fix those, we need support for %lu, %lf, %ld, and %d in tor_sscanf.
This is also coverity issue CID ...To avoid well-known pitfalls, we use tor_sscanf in lieu of the system libc's sscanf.... everywhere except for 3 calls in rephist.c.
To fix those, we need support for %lu, %lf, %ld, and %d in tor_sscanf.
This is also coverity issue CID 448.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/4283crypto_pk_cmp_keys does not document its error behaviour2020-06-13T14:13:56ZRobert Ransomcrypto_pk_cmp_keys does not document its error behaviour```
/** Compare the public-key components of a and b. Return -1 if a\<b, 0
* if a==b, and 1 if a\>b.
*/
```
```
if (!a || !b)
return -1;
if (!a->key || !b->key)
return -1;
```
Can we replace these with asserts on 0.2.3.x?```
/** Compare the public-key components of a and b. Return -1 if a\<b, 0
* if a==b, and 1 if a\>b.
*/
```
```
if (!a || !b)
return -1;
if (!a->key || !b->key)
return -1;
```
Can we replace these with asserts on 0.2.3.x?Tor: 0.2.4.x-finalRobert RansomRobert Ransomhttps://gitlab.torproject.org/legacy/trac/-/issues/4461Add a consensus parameter for token bucket refill interval2020-06-13T14:14:38ZKarsten LoesingAdd a consensus parameter for token bucket refill intervalWhen we merged the #3630 code, we changed the token bucket refill interval from 1/s to 10/s. We're now simulating whether this was a good choice in #4086.
Roger suggests that we add a consensus parameter that relays use to override the...When we merged the #3630 code, we changed the token bucket refill interval from 1/s to 10/s. We're now simulating whether this was a good choice in #4086.
Roger suggests that we add a consensus parameter that relays use to override their default token bucket refill interval. If we learn that 10/s wasn't the best choice, we can easily change it for all relays. Also, a consensus parameter would enable us to run experiments in the live Tor network, within reasonable bounds.
Thoughts?Tor: 0.2.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/4465Decide on a good token bucket refill interval2020-06-13T14:14:38ZKarsten LoesingDecide on a good token bucket refill intervalIn #3630 we changed the token bucket refill interval from 1/s to 10/s. We should evaluate whether this change was harmful and possibly find a better value. We should also put in a consensus parameter to change the refill interval for a...In #3630 we changed the token bucket refill interval from 1/s to 10/s. We should evaluate whether this change was harmful and possibly find a better value. We should also put in a consensus parameter to change the refill interval for all relays.Tor: 0.2.4.x-finalRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/4608Describe replay prevention for INTRODUCE2 cells in rend-spec.txt2020-06-13T14:15:29ZRobert RansomDescribe replay prevention for INTRODUCE2 cells in rend-spec.txtWe never documented Tor hidden services' replay-prevention behaviour for INTRODUCE2 cells in rend-spec.txt. We got the replay prevention wrong the first time, fixed a security bug in it without a Trac ticket, and changed it again to fix...We never documented Tor hidden services' replay-prevention behaviour for INTRODUCE2 cells in rend-spec.txt. We got the replay prevention wrong the first time, fixed a security bug in it without a Trac ticket, and changed it again to fix a major usability bug in #3460. Time to document that replay-prevention behaviour (and its history).Tor: 0.2.4.x-finalRobert RansomRobert Ransomhttps://gitlab.torproject.org/legacy/trac/-/issues/4609rend-spec.txt describes HidServAuth option incorrectly2020-06-13T14:15:30ZRobert Ransomrend-spec.txt describes HidServAuth option incorrectlyIn rend-spec.txt §2.4:
```
HidServAuth service-name service-address descriptor-cookie
```
HidServAuth lines don't have a ‘descriptor cookie’. They do have a description field at the end that no code uses. Document this, and if po...In rend-spec.txt §2.4:
```
HidServAuth service-name service-address descriptor-cookie
```
HidServAuth lines don't have a ‘descriptor cookie’. They do have a description field at the end that no code uses. Document this, and if possible the history of the HidServAuth option.Tor: 0.2.4.x-finalRobert RansomRobert Ransomhttps://gitlab.torproject.org/legacy/trac/-/issues/4613Revise proposal 186 and spec as needed2020-06-13T14:15:31ZNick MathewsonRevise proposal 186 and spec as neededProposal 186 has some good comments in tor-dev; it also has a partial implementation (#3785) merged as part of #3786. I should:
* Revise proposal 186 based on feedback.
* Update specs to reflect the already-implemented part of it.Proposal 186 has some good comments in tor-dev; it also has a partial implementation (#3785) merged as part of #3786. I should:
* Revise proposal 186 based on feedback.
* Update specs to reflect the already-implemented part of it.Tor: 0.2.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/4620Move ipv6_preferred from routerinfo_t to node_t2020-06-13T14:15:34ZLinus Nordberglinus@torproject.orgMove ipv6_preferred from routerinfo_t to node_tThe ipv6_preferred flag in routerinfo_t should not be there since that data structure is supposed to be immutable. Move it to node_t.The ipv6_preferred flag in routerinfo_t should not be there since that data structure is supposed to be immutable. Move it to node_t.Tor: 0.2.4.x-finalLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/4664./autogen.sh puts stuff on stderr2020-06-13T14:15:49ZSebastian Hahn./autogen.sh puts stuff on stderrinside autogen.sh, we call autoreconf -ivf. The -v flag means verbose reports, which are basically just "going to dir x, calling application y" on stderr. This is pretty useless, and for some scripts I'd like to be able to silence the ou...inside autogen.sh, we call autoreconf -ivf. The -v flag means verbose reports, which are basically just "going to dir x, calling application y" on stderr. This is pretty useless, and for some scripts I'd like to be able to silence the output except for error conditions. Can we simply take out the -v here without bad stuff happening?Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/4852Clients send NETINFO with time2020-06-13T14:52:54ZJacob AppelbaumClients send NETINFO with timeWhile implementing tordate, I noticed that Tor clients send NETINFO cells to servers with their time.
I believe that this is to spec but that both the implementation and the spec are wrong. A client should simply fill the time field out...While implementing tordate, I noticed that Tor clients send NETINFO cells to servers with their time.
I believe that this is to spec but that both the implementation and the spec are wrong. A client should simply fill the time field out with zeros. We already send zero as the address as a client, we should also send zero as the time stamp.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/4933Specification updates for 0.2.3.x2020-06-13T14:16:53ZGeorge KadianakisSpecification updates for 0.2.3.xThis is a parent ticket monitoring all tickets that try to update the spec. to conform with the current code.This is a parent ticket monitoring all tickets that try to update the spec. to conform with the current code.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/4971Provide initvalue in GETINFO config/names2020-06-13T14:17:01ZTomas ToucedaProvide initvalue in GETINFO config/namesTo handle torrc config options from Vidalia it would be useful to me to have the default values with each option printed by config/names.
Attached is a simple patch to handle this.To handle torrc config options from Vidalia it would be useful to me to have the default values with each option printed by config/names.
Attached is a simple patch to handle this.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/4994Be willing to use microdescs even if one bridge runs 0.2.22020-06-13T14:17:03ZRoger DingledineBe willing to use microdescs even if one bridge runs 0.2.2In #4013 we fixed a big bug where clients would ask 0.2.2 bridges for microdescriptors, and then just fail. But we fixed it by falling back to normal descriptors if we ever get a hint that we have an 0.2.2 bridge. That fix is adequate fo...In #4013 we fixed a big bug where clients would ask 0.2.2 bridges for microdescriptors, and then just fail. But we fixed it by falling back to normal descriptors if we ever get a hint that we have an 0.2.2 bridge. That fix is adequate for 0.2.3, but by the time we get to the 0.2.4 timeframe, 0.2.2 bridges will be rare. The fact that you fall back if you've ever seen an 0.2.2 bridge will make those clients rare and unusual (not to mention wasteful).
The better behavior, once 0.2.2 bridges are more gone, is to learn to avoid 0.2.2 bridges when asking microdescriptor requests, and only fall back to normal descriptors if none of your bridges can handle microdescriptors.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/5041Remove dirauths' contact information from consensus2020-06-13T14:17:09ZRobert RansomRemove dirauths' contact information from consensusweasel suggests removing the directory authorities' contact information from the consensus next time we add a new consensus method.weasel suggests removing the directory authorities' contact information from the consensus next time we add a new consensus method.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/5055Extend bridge statistics to learn about IPv4 vs. IPv6 usage2020-06-13T14:24:42ZKarsten LoesingExtend bridge statistics to learn about IPv4 vs. IPv6 usageOne of the main purposes for making bridges accept IPv6 connections was to circumvent some firewalls. But we don't have any statistics to see how well that works. IPv6 bridges always support IPv4, too, so we can't say from the current ...One of the main purposes for making bridges accept IPv6 connections was to circumvent some firewalls. But we don't have any statistics to see how well that works. IPv6 bridges always support IPv4, too, so we can't say from the current bridge statistics if connections came from one or the other address version.
In #5053 I briefly wondered if we should add a new country code `"?6"` to count unresolved IPv6 addresses. But that doesn't make sense, because as soon as we have an IPv6 GeoIP database, we wouldn't know if users coming from `"de"` actually connected to the bridge via IPv4 or IPv6.
How about we add a new line `"bridge-ip-versions v4=NN,v6=NN"` to count unique IP addresses for the two IP address versions?
In theory, we could add similar lines to the other statistics, but it mostly matters for bridge usage. I would want to do this for bridge statistics only, at least for the moment. And by "for the moment" I mean for 0.2.4.x.Tor: 0.2.4.x-finalLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/5070tor complains there's no ClientTransportPlugin line when actually it just can...2020-06-13T14:19:01ZRoger Dingledinetor complains there's no ClientTransportPlugin line when actually it just can't launch the exeWhen I set my torrc to say
```
ClientTransportPlugin obfs2 exec /path/to/nonexistent/file --managed
```
then the way Tor tells me it couldn't launch or find the file is by logging
```
Feb 10 03:23:28.000 [warn] Could not launch managed ...When I set my torrc to say
```
ClientTransportPlugin obfs2 exec /path/to/nonexistent/file --managed
```
then the way Tor tells me it couldn't launch or find the file is by logging
```
Feb 10 03:23:28.000 [warn] Could not launch managed proxy executable!
Feb 10 03:23:28.000 [warn] You have a Bridge line using the obfs2 pluggable transport, but there doesn't seem to be a corresponding ClientTransportPlugin line.
```
That second line is confusing people. It's not true.
If I then change the line to
```
ClientTransportPlugin obfs2 exec /bin/false --managed
```
I get
```
Feb 10 03:29:57.000 [notice] Managed proxy stream closed. Most probably application stopped running
Feb 10 03:29:57.000 [notice] Failed to terminate process with PID '13672'
Feb 10 03:29:57.000 [warn] You have a Bridge line using the obfs2 pluggable transport, but there doesn't seem to be a corresponding ClientTransportPlugin line.
Feb 10 03:29:58.000 [notice] Bootstrapped 5%: Connecting to directory server.
Feb 10 03:29:58.000 [warn] Tried to connect through proxy, but proxy address could not be found.
```
Again the warn line is what people look to. Also, should the "it closed" be a warn in this case? Also also, what's with the "tried to connect through proxy" line -- why does it tell me the proxy address could not be found?Tor: 0.2.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/5124Get rid of the last 'opt' strings in descriptors?2020-06-13T14:17:29ZRoger DingledineGet rid of the last 'opt' strings in descriptors?For a long time now 'opt' has been optional. So long that we can drop it from descriptor lines, yes?
I see it in "protocols", "fingerprint", "extra-info-digest", "hidden-service-dir".For a long time now 'opt' has been optional. So long that we can drop it from descriptor lines, yes?
I see it in "protocols", "fingerprint", "extra-info-digest", "hidden-service-dir".Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/5178Adaptive circuit-build timeout code does not match spec2020-06-13T14:17:39ZRobert RansomAdaptive circuit-build timeout code does not match spec```
01:37 < rransom_> wanoskarnet: See section 2.4.4 of path-spec.txt in https://gitweb.torproject.org/torspec.git/tree . Does that match the behaviour in the code? Is that behaviour good?
01:43 < wanoskarnet> numbers are different. idea...```
01:37 < rransom_> wanoskarnet: See section 2.4.4 of path-spec.txt in https://gitweb.torproject.org/torspec.git/tree . Does that match the behaviour in the code? Is that behaviour good?
01:43 < wanoskarnet> numbers are different. idea is fine except definition of networkk connectivity loss. and no double the timeout can happen because it reset number of counts and could count abandoned circuit if counted of success circ.
01:44 < wanoskarnet> "was already 60 or higher" "or higher" actually means changed initial values only. but it's ok to check for such case.
01:46 < wanoskarnet> in oter work: code do reset timeout to init values but can't double timeout.
01:55 < wanoskarnet> circuit_build_times_network_check_live() non the same as "2.4.4". cbt->liveness.nonlive_timeouts incremeants just after "we've received no cells or TLS handshakes since those circuits began." no matter what number of timeouts.
01:57 < wanoskarnet> "if (cbt->liveness.nonlive_timeouts > 0)" should be 3?
```Tor: 0.2.4.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/5191mp->transports' contents types should not change by time2020-06-13T14:17:43ZGeorge Kadianakismp->transports' contents types should not change by time```
/* The 'transports' list contains all the transports this proxy has
launched.
Before a managed_proxy_t reaches the PT_PROTO_COMPLETED phase,
this smartlist contains a 'transport_t' for every transport it
has la...```
/* The 'transports' list contains all the transports this proxy has
launched.
Before a managed_proxy_t reaches the PT_PROTO_COMPLETED phase,
this smartlist contains a 'transport_t' for every transport it
has launched.
When the managed_proxy_t reaches the PT_PROTO_COMPLETED phase, it
registers all its transports to the circuitbuild.c subsystem. At
that point the 'transport_t's are owned by the circuitbuild.c
subsystem.
To avoid carrying dangling 'transport_t's in this smartlist,
right before the managed_proxy_t reaches the PT_PROTO_COMPLETED
phase we replace all 'transport_t's with strings of their
transport names.
So, tl;dr:
When (conf_state != PT_PROTO_COMPLETED) this list carries
(transport_t *).
When (conf_state == PT_PROTO_COMPLETED) this list carries
(char *).
*/
```Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/5285smartlist_isin should be named smartlist_contains2020-06-13T14:17:54ZRobert Ransomsmartlist_isin should be named smartlist_containsTor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/5394warn users about their clock if they see a consensus from the future2020-06-13T14:18:15ZRoger Dingledinewarn users about their clock if they see a consensus from the futureIn router_set_networkstatus_v2() we check if the v2 ns is from the future, and warn if so:
```
if (ns->published_on > now + NETWORKSTATUS_ALLOW_SKEW) {
char dbuf[64];
long delta = now - ns->published_on;
format_time_interva...In router_set_networkstatus_v2() we check if the v2 ns is from the future, and warn if so:
```
if (ns->published_on > now + NETWORKSTATUS_ALLOW_SKEW) {
char dbuf[64];
long delta = now - ns->published_on;
format_time_interval(dbuf, sizeof(dbuf), delta);
log_warn(LD_GENERAL, "Network status from %s was published %s in the "
"future (%s GMT). Check your time and date settings! "
"Not caching.",
source_desc, dbuf, published);
control_event_general_status(LOG_WARN,
"CLOCK_SKEW MIN_SKEW=%ld SOURCE=NETWORKSTATUS:%s:%d",
delta, ns->source_address, ns->source_dirport);
skewed = 1;
}
```
We should do something similar for v3 consensuses.
Also, we might want to use a smaller value than '24 hours' for skew tolerance, since there's really no realistic way a consensus will validly appear from even the near future.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/5396Update torspec wrt transports in extra-info descriptors2020-06-13T14:18:15ZGeorge KadianakisUpdate torspec wrt transports in extra-info descriptors#3589 specifies how pluggable transport information should be enlisted in extra-info descriptors. But it doesn't update the spec. This ticket is responsible for doing the spec part.#3589 specifies how pluggable transport information should be enlisted in extra-info descriptors. But it doesn't update the spec. This ticket is responsible for doing the spec part.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/5415Rename or remove _UseFilteringSSLBufferevents option2020-06-13T14:18:19ZRobert RansomRename or remove _UseFilteringSSLBufferevents option`_UseFilteringSSLBufferevents` should be renamed (to `UseFilteringSSLBufferevents`) or removed.
(Not marking this ticket as ‘easy’ because deciding whether to rename or remove this option is not necessarily easy.)`_UseFilteringSSLBufferevents` should be renamed (to `UseFilteringSSLBufferevents`) or removed.
(Not marking this ticket as ‘easy’ because deciding whether to rename or remove this option is not necessarily easy.)Tor: 0.2.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/5450Remove Tor's SHA-256 implementation2020-06-13T14:18:24ZRobert RansomRemove Tor's SHA-256 implementationTor includes an implementation of SHA-256 (in src/common/sha256.c) in case it is linked to a version of OpenSSL older than 0.9.8. Tor should no longer support such old versions of OpenSSL, so Tor should dump code needed only to support ...Tor includes an implementation of SHA-256 (in src/common/sha256.c) in case it is linked to a version of OpenSSL older than 0.9.8. Tor should no longer support such old versions of OpenSSL, so Tor should dump code needed only to support them.
Some changes to src/common/crypto.c will also be needed (at a minimum, in `crypto_hmac_sha256`).Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/5486Add IPv6 support to bridge authorities2020-06-13T14:18:31ZLinus Nordberglinus@torproject.orgAdd IPv6 support to bridge authoritiesFix the IPv4-only:isms we'll find when trying to run a bridge
authority on IPv6.Fix the IPv4-only:isms we'll find when trying to run a bridge
authority on IPv6.Tor: 0.2.4.x-finalLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/5529Move last_reachable and testing_since from routerinfo_t to node_t2020-06-13T14:18:39ZLinus Nordberglinus@torproject.orgMove last_reachable and testing_since from routerinfo_t to node_tIn preparation for adding support for reachability testing over IPv6
(in bridge authorities to begin with), let's move last_reachable and
testing_since from routerinfo_t to node_t. routerinfo_t is supposed
to be imutable so it'd be sad ...In preparation for adding support for reachability testing over IPv6
(in bridge authorities to begin with), let's move last_reachable and
testing_since from routerinfo_t to node_t. routerinfo_t is supposed
to be imutable so it'd be sad to add more mutable members to it now.Tor: 0.2.4.x-finalLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/5533Bridge reachability over IPv62020-06-13T14:18:40ZLinus Nordberglinus@torproject.orgBridge reachability over IPv6Bridge authorities need to check reachability for bridges with an IPv6 address over IPv6.Bridge authorities need to check reachability for bridges with an IPv6 address over IPv6.Tor: 0.2.4.x-finalLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/5534Make bridge authorities add "a" lines to router status entries2020-06-13T14:21:16ZLinus Nordberglinus@torproject.orgMake bridge authorities add "a" lines to router status entriesAs per prop 186, an "a" line should be added to router status entries
in network status documents for each reachable bridge.As per prop 186, an "a" line should be added to router status entries
in network status documents for each reachable bridge.Tor: 0.2.4.x-finalLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/5535Make clients use "a" lines in network status documents2020-06-13T14:18:43ZLinus Nordberglinus@torproject.orgMake clients use "a" lines in network status documentsAs per prop 186, a client which can use IPv6 should use should be
added to router status entry "a" lines.As per prop 186, a client which can use IPv6 should use should be
added to router status entry "a" lines.Tor: 0.2.4.x-finalLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/5547Add support for resolving destination names to IPv6 and exiting to IPv6 desti...2020-06-13T14:18:47ZKarsten LoesingAdd support for resolving destination names to IPv6 and exiting to IPv6 destinationsItem 24 from [org/sponsors/SponsorF/Year2](org/sponsors/SponsorF/Year2) is: "Support for resolving destination names to IPv6 and exiting to IPv6 destinations."
Summarizing [phase 5 of the IPv6 roadmap](https://gitweb.torproject.org/tors...Item 24 from [org/sponsors/SponsorF/Year2](org/sponsors/SponsorF/Year2) is: "Support for resolving destination names to IPv6 and exiting to IPv6 destinations."
Summarizing [phase 5 of the IPv6 roadmap](https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-ipv6-roadmap.txt#l143), this deliverable consists of the following substeps:
- We'll need to get our DNS resolver to support IPv6 addresses, and our clients to decide which address to report to the client and which to use.
- Transport IPv6 traffic and exit to IPv6 servers. The issues to solve here are exit policies; formulating an approach similar to the notion of topologically close in IPv4 (same /16) to IPv6, unless it doesn't make sense; and implementing the specified enhancements to RELAY_BEGIN cells from tor-spec.
- We need to extend TorDNSEL/TorBEL and the part of ExoneraTor that processes the TorDNSEL/TorBEL output.
- We also need to update VisiTor to handle IPv6 addresses in web server logs and compare them to exit lists. (There are zero known VisiTor users, so this should be considered optional.)
Anything else we need to do here?
Scheduling this ticket for November, not for July, because we'll be busy making clients talk to private and public bridges (phases 3 and 4 of the IPv4 roadmap) until [June](https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorG#Phase3:June302012).Tor: 0.2.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/5595Some relays tried to refetch maatuska's new certificate repeatedly2020-06-13T14:18:57ZRobert RansomSome relays tried to refetch maatuska's new certificate repeatedlykoolfy reports the following log message on one of his relays:
```
05:12:01 [WARN] Got a certificate for maatuska, but we already have it. Maybe they haven't updated it. Waiting for
a while. [64 duplicates hidden]
```
“64 duplicates hid...koolfy reports the following log message on one of his relays:
```
05:12:01 [WARN] Got a certificate for maatuska, but we already have it. Maybe they haven't updated it. Waiting for
a while. [64 duplicates hidden]
```
“64 duplicates hidden” is _bad_.Tor: 0.2.4.x-finalAndrea ShepardAndrea Shepardhttps://gitlab.torproject.org/legacy/trac/-/issues/5610Tor 0.2.2.35 ignores ExcludeExitNodes list, also cannot connect when ExitNod...2020-06-13T14:19:05ZTracTor 0.2.2.35 ignores ExcludeExitNodes list, also cannot connect when ExitNodes specifiedInstalled Vidalia Tor bundle for Win (not the Tor browser bundle), Vidalia 0.2.17 Tor 0.2.2.35. In an effort to ensure the exit node used is in the USA, Added to torrc :
StrictNodes 1
ExcludeExitNodes {AD},{AE},{AF},{AG},{AI},{AL} ( + m...Installed Vidalia Tor bundle for Win (not the Tor browser bundle), Vidalia 0.2.17 Tor 0.2.2.35. In an effort to ensure the exit node used is in the USA, Added to torrc :
StrictNodes 1
ExcludeExitNodes {AD},{AE},{AF},{AG},{AI},{AL} ( + many other country codes not including US))
However, Tor seems to ignore the list of country codes and will still exit through arbitrary countries in the list. Problem persists though restarts of Tor and the Win7 computer.
Also tried ExitNodes, both with {<country code>} , node name, and node signature. ( for example, ExitNodes {us} )
When trying to specify just US exit nodes, the result was Tor not connecting, log displays:
Apr 12 16:48:53.777 [Warning] failed to choose an exit server
Apr 12 16:48:54.759 [Notice] All routers are down or won't exit or are Excluded -- choosing a doomed exit at random.
Apr 12 16:48:54.759 [Warning] No specified non-excluded exit routers seem to be running: can't choose an exit.
Apr 12 16:48:54.759 [Warning] failed to choose an exit server
**Trac**:
**Username**: stevecryeTor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/5809Get rid of routerinfo_t->testing_since?2020-06-13T14:19:29ZLinus Nordberglinus@torproject.orgGet rid of routerinfo_t->testing_since?routerinfo_t->testing_since is not being used for anything.
Should we get rid of it or keep it for a rainy day?routerinfo_t->testing_since is not being used for anything.
Should we get rid of it or keep it for a rainy day?Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/5823Remove dirreq-v2-* and dirreq-v?-share statistics2020-06-13T14:19:30ZKarsten LoesingRemove dirreq-v2-* and dirreq-v?-share statisticsThe v2 directory protocol is (almost?) dead, and we stopped using dirreq-v?-share lines, because they were highly inaccurate. Should we stop including these lines in extra-info descriptors? If so, I can prepare a patch.The v2 directory protocol is (almost?) dead, and we stopped using dirreq-v?-share lines, because they were highly inaccurate. Should we stop including these lines in extra-info descriptors? If so, I can prepare a patch.Tor: 0.2.4.x-finalKarsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/5956Thresholds of nodes to build circuits should be tunable and maybe consider we...2020-06-13T14:19:50ZNick MathewsonThresholds of nodes to build circuits should be tunable and maybe consider weights tooOn #5343, Mike notes that he doesn't like the 1/3 threshold for having sufficient exit nodes to build circuits.
Arguably, this threshold (and the other threshold changed in #3196) should be consensus parameters too.
Arguably, there sho...On #5343, Mike notes that he doesn't like the 1/3 threshold for having sufficient exit nodes to build circuits.
Arguably, this threshold (and the other threshold changed in #3196) should be consensus parameters too.
Arguably, there should also (or instead?) be a minimum threshold by weight.
I'm marking this for 0.2.4.x, but it's likely to be very backportable.Tor: 0.2.4.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/5974Add configuration option for indicating if a directory authority is on IPv6 o...2020-06-13T14:19:54ZLinus Nordberglinus@torproject.orgAdd configuration option for indicating if a directory authority is on IPv6 or notBackground from #5534:
TODO: Add a configuration option telling tor if it's supposed to
have IPv6 connectivity. This will be something like
AuthorityHasIPv6Connectivity 0|1|auto. Clients and ordinary relays
will have to detect t...Background from #5534:
TODO: Add a configuration option telling tor if it's supposed to
have IPv6 connectivity. This will be something like
AuthorityHasIPv6Connectivity 0|1|auto. Clients and ordinary relays
will have to detect this.
This should be an option for authorities only for use until we have
good automatic detection of IPv6 connectivity.
The idea is that an authority with this option set to 0 will emit "a"
lines with IPv6 relay addresses without performing reachability tests.
The reasoning behind it is that relays on IPv6 shouldn't be punished
by directory authorities not on IPv6.
Regarding its default value, I think that 'auto' would be a good
default. Once we have automatic detection in place, leaving this
option out will make no difference. In the meantime 'auto' will turn
into '0' and authorities will by default let "a" lines through.
Regarding automatic detection, I wonder how we can do that without
leaking information. Is it possible? If not, how much can we leak?
Should we add more config option(s) for enabling more leaky strategies?Tor: 0.2.4.x-finalLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/6026Relays don't realise that their IPv6 OR port has changed2020-06-13T14:20:01ZLinus Nordberglinus@torproject.orgRelays don't realise that their IPv6 OR port has changedretry_all_listeners() needs fixing, see #4847 for more info.retry_all_listeners() needs fixing, see #4847 for more info.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6044Tor can't use a named pipe for a hidden service key2020-06-13T14:20:14ZTracTor can't use a named pipe for a hidden service keyIf I try to use a named pipe for a hidden service key, Tor dies with
```
Jun 03 00:00:00.000 [notice] Tor 0.2.3.15-alpha-dev (git-ec7fd08ccfa878c3) opening log file.
Jun 03 00:00:00.000 [err] {FS} Can't read key from /tmp/tmp.SekAugJpK0/...If I try to use a named pipe for a hidden service key, Tor dies with
```
Jun 03 00:00:00.000 [notice] Tor 0.2.3.15-alpha-dev (git-ec7fd08ccfa878c3) opening log file.
Jun 03 00:00:00.000 [err] {FS} Can't read key from /tmp/tmp.SekAugJpK0/private_key"
Jun 03 00:00:00.000 [warn] {GENERAL} Error loading rendezvous service keys
Jun 03 00:00:00.000 [err] {BUG} set_options(): Bug: Acting on config options left us in a broken state. Dying.
```
**Trac**:
**Username**: katmagicTor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6055Re-enable TLS 1.1 and TLS 1.2 once they are fixed2020-06-13T14:20:16ZNick MathewsonRe-enable TLS 1.1 and TLS 1.2 once they are fixedSee #6033 for why we needed to disable TLS1.1 and TLS1.2.
We'd like to turn them back on once OpenSSL 1.0.1d comes out with the bugfix. The easiest way to do that will be to make the whole block that disables them conditional on the co...See #6033 for why we needed to disable TLS1.1 and TLS1.2.
We'd like to turn them back on once OpenSSL 1.0.1d comes out with the bugfix. The easiest way to do that will be to make the whole block that disables them conditional on the compile-time OpenSSL version.
Of course, we'll have the obvious problem: many vendors will only partially backport openssl changes, and will not bump the OpenSSL version when they do so. We should see where and how this is a problem: Right now, Ubuntu 12.04 (LTS!? :( ) seems to be the likeliest place for a problem to occur here, since it's shipping a patched 1.0.1 that it calls 1.0.1-4.
If we decide we need to re-enable TLS on these platforms too, here are the options I can think of:
* Try renegotiation with TLS 1.2 with ourselves at runtime. If that fails, disable TLS 1.1 and TLS 1.2.
* Have a compile-time or runtime option that tells us that openssl has been fixed.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6135Tune + tighten path bias parameters2020-06-13T14:21:58ZMike PerryTune + tighten path bias parametersThe path bias defenses in #5458 and #5956 will have tunable parameters to allow us to dial in on the lowest acceptable amount of bias while not also breaking stuff.
That is going to require more work and attention, though. It's possible...The path bias defenses in #5458 and #5956 will have tunable parameters to allow us to dial in on the lowest acceptable amount of bias while not also breaking stuff.
That is going to require more work and attention, though. It's possible that network scanners (ie #5459) can provide us with answers for #5458.
We can also ask our volunteer QA team to report what sorts of values they see in their logs for stuff like this, to get an idea on real ranges in real clients.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6143Implement server-side of proposal 198 ("Restore semantics of TLS ClientHello")2020-06-13T14:20:26ZNick MathewsonImplement server-side of proposal 198 ("Restore semantics of TLS ClientHello")In Tor 0.2.3.17-tbd, we implement the client side of proposal 198: our ClientHellos can now be taken seriously.
Early in Tor 0.2.4.x, we should have servers start recognize the new ClientHellos, and take them seriously.In Tor 0.2.3.17-tbd, we implement the client side of proposal 198: our ClientHellos can now be taken seriously.
Early in Tor 0.2.4.x, we should have servers start recognize the new ClientHellos, and take them seriously.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6164Possible assertion failure triggered by control port2020-06-13T14:20:29ZRobert RansomPossible assertion failure triggered by control portIn `routerstatus_format_entry` (in src/or/dirserv.c):
```
/* This assert can fire for the control port, because
* it can request NS documents before all descriptors
* have been fetched. */
```
This needs to be invest...In `routerstatus_format_entry` (in src/or/dirserv.c):
```
/* This assert can fire for the control port, because
* it can request NS documents before all descriptors
* have been fetched. */
```
This needs to be investigated during 0.2.4.x-alpha, and the fix may need to be backported.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6167Possible assertion failure in connection_ap_handshake_attach_circuit()2020-06-13T14:20:29ZNick MathewsonPossible assertion failure in connection_ap_handshake_attach_circuit()Vektor reports that an AdvOR user reported a failure of the assertion
```
tor_assert(introcirc->_base.purpose == CIRCUIT_PURPOSE_C_INTRODUCING);
```
in connection_ap_handshake_attach_circuit().
His fix is to replace the test in circu...Vektor reports that an AdvOR user reported a failure of the assertion
```
tor_assert(introcirc->_base.purpose == CIRCUIT_PURPOSE_C_INTRODUCING);
```
in connection_ap_handshake_attach_circuit().
His fix is to replace the test in circuit_is_acceptable() so that CIRCUIT_PURPOSE_C_INTRODUCE_ACK_WAIT circuits can no longer get returned.
We should investigate. Filing for 0.2.2 since ISTR that's what AdvOR is tracking.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6172GETCONF responses must be quoted2020-06-13T14:20:31ZneenaGETCONF responses must be quotedThe control spec says
```
264 Value may be a raw value or a quoted string. Tor will try to use
265 unquoted values except when the value could be misinterpreted through
266 not being quoted.
```
here https://gitweb.torproj...The control spec says
```
264 Value may be a raw value or a quoted string. Tor will try to use
265 unquoted values except when the value could be misinterpreted through
266 not being quoted.
```
here https://gitweb.torproject.org/torspec.git/blob/master:/control-spec.txt#l264
GETCONF returns values which seperated by spaces without quoting them (this would be something that could be misinterpreted). Tor should respond with quoted values.
Ex:
```
getconf log
250 Log=notice stdout
```
should be
```
getconf log
250 Log="notice stdout"
```Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6174De-kludgify marking circs as unsuitable for new streams2020-06-13T14:20:32ZRobert RansomDe-kludgify marking circs as unsuitable for new streams```
/* XXXX024 This is a screwed-up way to say "This is too dirty
* for new circuits. */
circ->timestamp_dirty -= options->MaxCircuitDirtiness;
```
```
/* XXXX024 this is a kludgy way to do this. */
tor_assert(...```
/* XXXX024 This is a screwed-up way to say "This is too dirty
* for new circuits. */
circ->timestamp_dirty -= options->MaxCircuitDirtiness;
```
```
/* XXXX024 this is a kludgy way to do this. */
tor_assert(circ->timestamp_dirty);
circ->timestamp_dirty -= options->MaxCircuitDirtiness;
```
```
/* XXXX024 this is a kludgy way to do this. */
tor_assert(circ->_base.timestamp_dirty);
circ->_base.timestamp_dirty -= get_options()->MaxCircuitDirtiness;
```
Yes, it is, and wrong in several different ways too.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6177Refactor rend_service_introduce()2020-06-13T14:20:33ZAndrea ShepardRefactor rend_service_introduce()This function looks like something that crawled out of Cthulhu's navel, loathesomely redolent of spheres. Sanity is a scarce resource and we shouldn't squander it thus.This function looks like something that crawled out of Cthulhu's navel, loathesomely redolent of spheres. Sanity is a scarce resource and we shouldn't squander it thus.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6255Tor crashes on startup.2020-06-13T14:20:44ZTracTor crashes on startup.7c9f6a99 crashes on startup. An info-level log is below.
```
Jan 00:00:00.000 [notice] Tor 0.2.4.0-alpha-dev (git-7c9f6a994f610b27) opening new log file.
Jan 01 00:00:00.000 [info] {FS} tor_lockfile_lock(): Locking "/var/lib/tor/lock"
...7c9f6a99 crashes on startup. An info-level log is below.
```
Jan 00:00:00.000 [notice] Tor 0.2.4.0-alpha-dev (git-7c9f6a994f610b27) opening new log file.
Jan 01 00:00:00.000 [info] {FS} tor_lockfile_lock(): Locking "/var/lib/tor/lock"
Jan 01 00:00:00.000 [info] {GENERAL} entry_guards_parse_state(): Read 123/150 path bias for node Node
Jan 01 00:00:00.000 [info] {GENERAL} entry_guards_parse_state(): Read 43/55 path bias for node Node
Jan 01 00:00:00.000 [info] {GENERAL} entry_guards_parse_state(): Read 149/189 path bias for node Node
Jan 01 00:00:00.000 [info] {GENERAL} entry_guards_parse_state(): Read 83/94 path bias for node Node
Jan 01 00:00:00.000 [info] {GENERAL} entry_guards_parse_state(): Read 2/2 path bias for node Node
Jan 01 00:00:00.000 [info] {GENERAL} or_state_load(): Loaded state from "/var/lib/tor/state"
Jan 01 00:00:00.000 [info] {GENERAL} entry_guards_parse_state(): Read 123/150 path bias for node Node
Jan 01 00:00:00.000 [info] {GENERAL} entry_guards_parse_state(): Read 43/55 path bias for node Node
Jan 01 00:00:00.000 [info] {GENERAL} entry_guards_parse_state(): Read 149/189 path bias for node Node
Jan 01 00:00:00.000 [info] {GENERAL} entry_guards_parse_state(): Read 83/94 path bias for node Node
Jan 01 00:00:00.000 [info] {GENERAL} entry_guards_parse_state(): Read 2/2 path bias for node Node
Jan 01 00:00:00.000 [info] {CIRC} remove_obsolete_entry_guards(): Entry guard 'Node' (0000000000000000000000000000000000000000) was selected several months ago. (Version="0.2.3.15-alpha-dev".) Replacing it.
Jan 01 00:00:00.000 [info] {CIRC} log_entry_guards(): Node [0000000000000000000000000000000000000000] (no descriptor, made-contact), Node [0000000000000000000000000000000000000000] (no descriptor, made-contact),Node [0000000000000000000000000000000000000000] (no descriptor, made-contact), Node [0000000000000000000000000000000000000000] (no descriptor, made-contact),Node [0000000000000000000000000000000000000000] (no descriptor, made-contact),Node [0000000000000000000000000000000000000000] (no descriptor, made-contact),Node [0000000000000000000000000000000000000000] (bad, made-contact), Node [0000000000000000000000000000000000000000] (no descriptor, made-contact),Node [0000000000000000000000000000000000000000] (no descriptor, made-contact),Node [0000000000000000000000000000000000000000] (no descriptor, made-contact),Node [0000000000000000000000000000000000000000] (no descriptor, made-contact),Node [0000000000000000000000000000000000000000] (bad, made-contact),Node [0000000000000000000000000000000000000000] (no descriptor, made-contact),Node [0000000000000000000000000000000000000000] (no descriptor, made-contact),Node [0000000000000000000000000000000000000000] (no descriptor, made-contact),Node [0000000000000000000000000000000000000000] (no descriptor, made-contact),Node [0000000000000000000000000000000000000000] (no descriptor, made-contact)
Jan 01 00:00:00.000 [info] {CIRC} circuit_build_times_parse_state(): Adding 7 timeouts.
Jan 01 00:00:00.000 [info] {CIRC} circuit_build_times_parse_state(): Loaded 1000/1000 values from 166 lines in circuit time histogram
Jan 01 00:00:00.000 [info] {CIRC} circuit_build_times_get_xm(): Xm mode #0: 775 43
Jan 01 00:00:00.000 [info] {CIRC} circuit_build_times_get_xm(): Xm mode #1: 875 42
Jan 01 00:00:00.000 [info] {CIRC} circuit_build_times_get_xm(): Xm mode #2: 775 43
Jan 01 00:00:00.000 [info] {CIRC} circuit_build_times_set_timeout(): Based on 1000 circuit times, it looks like we don't need to wait so long for circuits to finish. We will now assume a circuit is too slow to use after waiting 3 seconds.
Jan 01 00:00:00.000 [info] {CIRC} circuit_build_times_set_timeout(): Circuit timeout data: 0.00000ms, 0.000000ms, Xm: 0, a: 1.000000, r: 0.000000
Jan 01 00:00:00.000 [info] {FS} read_file_to_str(): Could not open "/var/lib/tor/router-stability": No such file or directory
Jan 01 00:00:00.000 [info] {CONFIG} addressmap_register(): Addressmap: (re)mapped '[scrubbed]' to '[scrubbed]'
Jan 01 00:00:00.000 [info] {CONFIG} addressmap_register(): Addressmap: (re)mapped '[scrubbed]' to '[scrubbed]'
Jan 01 00:00:00.000 [info] {CONFIG} addressmap_register(): Addressmap: (re)mapped '[scrubbed]' to '[scrubbed]'
Jan 01 00:00:00.000 [info] {CONFIG} addressmap_register(): Addressmap: (re)mapped '[scrubbed]' to '[scrubbed]'
Jan 01 00:00:00.000 [info] {CONFIG} addressmap_register(): Addressmap: (re)mapped '[scrubbed]' to '[scrubbed]'
Jan 01 00:00:00.000 [info] {CONFIG} addressmap_register(): Addressmap: (re)mapped '[scrubbed]' to '[scrubbed]'
Jan 01 00:00:00.000 [info] {CONFIG} addressmap_register(): Addressmap: (re)mapped '[scrubbed]' to '[scrubbed]'
Jan 01 00:00:00.000 [info] {CONFIG} addressmap_register(): Addressmap: (re)mapped '[scrubbed]' to '[scrubbed]'
Jan 01 00:00:00.000 [info] {CONFIG} addressmap_register(): Addressmap: (re)mapped '[scrubbed]' to '[scrubbed]'
Jan 01 00:00:00.000 [info] {CONFIG} addressmap_register(): Addressmap: (re)mapped '[scrubbed]' to '[scrubbed]'
Jan 01 00:00:00.000 [info] {CONFIG} parse_reachable_addresses(): Using ReachableAddresses as ReachableORAddresses.
Jan 01 00:00:00.000 [info] {CONFIG} parse_reachable_addresses(): Using ReachableAddresses as ReachableDirAddresses
Jan 01 00:00:00.000 [info] {REND} rend_service_load_all_keys(): Loading hidden-service keys from "/var/lib/tor/hs"
Jan 01 00:00:00.000 [info] {CONFIG} rend_service_load_auth_keys(): Parsed 3 previously stored client entries.
```
**Trac**:
**Username**: katmagicTor: 0.2.4.x-finalAndrea ShepardAndrea Shepardhttps://gitlab.torproject.org/legacy/trac/-/issues/6297SOCKS issues with bitcoin in .2.3.18-rc vs .2.2.372020-06-13T14:20:52ZTracSOCKS issues with bitcoin in .2.3.18-rc vs .2.2.37Support for propagating and selectively connecting through tor's socks proxy for onion addresses has recently been merged into Bitcoin.
The support as it stands right now works with .2.2.37 but the socks connect fails with 0x01 (general...Support for propagating and selectively connecting through tor's socks proxy for onion addresses has recently been merged into Bitcoin.
The support as it stands right now works with .2.2.37 but the socks connect fails with 0x01 (general failure) using .2.3.18-rc.
I have pcaps of the working .2.2.37 functionality on an OS X 10.7 client using the browser bundle binaries and of the broken functionality on wheezy using the .2.3.18-rc wheezy packages.
In addition I have pcaps of connect.c (ProxyCommand for ssh/etc to use socks) going through the same onion addresses and working on both versions. I did this by running an sshd listening on the bitcoin port for these tests.
Everything in the handshake looks right to me except for the error response in .2.3.18-rc.
(The onion addresses in the dumps are public nodes.)
I tried adding NoIsolateSOCKSAuth and NoIsolateClientAddr to the SocksPort declaration but it didn't make any difference.
All that shows up in the .2.3.18-rc logs is the following (debug):
Jul 04 14:57:42.000 [warn] Socks version 0 not recognized. (Tor is not an http proxy.)
Jul 04 14:57:42.000 [warn] Fetching socks handshake failed. Closing.
Jul 04 14:57:43.000 [warn] Socks version 0 not recognized. (Tor is not an http proxy.)
Jul 04 14:57:43.000 [warn] Fetching socks handshake failed. Closing.
**Trac**:
**Username**: jrmithdobbsTor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6302Use SOCK_ERRNO consistently2020-06-13T14:20:53ZNick MathewsonUse SOCK_ERRNO consistentlyEverywhere that we currently say
```
#ifdef _WIN32
frobnicate(WSAENOWOMBATS);
#else
frobnicate(ENOWOMBATS);
#endif
```
we ought instead to just say:
```
frobincate(SOCK_ERRNO(ENOWOMBATS));
```
in order to help get internal #ifdefs...Everywhere that we currently say
```
#ifdef _WIN32
frobnicate(WSAENOWOMBATS);
#else
frobnicate(ENOWOMBATS);
#endif
```
we ought instead to just say:
```
frobincate(SOCK_ERRNO(ENOWOMBATS));
```
in order to help get internal #ifdefs out of our functions.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6304CircuitBuildTimeout default value does not match man page2020-06-13T14:20:54ZDavid Fifielddcf@torproject.orgCircuitBuildTimeout default value does not match man pageRunning tor with
```
LearnCircuitBuildTimeout 0
```
and not specifiying any `CircuitBuildTimeout` gives a misleading warning about a timeout of 0:
```
Jul 05 02:48:16.974 [warn] CircuitBuildTimeout is shorter (0 seconds) than recommended...Running tor with
```
LearnCircuitBuildTimeout 0
```
and not specifiying any `CircuitBuildTimeout` gives a misleading warning about a timeout of 0:
```
Jul 05 02:48:16.974 [warn] CircuitBuildTimeout is shorter (0 seconds) than recommended (10 seconds), and LearnCircuitBuildTimeout is disabled. If tor isn't working, raise this value or enable LearnCircuitBuildTimeout.
```
The ticket that resulted in this warning is #5452.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6321Write a proposal for unverified DNS caching2020-06-13T14:20:57ZJacob AppelbaumWrite a proposal for unverified DNS cachingWe need a proposal for making Tor clients only cache DNS on a per circuit basis unless verified by DNSSEC. In the absence of DNSSEC, we should not share DNS cache state between circuits.We need a proposal for making Tor clients only cache DNS on a per circuit basis unless verified by DNSSEC. In the absence of DNSSEC, we should not share DNS cache state between circuits.Tor: 0.2.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/6342different streams have too close exit node IP's2020-06-13T14:21:04Zproperdifferent streams have too close exit node IP'sExample:
TransPort gets x.x.x.120
SocksPort gets x.x.x.121
Happens sometimes. I suspect that both IP's are owned by the same family. The exit node could still correlate both connections.Example:
TransPort gets x.x.x.120
SocksPort gets x.x.x.121
Happens sometimes. I suspect that both IP's are owned by the same family. The exit node could still correlate both connections.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6344Implement proposal 204: ignore subdomains in hidden service addresses2020-06-13T14:21:05ZLunarImplement proposal 204: ignore subdomains in hidden service addressesAttached is a patch that implements proposal 204. The present version address Nick's comments made on <https://lists.torproject.org/pipermail/tor-dev/2012-July/003723.html>.Attached is a patch that implements proposal 204. The present version address Nick's comments made on <https://lists.torproject.org/pipermail/tor-dev/2012-July/003723.html>.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6350Extra-info descriptors contain extra space between nickname and fingerprint2020-06-13T17:56:41ZKarsten LoesingExtra-info descriptors contain extra space between nickname and fingerprintStarting 16 hours ago, a relay started publishing the following extra-info descriptor that makes metrics-lib choke:
```
extra-info free EB2798A84E9D962DF13C61FA055C2513DDDAF800
published 2012-07-08 13:36:56
router-signature
-----BEGIN ...Starting 16 hours ago, a relay started publishing the following extra-info descriptor that makes metrics-lib choke:
```
extra-info free EB2798A84E9D962DF13C61FA055C2513DDDAF800
published 2012-07-08 13:36:56
router-signature
-----BEGIN SIGNATURE-----
nn7itViCioERo/QzaKYB5AKu/ufMjukORZBU4QXqL0PPSvjDVix1+ckK8J5xYJc7
6fie9moyZpUK+bdz4xzIf/YECMbGwT3lJOZO59f+vMwQycI6tRWHyCWc9A941Mf4
6hrvwRj7IKgIcJdhxFp3FevREx5CCA3f+yhWJdAbQ5s=
-----END SIGNATURE-----
```
metrics-lib would expect a single SP between nickname and fingerprint, which is the default for most descriptor lines. I'm not entirely certain that dir-spec.txt doesn't allow two SP though:
```
"extra-info" Nickname Fingerprint NL
```
The space between Nickname and Fingerprint could be interpreted as SP (which is what I did in many places that didn't have an explicit definition of SP), or it could be considered WS which is defined as `WS = (SP | TAB)+`.
So, should the directory authorities reject this descriptor for being malformed? Or should metrics-lib (and stem) interpret multiple SP as well as any combination of SP and TAB as keyword separator whenever there's no explicit definition in dir-spec.txt?Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6364Make sure the NETINFO cells include and use IPv6 addresses correctly2020-06-13T14:21:09ZLinus Nordberglinus@torproject.orgMake sure the NETINFO cells include and use IPv6 addresses correctlyTor: 0.2.4.x-finalLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/6406Add configuration option for directory authorities to vote on "a" lines2020-06-13T14:21:15ZLinus Nordberglinus@torproject.orgAdd configuration option for directory authorities to vote on "a" linesWhen deploying relays with IPv6 OR port(s) (#4564) we will want to
make it possible for directory authority operators to select if they
should vote on "a" lines or not. Add a configuration option,
AuthDirUseIPv6, indicating that a direc...When deploying relays with IPv6 OR port(s) (#4564) we will want to
make it possible for directory authority operators to select if they
should vote on "a" lines or not. Add a configuration option,
AuthDirUseIPv6, indicating that a directory authority should test OR
ports given in "or-address" lines in server descriptors and vote on
them. There might be a better name for the config option.
#5534 implements the testing and writing "a" lines to status
documents. This is done for bridge authorities only. That test
should be replaced with a test for the above mentioned config option.Tor: 0.2.4.x-finalLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/6416tor current compile breakage circuitbuild.c - dual def'n of transport_t2020-06-13T14:21:19ZTractor current compile breakage circuitbuild.c - dual def'n of transport_tIn file included from circuitbuild.c:29:
transports.h:28: error: redefinition of typedef 'transport_t'
circuitbuild.h:140: error: previous declaration of 'transport_t' was here
*** Error code 1
Stop.
make: stopped in /usr/local/src/tor/...In file included from circuitbuild.c:29:
transports.h:28: error: redefinition of typedef 'transport_t'
circuitbuild.h:140: error: previous declaration of 'transport_t' was here
*** Error code 1
Stop.
make: stopped in /usr/local/src/tor/src/or
*** Error code 1
Developers need to harmonize transports.h:28 and circuitbuild.h:140
**Trac**:
**Username**: yancmTor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6423Adding, removing or changing an IPv6 OR port isn't a cosmetic change2020-06-13T14:21:22ZLinus Nordberglinus@torproject.orgAdding, removing or changing an IPv6 OR port isn't a cosmetic changerouter_differences_are_cosmetic() needs to take a potential IPv6 OR
port in consideration when deciding if a router has changed
substantially or not.router_differences_are_cosmetic() needs to take a potential IPv6 OR
port in consideration when deciding if a router has changed
substantially or not.Tor: 0.2.4.x-finalLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/6465Build abstraction layer around TLS2020-06-13T14:22:45ZAndrea ShepardBuild abstraction layer around TLSRight now the code in connection.c/connection_or.c is tightly coupled to TLS. This makes it hard to experiment with different transports. A new abstraction, channel_t, should be introduce which hides the details of how cells get from o...Right now the code in connection.c/connection_or.c is tightly coupled to TLS. This makes it hard to experiment with different transports. A new abstraction, channel_t, should be introduce which hides the details of how cells get from one node to the next.
Possible follow-on: add mechanism for nodes to advertise support for multiple transports, replace IPv4 addresses in cells with flexible variable-length transport-specific address fields, investigate path selection if multi-transport network means the connectivity graph is no longer a complete graph on the set of all nodes.Tor: 0.2.4.x-finalAndrea ShepardAndrea Shepardhttps://gitlab.torproject.org/legacy/trac/-/issues/6468OR connection early-flush code in connection_handle_write_impl is needless2020-06-13T14:21:28ZNick MathewsonOR connection early-flush code in connection_handle_write_impl is needlessLong ago, before we had cell queues, it was necessary to maybe call connection_handle_write() from connectino_write_to_buf_impl() on OR connections, so that we wouldn't get into a loop of reading infinite amounts of data and queueing it ...Long ago, before we had cell queues, it was necessary to maybe call connection_handle_write() from connectino_write_to_buf_impl() on OR connections, so that we wouldn't get into a loop of reading infinite amounts of data and queueing it all on an outbuf before bothering to write any data.
If that doesn't sounds like what our code does now, you're right: right now, we won't stick more than OR_CONN_HIGHWATER bytes of cells on an outbuf, and we won't suck more than CELL_QUEUE_HIGHWATER_SIZE cells off any edge connection. So, there's no more call for that code.
Removing this code will simplify our code flow, and that should be something we can all get behind.
Discovered by a user on IRC. Marking this for 0.2.4, though we can backport to 0.2.3 if it turns out to be safe. If we're not 100% sure here, we could simulate before merging.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6517Redundant calls to check_sockaddr_family_match in connection_handle_listener_...2020-06-13T14:21:38ZMatthew FinkelRedundant calls to check_sockaddr_family_match in connection_handle_listener_readcheck_sockaddr_family_match is called twice without an apparent reason. It should be reasonable to remove the second instance assuming check_sockaddr does not modify *remote (constifying ticket coming soon).check_sockaddr_family_match is called twice without an apparent reason. It should be reasonable to remove the second instance assuming check_sockaddr does not modify *remote (constifying ticket coming soon).Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6519Update connection_init's documentation2020-06-13T14:21:39ZMatthew FinkelUpdate connection_init's documentationconnection_init has been updated/refactored but the documentation did not go with it.
Ex. The function no longer allocates space for a socks_request nor does it assign a pseudorandom number for next_circ_id.connection_init has been updated/refactored but the documentation did not go with it.
Ex. The function no longer allocates space for a socks_request nor does it assign a pseudorandom number for next_circ_id.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6522[PATCH] Enable automake silent rules2020-06-13T14:21:40ZTrac[PATCH] Enable automake silent rulestwo patches to enable automake silent rules by default for build, including documentation builds (second patch).
This makes it easier to see compiler warnings.
As usual, it can be disabled with "make V=1" for any specific invocation of...two patches to enable automake silent rules by default for build, including documentation builds (second patch).
This makes it easier to see compiler warnings.
As usual, it can be disabled with "make V=1" for any specific invocation of make
**Trac**:
**Username**: stewartTor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6524[PATCH] move to non-recursive make2020-06-13T14:21:42ZTrac[PATCH] move to non-recursive makeThis patch switches the automake foo over to non-recursive make.
This gives us a few benefits:
1) make -j clean all
this will start working, as it should. It currently doesn't.
2) increased parallel build
r...This patch switches the automake foo over to non-recursive make.
This gives us a few benefits:
1) make -j clean all
this will start working, as it should. It currently doesn't.
2) increased parallel build
recursive make will max out at number of files in a directory,
non-recursive make doesn't have such a limitation
3) Removal of duplicate information in make files,
less error prone
I've also slightly updated how we call AM_INIT_AUTOMAKE, as the way
that was used was not only deprecated but will be *removed* in the next
major automake release (1.13).... so probably best that we can continue
to bulid tor without requiring old automake.
(see http://www.gnu.org/software/automake/manual/html_node/Public-Macros.html )
For more reasons why, see resources such as:
http://miller.emu.id.au/pmiller/books/rmch/
Technically, this applies on top of the patches in https://trac.torproject.org/projects/tor/ticket/6522 - but they're probably not *required*
**Trac**:
**Username**: stewartTor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6526Implement directory guards2020-06-13T14:25:48ZRobert RansomImplement directory guardsTor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6532bootstrapping conecting to tor network2012-08-03T08:09:09ZTracbootstrapping conecting to tor networkAllways getting warning: stuck at 80%: connecting to the tor network ( connection time out (wsaetimedout) timeout;count 1;recomendation warn)
**Trac**:
**Username**: pericoAllways getting warning: stuck at 80%: connecting to the tor network ( connection time out (wsaetimedout) timeout;count 1;recomendation warn)
**Trac**:
**Username**: pericoTor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6538Use bit-twiddling tricks to make choose-by-bandwith algorithm even more time-...2020-06-13T14:21:45ZNick MathewsonUse bit-twiddling tricks to make choose-by-bandwith algorithm even more time-invariantSee #6537 for discussion. There's a branch in the middle of our node selection algorithm, which is bad for time-invariance. Furthermore, a sufficiently clever compiler might decide to reinsert the break statement that 6537 so carefully...See #6537 for discussion. There's a branch in the middle of our node selection algorithm, which is bad for time-invariance. Furthermore, a sufficiently clever compiler might decide to reinsert the break statement that 6537 so carefully removed. (I have not yet found a compiler this clever, but better safe than sorry!)
We can probably do better by using a bit-twiddling approach to setting i_chosen. For example, rransom wrote:
```
i_chosen = 0;
i_hasnt_been_chosen = ~0;
for (...) {
int64_t choose_this_i;
tmp += int_bandwidths[i];
choose_this_i = rand_bw - (tmp+1);
choose_this_i = choose_this_i >> 63;
/* choose_this_i = -1 if rand_bw < (tmp+1); choose_this_i = 0 otherwise */
i_chosen |= (i & choose_this_i & i_hasnt_been_chosen);
i_hasnt_been_chosen &= ~choose_this_i;
}
i = i_chosen;
```
This looks okay to me; more eyes are needed here, though.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6572“Bug: Circuit somehow completed a hop while the network was not live.”2020-06-13T14:21:49ZTrac“Bug: Circuit somehow completed a hop while the network was not live.”[Tue Aug 7 19:50:10 2012] Tor Software Error - The Tor software encountered an internal bug. Please report the following error message to the Tor developers at bugs.torproject.org: "circuit_build_times_network_close(): Bug: Circuit someh...[Tue Aug 7 19:50:10 2012] Tor Software Error - The Tor software encountered an internal bug. Please report the following error message to the Tor developers at bugs.torproject.org: "circuit_build_times_network_close(): Bug: Circuit somehow completed a hop while the network was not live. Network was last live at 2012-08-07 19:49:09, but circuit launched at 2012-08-07 19:49:10. It's now 2012-08-07 19:50:10.
"
happened after i got a faster upload deal from my isp (just for an exit node), and a new router.
**Trac**:
**Username**: bpmcontrolTor: 0.2.4.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/6595different streams sometimes end up with same exit node IP2020-06-13T14:21:50Zproperdifferent streams sometimes end up with same exit node IPRelated to #6342.
It happens that different SocksPorts end up with the very same exit IP, thus stream isolation is practically ignored.
Seldom, but happens.
If you are interested I can provide shell scripts for checking different Sock...Related to #6342.
It happens that different SocksPorts end up with the very same exit IP, thus stream isolation is practically ignored.
Seldom, but happens.
If you are interested I can provide shell scripts for checking different Socks- or TransPorts reporting if they get the same exit IP.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6598Update dir-spec with "a" lines2020-06-13T14:21:51ZLinus Nordberglinus@torproject.orgUpdate dir-spec with "a" linesProposal 186 specifies "a" lines to go in votes and consensuses.
dir-spec needs to be updated to include "a" lines and a new voting method.Proposal 186 specifies "a" lines to go in votes and consensuses.
dir-spec needs to be updated to include "a" lines and a new voting method.Tor: 0.2.4.x-finalLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/6599./configure script using option -q2020-06-13T14:21:51ZTrac./configure script using option -qThe configure script is not quiet when using the option -q.
# ./configure --prefix=/ -q
tor_cv_library_openssl_dir is (system)
#
OS: OpenBSD 5.1
**Trac**:
**Username**: tgredemarkThe configure script is not quiet when using the option -q.
# ./configure --prefix=/ -q
tor_cv_library_openssl_dir is (system)
#
OS: OpenBSD 5.1
**Trac**:
**Username**: tgredemarkTor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6605Default 5MB/10MB rate limits are too low2020-06-13T14:21:52ZRoger DingledineDefault 5MB/10MB rate limits are too lowOnce upon a time, I picked 5MB rate / 10MB burst as rate limiting numbers that were basically infinite. It turns out they're now limiting our 100mbit relays and bridges.
Should we raise the numbers? I don't think it will surprise anybod...Once upon a time, I picked 5MB rate / 10MB burst as rate limiting numbers that were basically infinite. It turns out they're now limiting our 100mbit relays and bridges.
Should we raise the numbers? I don't think it will surprise anybody who wouldn't already be surprised by the current numbers.
What should we raise them to? 25MB / 50MB? 50MB / 100MB? Should we future-proof ourselves more thoroughly and say 1GB / 2GB?Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6621Authorities shouldn't set Running unless all advertised OR ports are reachable2020-06-13T14:21:54ZLinus Nordberglinus@torproject.orgAuthorities shouldn't set Running unless all advertised OR ports are reachableProp 186 says
An authority shouldn't list a node as Running unless every
or-address line it advertises looks like it will work.
Authorities don't consider a potential IPv6 OR port when deciding
whether a relay is running or not.
I...Prop 186 says
An authority shouldn't list a node as Running unless every
or-address line it advertises looks like it will work.
Authorities don't consider a potential IPv6 OR port when deciding
whether a relay is running or not.
I suggest we fix that but have auths not on IPv6
(AuthDirHasIPv6Connectivity == 0) not take IPv6 reachability into
account.Tor: 0.2.4.x-finalLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/6638Lots of Unknown Error in tor.log2020-06-13T14:21:57ZTracLots of Unknown Error in tor.logusing git.
Aug 19 21:17:54.000 [warn] unknown error for INTRODUCE2 on circ 53605
Aug 19 21:18:17.000 [warn] unknown error for INTRODUCE2 on circ 11793
Aug 19 21:18:49.000 [warn] unknown error for INTRODUCE2 on circ 30079
Aug 19 21:19:03...using git.
Aug 19 21:17:54.000 [warn] unknown error for INTRODUCE2 on circ 53605
Aug 19 21:18:17.000 [warn] unknown error for INTRODUCE2 on circ 11793
Aug 19 21:18:49.000 [warn] unknown error for INTRODUCE2 on circ 30079
Aug 19 21:19:03.000 [warn] unknown error for INTRODUCE2 on circ 30079
Aug 19 21:19:36.000 [warn] unknown error for INTRODUCE2 on circ 53605
**Trac**:
**Username**: oyvindsTor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6673tor crashes silently with non-threaded openssl build2020-06-13T14:22:00ZLeonid Evdokimovtor crashes silently with non-threaded openssl buildI've seen lots of cryptic crashes of tor on my openwrt gateway: https://atlas.torproject.org/#details/F44DA505AD91CFC8D5745BB070909F20F21E06D9
I've recently decided to debug this issue and run tor with --Daemon 0 under tmux and I got as...I've seen lots of cryptic crashes of tor on my openwrt gateway: https://atlas.torproject.org/#details/F44DA505AD91CFC8D5745BB070909F20F21E06D9
I've recently decided to debug this issue and run tor with --Daemon 0 under tmux and I got assertion failure:
```
...
Aug 24 00:43:13.842 [notice] Performing bandwidth self-test...done.
/usr/sbin/tor: md_rand.c: 325: ssleay_rand_add: Assertion `md_c[1] == md_count[1]' failed.
Aborted
```
Accoding to openssl code it means that openssl was built without OPENSSL_THREADS
```
crypto/rand/md_rand.c
320- if (entropy < ENTROPY_NEEDED) /* stop counting when we have enough */
321- entropy += add;
322- if (!do_not_lock) CRYPTO_w_unlock(CRYPTO_LOCK_RAND);
323-
324-#if !defined(OPENSSL_THREADS) && !defined(OPENSSL_SYS_WIN32)
325: assert(md_c[1] == md_count[1]);
326-#endif
327- }
328-
329-static void ssleay_rand_seed(const void *buf, int num)
330- {
```
If OPENSSL_THREADS is required for tor to work, then tor should probably check for it in compile-time:
```
openssl-1.0.1/doc/crypto/threads.pod
You can find out if OpenSSL was configured with thread support:
#define OPENSSL_THREAD_DEFINES
#include <openssl/opensslconf.h>
#if defined(OPENSSL_THREADS)
// thread support enabled
#else
// no thread support
#endif
```
If OPENSSL_THREADS is not required, than it looks like either bug in tor itself or in tor<->openssl interaction.
libopenssl - 1.0.1c-1
tor - 0.2.2.37-1
P.S. related OpenWrt ticket: https://dev.openwrt.org/ticket/12072Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6731man page entry for TestingTorNetwork gives an out-of-date list2020-06-13T14:22:06ZRoger Dingledineman page entry for TestingTorNetwork gives an out-of-date listIn 'man tor', the TestingTorNetwork stanza tries to list all the things it changes. Which is great, but I bet we don't update it when we change testing_tor_network_defaults[] in the code.
Perhaps the man page stanza should point to a gi...In 'man tor', the TestingTorNetwork stanza tries to list all the things it changes. Which is great, but I bet we don't update it when we change testing_tor_network_defaults[] in the code.
Perhaps the man page stanza should point to a gitweb url with a hint about what to search for? That would still be messy because it would vary by major tor version, but it would be more future-proof.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6736Tor is a bit loud at startup2020-06-13T14:22:07ZNick MathewsonTor is a bit loud at startupHere is a typical startup log:
```
Aug 30 02:06:48.496 [notice] Tor v0.2.4.0-alpha-dev (git-661bd3fe714f0c99) running on Darwin.
Aug 30 02:06:48.496 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.t...Here is a typical startup log:
```
Aug 30 02:06:48.496 [notice] Tor v0.2.4.0-alpha-dev (git-661bd3fe714f0c99) running on Darwin.
Aug 30 02:06:48.496 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Aug 30 02:06:48.496 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Aug 30 02:06:48.496 [notice] Configuration file "/usr/local/etc/tor/torrc" not present, using reasonable defaults.
Aug 30 02:06:48.499 [notice] Initialized libevent version 2.1.1-alpha-dev using method kqueue. Good.
Aug 30 02:06:48.499 [notice] Opening Socks listener on 127.0.0.1:9050
Aug 30 02:06:48.000 [notice] No AES engine found; using AES_* functions.
Aug 30 02:06:48.000 [notice] This version of OpenSSL has a slow implementation of counter mode; not using it.
Aug 30 02:06:48.000 [notice] OpenSSL OpenSSL 0.9.8r 8 Feb 2011 looks like version 0.9.8m or later; I will try SSL_OP to enable renegotiation
Aug 30 02:06:48.000 [notice] Reloaded microdescriptor cache. Found 0 descriptors.
Aug 30 02:06:48.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
Aug 30 02:06:49.000 [notice] Bootstrapped 5%: Connecting to directory server.
Aug 30 02:06:49.000 [notice] Heartbeat: Tor's uptime is 0:00 hours, with 1 circuits open. I've sent 0 kB and received 0 kB.
Aug 30 02:06:49.000 [notice] Bootstrapped 10%: Finishing handshake with directory server.
Aug 30 02:06:49.000 [notice] We weren't able to find support for all of the TLS ciphersuites that we wanted to advertise. This won't hurt security, but it might make your Tor (if run as a client) more easy for censors to block.
Aug 30 02:06:49.000 [notice] To correct this, use a more recent OpenSSL, built without disabling any secure ciphers or features.
Aug 30 02:06:50.000 [notice] Bootstrapped 15%: Establishing an encrypted directory connection.
Aug 30 02:06:50.000 [notice] Bootstrapped 20%: Asking for networkstatus consensus.
Aug 30 02:06:50.000 [notice] Bootstrapped 25%: Loading networkstatus consensus.
Aug 30 02:06:51.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
Aug 30 02:06:52.000 [notice] Bootstrapped 40%: Loading authority key certs.
Aug 30 02:06:53.000 [notice] Bootstrapped 45%: Asking for relay descriptors.
Aug 30 02:06:53.000 [notice] I learned some more directory information, but not enough to build a circuit: We have only 0/3067 usable microdescriptors.
Aug 30 02:06:55.000 [notice] We now have enough directory information to build circuits.
Aug 30 02:06:55.000 [notice] Bootstrapped 80%: Connecting to the Tor network.
Aug 30 02:06:55.000 [notice] Bootstrapped 85%: Finishing handshake with first hop.
Aug 30 02:06:55.000 [notice] Bootstrapped 90%: Establishing a Tor circuit.
Aug 30 02:06:57.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Aug 30 02:06:57.000 [notice] Bootstrapped 100%: Done.
```
That's 29 lines to say "everything's okay."Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6757ClientPreferIPv6ORPort not honoured when running with bridges2020-06-13T14:22:12ZLinus Nordberglinus@torproject.orgClientPreferIPv6ORPort not honoured when running with bridgesSince get_configured_bridge_by_routerinfo() returns the same bridge
regardless of which routerinfo we pass to it, the first found
(seemingly the one configured first in the config file).
One effect of this is that rewrite_node_address_f...Since get_configured_bridge_by_routerinfo() returns the same bridge
regardless of which routerinfo we pass to it, the first found
(seemingly the one configured first in the config file).
One effect of this is that rewrite_node_address_for_bridge() will
prefer whatever is listed first. Looking at ClientPreferIPv6 wouldn't
make sense here since we come here once (only one routerinfo is
received), unless we start calling it for every configured
bridge. That doesn't seem like the right thing though.
Note that the idea of having ipv6_preferred as a property of the
node_t is that we'd like to be able to change its value, per relay,
when we learn about how we have been in touch with the relay.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6758No need to print first heartbeat message2020-06-13T14:22:13ZRoger DingledineNo need to print first heartbeat message```
Sep 03 17:57:38.000 [notice] Heartbeat: Tor's uptime is 0:00 hours, with 1 circuits open. I've sent 0 kB and received 0 kB.
```
This line doesn't tell me anything, and based on #6736 it is mildly harmful.```
Sep 03 17:57:38.000 [notice] Heartbeat: Tor's uptime is 0:00 hours, with 1 circuits open. I've sent 0 kB and received 0 kB.
```
This line doesn't tell me anything, and based on #6736 it is mildly harmful.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6760Quiet initial "learned some more directory information" log message2020-06-13T14:22:13ZRoger DingledineQuiet initial "learned some more directory information" log messageOn initial bootstrap, we get
```
Sep 03 19:15:34.000 [notice] Reloaded microdescriptor cache. Found 0 descriptors.
Sep 03 19:15:34.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no usa...On initial bootstrap, we get
```
Sep 03 19:15:34.000 [notice] Reloaded microdescriptor cache. Found 0 descriptors.
Sep 03 19:15:34.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
Sep 03 19:15:35.000 [notice] Bootstrapped 5%: Connecting to directory server.
Sep 03 19:15:35.000 [notice] Heartbeat: Tor's uptime is 0:00 hours, with 1 circuits open. I've sent 0 kB and received 0 kB.
```
The "bootstrapped 5%" line is useful (more precisely, its absence is useful).
The "learned some more directory information" line is actually false in this case though: it got triggered because we called directory_info_has_arrived() from do_main_loop(), to jumpstart it into calling update_all_descriptor_downloads() for us.
The only case where we call directory-info-has-arrived with from_cache == 1 is this initial jumpstarting case.
I suggest we quiet the log message when from_cache is 1.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6763Combine "m" lines with identical hash values2020-06-13T14:22:15ZLinus Nordberglinus@torproject.orgCombine "m" lines with identical hash valuesdirserv_generate_networkstatus_vote_obj() recently (or soon to be,
depending on how you see it -- it sits in my branch bug6363_5535)
started generating two "m" lines in votes, one for consensus methods
8-13 and one for method 14 ("a" lin...dirserv_generate_networkstatus_vote_obj() recently (or soon to be,
depending on how you see it -- it sits in my branch bug6363_5535)
started generating two "m" lines in votes, one for consensus methods
8-13 and one for method 14 ("a" lines).
For relays without an IPv6 address (i.e. not including an "or-address"
line in their descriptor), the two hashes will be identical.
As an optimisation we could combine two "m" lines with identical hash
values. As an example, instead of saying
```
"m 1,2,3 H1"
"m 4,5 H1"
```
we would say
```
"m 1,2,3,4,5 H1"
```
but still say
```
"m 1,2,3 H1"
"m 4,5 H2"
```
This affects the size of the votes only and don't affect bandwidth
consumption for ordinary relays or clients in any way.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6765Defensive programming: Use tor_malloc_zero() in var_cell_new()2020-06-13T14:22:15ZGeorge KadianakisDefensive programming: Use tor_malloc_zero() in var_cell_new()To be sure that we don't leak any memory to the network (a la CVE-2011-4576), it would be good if we used `tor_malloc_zero()` in `var_cell_new()`. We currently use `tor_malloc()` which does not clean memory.
We currently seem to be sett...To be sure that we don't leak any memory to the network (a la CVE-2011-4576), it would be good if we used `tor_malloc_zero()` in `var_cell_new()`. We currently use `tor_malloc()` which does not clean memory.
We currently seem to be setting `var_cell_t.payload` and `var_cell_t.payload_len` correctly before calls to `connection_or_write_var_cell_to_buf()`, but it would be good to future-proof ourselves.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6768Client fails to pick an exit for https connection2020-06-13T14:22:17ZLinus Nordberglinus@torproject.orgClient fails to pick an exit for https connectionA TorTestingNetwork with 11 relays (3 dir auths, 1 bridge auth), most
of them running master as of late August plus IPv6 patches. Client and
exit running master as of early Sept without IPv6 patches.
Exit policy accept port 80, 443 and ...A TorTestingNetwork with 11 relays (3 dir auths, 1 bridge auth), most
of them running master as of late August plus IPv6 patches. Client and
exit running master as of early Sept without IPv6 patches.
Exit policy accept port 80, 443 and deny *. Haven't been able to
reproduce with default exit policy (i.e. no ExitPolicy directive in
config).
curl https://check.torproject.org/ fails with client saying
```
Sep 04 23:54:01.000 [info] exit circ (length 3, last hop dfri02x): $80CC45020AC1073A767DB5D038A31ED50D56F869(open) $42C79519EAB12BA36C627194DC4BD2228E67EB0F(open) $E0CF1972093B7D13DF82A620D56CFD0A6BB7687A(open)
Sep 04 23:54:01.000 [debug] circuit_send_next_onion_skin(): starting to send subsequent skin.
Sep 04 23:54:01.000 [debug] circuit_build_times_disabled(): CircuitBuildTime learning is not disabled. Consensus=0, Config=0, AuthDir=0, StateFile=0
Sep 04 23:54:01.000 [debug] circuit_build_times_add_time(): Adding circuit build time 13
Sep 04 23:54:01.000 [debug] circuit_build_times_disabled(): CircuitBuildTime learning is not disabled. Consensus=0, Config=0, AuthDir=0, StateFile=0
Sep 04 23:54:01.000 [info] circuit_build_times_get_xm(): Xm mode #0: 225 116
Sep 04 23:54:01.000 [info] circuit_build_times_get_xm(): Xm mode #1: 275 111
Sep 04 23:54:01.000 [info] circuit_build_times_get_xm(): Xm mode #2: 325 86
Sep 04 23:54:01.000 [info] circuit_build_times_set_timeout_worker(): Circuit build measurement period of 60000ms is more than twice the maximum build time we have ever observed. Capping it to 2150ms.
Sep 04 23:54:01.000 [info] circuit_build_times_set_timeout(): Set buildtimeout to low value 487.234426ms. Setting to 1500ms
Sep 04 23:54:01.000 [info] circuit_build_times_set_timeout(): Set circuit build timeout to 2s (1500.000000ms, 2150.000000ms, Xm: 270, a: 2.726366, r: 0.000000) based on 1000 circuit times
Sep 04 23:54:01.000 [info] circuit_send_next_onion_skin(): circuit built!
Sep 04 23:54:01.000 [info] pathbias_count_success(): Got success count 192/186 for guard ndn00a=80CC45020AC1073A767DB5D038A31ED50D56F869
Sep 04 23:54:01.000 [notice] pathbias_count_success(): Bug: Unexpectedly high circuit_successes (192/186) for guard ndn00a=80CC45020AC1073A767DB5D038A31ED50D56F869
Sep 04 23:54:01.000 [debug] new_route_len(): Chosen route length 3 (11/11 routers suitable).
Sep 04 23:54:01.000 [info] choose_good_exit_server_general(): Found 0 servers that might support 0/1 pending connections.
Sep 04 23:54:01.000 [info] choose_good_exit_server_general(): We couldn't find any live, fast routers; falling back to list of all routers.
Sep 04 23:54:01.000 [info] choose_good_exit_server_general(): Found 0 servers that might support 0/1 pending connections.
Sep 04 23:54:01.000 [notice] All routers are down or won't exit -- choosing a doomed exit at random.
```Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6770Default value for AuthDirPublishIPv6 not honoured2020-06-13T14:22:19ZLinus Nordberglinus@torproject.orgDefault value for AuthDirPublishIPv6 not honouredAuthDirPublishIPv6 is AUTOBOOL.
AUTOBOOL defaults to -1.
We check AuthDirPublishIPv6 like this
```
options->AuthDirHasIPv6Connectivity == 0
```
in two places where we want to test whether it's "unset" or not. This
test will fail fo...AuthDirPublishIPv6 is AUTOBOOL.
AUTOBOOL defaults to -1.
We check AuthDirPublishIPv6 like this
```
options->AuthDirHasIPv6Connectivity == 0
```
in two places where we want to test whether it's "unset" or not. This
test will fail for AuthDirPublishIPv6 being -1.
After an interesting discussion with Roger on IRC, I suggest we make
this option BOOL.
The motivation is that we should have AUTOBOOL options only for things
decided from information from the consensus or the operating system
we're running on. Once we have code for autodetecting IPv6 support
from the OS we can turn it back into an AUTOBOOL again.Tor: 0.2.4.x-final