Tor 0.3.2.4-alpha is released, with several stability fixes

by nickm | November 8, 2017

Tor 0.3.2.4-alpha is the fourth alpha release in the 0.3.2.x series. It fixes several stability and reliability bugs, especially including a major reliability issue that has been plaguing fast exit relays in recent months.

You can download the source from the usual place on the website. Binary packages should be available soon, with an alpha Tor Browser likely in the next week or so.

Remember: This is an alpha release, and it's likely to have more bugs than usual. We hope that people will try it out to find and report bugs, though.

Changes in version 0.3.2.4-alpha - 2017-11-08

  • Major bugfixes (exit relays, DNS):
    • Fix an issue causing DNS to fail on high-bandwidth exit nodes, making them nearly unusable. Fixes bugs 21394 and 18580; bugfix on 0.1.2.2-alpha, which introduced eventdns. Thanks to Dhalgren for identifying and finding a workaround to this bug and to Moritz, Arthur Edelstein, and Roger for helping to track it down and analyze it.
  • Major bugfixes (scheduler, channel):
    • Stop processing scheduled channels if they closed while flushing cells. This can happen if the write on the connection fails leading to the channel being closed while in the scheduler loop. Fixes bug 23751; bugfix on 0.3.2.1-alpha.

 

  • Minor features (logging, scheduler):
    • Introduce a SCHED_BUG() function to log extra information about the scheduler state if we ever catch a bug in the scheduler. Closes ticket 23753.
  • Minor features (removed deprecations):
    • The ClientDNSRejectInternalAddresses flag can once again be set in non-testing Tor networks, so long as they do not use the default directory authorities. This change also removes the deprecation of this flag from 0.2.9.2-alpha. Closes ticket 21031.
  • Minor features (testing):
    • Our fuzzing tests now test the encrypted portions of v3 onion service descriptors. Implements more of 21509.
  • Minor bugfixes (directory client):
    • On failure to download directory information, delay retry attempts by a random amount based on the "decorrelated jitter" algorithm. Our previous delay algorithm tended to produce extra-long delays too easily. Fixes bug 23816; bugfix on 0.2.9.1-alpha.
  • Minor bugfixes (IPv6, v3 single onion services):
    • Remove buggy code for IPv6-only v3 single onion services, and reject attempts to configure them. This release supports IPv4, dual-stack, and IPv6-only v3 onion services; and IPv4 and dual- stack v3 single onion services. Fixes bug 23820; bugfix on 0.3.2.1-alpha.
  • Minor bugfixes (logging, relay):
    • Give only a protocol warning when the ed25519 key is not consistent between the descriptor and microdescriptor of a relay. This can happen, for instance, if the relay has been flagged NoEdConsensus. Fixes bug 24025; bugfix on 0.3.2.1-alpha.
  • Minor bugfixes (manpage, onion service):
    • Document that the HiddenServiceNumIntroductionPoints option is 0-10 for v2 services and 0-20 for v3 services. Fixes bug 24115; bugfix on 0.3.2.1-alpha.
  • Minor bugfixes (memory leaks):
    • Fix a minor memory leak at exit in the KIST scheduler. This bug should have no user-visible impact. Fixes bug 23774; bugfix on 0.3.2.1-alpha.
    • Fix a memory leak when decrypting a badly formatted v3 onion service descriptor. Fixes bug 24150; bugfix on 0.3.2.1-alpha. Found by OSS-Fuzz; this is OSS-Fuzz issue 3994.
  • Minor bugfixes (onion services):
    • Cache some needed onion service client information instead of constantly computing it over and over again. Fixes bug 23623; bugfix on 0.3.2.1-alpha.
    • Properly retry HSv3 descriptor fetches when missing required directory information. Fixes bug 23762; bugfix on 0.3.2.1-alpha.
  • Minor bugfixes (path selection):
    • When selecting relays by bandwidth, avoid a rounding error that could sometimes cause load to be imbalanced incorrectly. Previously, we would always round upwards; now, we round towards the nearest integer. This had the biggest effect when a relay's weight adjustments should have given it weight 0, but it got weight 1 instead. Fixes bug 23318; bugfix on 0.2.4.3-alpha.
    • When calculating the fraction of nodes that have descriptors, and all nodes in the network have zero bandwidths, count the number of nodes instead. Fixes bug 23318; bugfix on 0.2.4.10-alpha.
    • Actually log the total bandwidth in compute_weighted_bandwidths(). Fixes bug 24170; bugfix on 0.2.4.3-alpha.
  • Minor bugfixes (relay, crash):
    • Avoid a crash when transitioning from client mode to bridge mode. Previously, we would launch the worker threads whenever our "public server" mode changed, but not when our "server" mode changed. Fixes bug 23693; bugfix on 0.2.6.3-alpha.
  • Minor bugfixes (testing):
    • Fix a spurious fuzzing-only use of an uninitialized value. Found by Brian Carpenter. Fixes bug 24082; bugfix on 0.3.0.3-alpha.
    • Test that IPv6-only clients can use microdescriptors when running "make test-network-all". Requires chutney master 61c28b9 or later. Closes ticket 24109.

Comments

Please note that the comment area below has been archived.

November 10, 2017

Permalink

I was planning to switch my hidden service from V2 to V3 after "0.3.2 stable" is released.
Should/Can I try V3 now, or I should wait another 1 year(0.3.3 stable)?

Will I become compromize if I try V3 now(0.3.2 alpha)? Can anyone say 0.3.2_stable is a go-sign for V3 onion?

November 19, 2017

Permalink

Here is an onion using hidden service v3. 6xqzuxcqiz63hzdotbgpddiu4qr4z6n4lxztb32hfkfxwj64rnsofaid.onion
I believe you need the 7.5 alpha tor browser to access the new longer onion site names.

November 28, 2017

Permalink

nice

December 06, 2017

Permalink

Is it possible to block TOR browser from commenting on Disqus?

I visit web-pages that normally allows readers using FIREFOX browser to view/make comments on DISQUS. When I use TOR browser the web-page does not load comments.

Does this mean the web owner has blocked TOR browser?

That could be one reason, yes. Another one could be that the Disqus comment system is implemented in a way that gets broken by Tor Browser's tracking defenses. I am not sure yet which one is the case. Might be worth investigating.