New Alpha Release: Tor 0.4.2.3-alpha

by nickm | October 24, 2019

There's a new alpha release available for download. If you build Tor from source, you can download the source code for 0.4.2.3-alpha from the download page on the website. Packages should be available over the coming weeks, with a new alpha Tor Browser release in a couple of weeks.

Remember, this is an alpha release: you should only run this if you'd like to find and report more bugs than usual.

This release fixes several bugs from the previous alpha release, and from earlier versions of Tor.

Changes in version 0.4.2.3-alpha - 2019-10-24

  • Major bugfixes (relay):
    • Relays now respect their AccountingMax bandwidth again. When relays entered "soft" hibernation (which typically starts when we've hit 90% of our AccountingMax), we had stopped checking whether we should enter hard hibernation. Soft hibernation refuses new connections and new circuits, but the existing circuits can continue, meaning that relays could have exceeded their configured AccountingMax. Fixes bug 32108; bugfix on 0.4.0.1-alpha.
  • Major bugfixes (v3 onion services):
    • Onion services now always use the exact number of intro points configured with the HiddenServiceNumIntroductionPoints option (or fewer if nodes are excluded). Before, a service could sometimes pick more intro points than configured. Fixes bug 31548; bugfix on 0.3.2.1-alpha.

 

  • Minor feature (onion services, control port):
    • The ADD_ONION command's keyword "BEST" now defaults to ED25519-V3 (v3) onion services. Previously it defaulted to RSA1024 (v2). Closes ticket 29669.
  • Minor features (testing):
    • When running tests that attempt to look up hostnames, replace the libc name lookup functions with ones that do not actually touch the network. This way, the tests complete more quickly in the presence of a slow or missing DNS resolver. Closes ticket 31841.
  • Minor features (testing, continuous integration):
    • Disable all but one Travis CI macOS build, to mitigate slow scheduling of Travis macOS jobs. Closes ticket 32177.
    • Run the chutney IPv6 networks as part of Travis CI. Closes ticket 30860.
    • Simplify the Travis CI build matrix, and optimise for build time. Closes ticket 31859.
    • Use Windows Server 2019 instead of Windows Server 2016 in our Appveyor builds. Closes ticket 32086.
  • Minor bugfixes (build system):
    • Interpret "--disable-module-dirauth=no" correctly. Fixes bug 32124; bugfix on 0.3.4.1-alpha.
    • Interpret "--with-tcmalloc=no" correctly. Fixes bug 32124; bugfix on 0.2.0.20-rc.
    • Stop failing when jemalloc is requested, but tcmalloc is not found. Fixes bug 32124; bugfix on 0.3.5.1-alpha.
    • When pkg-config is not installed, or a library that depends on pkg-config is not found, tell the user what to do to fix the problem. Fixes bug 31922; bugfix on 0.3.1.1-alpha.
  • Minor bugfixes (connections):
    • Avoid trying to read data from closed connections, which can cause needless loops in Libevent and infinite loops in Shadow. Fixes bug 30344; bugfix on 0.1.1.1-alpha.
  • Minor bugfixes (error handling):
    • Always lock the backtrace buffer before it is used. Fixes bug 31734; bugfix on 0.2.5.3-alpha.
  • Minor bugfixes (mainloop, periodic events, in-process API):
    • Reset the periodic events' "enabled" flag when Tor is shut down cleanly. Previously, this flag was left on, which caused periodic events not to be re-enabled when Tor was relaunched in-process with tor_api.h after a shutdown. Fixes bug 32058; bugfix on 0.3.3.1-alpha.
  • Minor bugfixes (process management):
    • Remove overly strict assertions that triggered when a pluggable transport failed to launch. Fixes bug 31091; bugfix on 0.4.0.1-alpha.
    • Remove an assertion in the Unix process backend. This assertion would trigger when we failed to find the executable for a child process. Fixes bug 31810; bugfix on 0.4.0.1-alpha.
  • Minor bugfixes (testing):
    • Avoid intermittent test failures due to a test that had relied on inconsistent timing sources. Fixes bug 31995; bugfix on 0.3.1.3-alpha.
    • When testing port rebinding, don't busy-wait for tor to log. Instead, actually sleep for a short time before polling again. Also improve the formatting of control commands and log messages. Fixes bug 31837; bugfix on 0.3.5.1-alpha.
  • Minor bugfixes (tls, logging):
    • Log bugs about the TLS read buffer's length only once, rather than filling the logs with similar warnings. Fixes bug 31939; bugfix on 0.3.0.4-rc.
  • Minor bugfixes (v3 onion services):
    • Fix an implicit conversion from ssize_t to size_t discovered by Coverity. Fixes bug 31682; bugfix on 0.4.2.1-alpha.
    • Fix a memory leak in an unlikely error code path when encoding HS DoS establish intro extension cell. Fixes bug 32063; bugfix on 0.4.2.1-alpha.
    • When cleaning up intro circuits for a v3 onion service, don't remove circuits that have an established or pending circuit, even if they ran out of retries. This way, we don't remove a circuit on its last retry. Fixes bug 31652; bugfix on 0.3.2.1-alpha.
  • Documentation:
    • Correct the description of "GuardLifetime". Fixes bug 31189; bugfix on 0.3.0.1-alpha.
    • Make clear in the man page, in both the bandwidth section and the AccountingMax section, that Tor counts in powers of two, not powers of ten: 1 GByte is 1024*1024*1024 bytes, not one billion bytes. Resolves ticket 32106.

Comments

Please note that the comment area below has been archived.

Anonymous (not verified) said:

October 24, 2019

Permalink

I've been using tor with the obfs4 bridges. After many months, my entry guard node has recently changed. Looking at the circuits, now I see a new guard consistently being the first node.

However, at the beginning of each tor connection there are also 2 other nodes listed at the top of circuit list, and they disappear shortly. Strangely, I recognize one of them as my former long-term guard last year. The other has only a slightly different name; must be a node from the same family.

Is this normal for the tor nightly master 0.4.3 alpha package? If not, any advice?

This is normal for Tor (and not just the 0.4.2 alphas). Your main guard is called your "entry guard", and the three of them together make up your "directory guards". The directory guards fetch information about the Tor network, but only the entry guard is used for circuits that will carry your application traffic.

In an ideal world you would use your one entry guard as your one directory guard, but it's a balance: the reason you have multiple directory guards is to limit attacks where a single directory guard might choose to not provide you information about certain relays, thus letting it influence the paths your client can make.

Same poster (not verified) said:

October 31, 2019

Permalink

OK. But then, is it normal that the 2 directory guards are named nearly identically (differing in the end numbers)? Should not they be diversified?

You are commenting in the wrong blog post. This one is about Tor and not Tor Browser. However, to get back to your request: disabling letterboxing, while not recommended, is of course possible. You need to flip the governing preference, privacy.resistFingerprinting.letterboxing , on about:config.

Yep. Would we rather try to teach people what we mean by gigabyte, or teach people that there's a surprise word they've never heard of called gibibyte, or change Tor's notion of the word and then teach a different set of people what we mean by it? Hard to win. At least now we're making it even clearer what Tor does.

Which self-appointed people? Consumers or scientists and engineers? The prefix giga- exists for all metric units throughout the sciences and has meant the base-10 characteristic x10^9 since the 1920s. As x10^9, it has been an IUPAC international chemistry standard since 1947 or earlier and an SI metric standard since 1960. Computer drive and network hardware manufacturers and have always expressed capacities in base-10. Macintosh computers since launching in 1984, base-10. Microsoft Windows since 1985, base-2. And that, I think, is when customer confusion began. IEEE 100-1988 in 1988 defined a gigabyte as base-2. Some organizations proposed base-10 adherence and new base-2 prefixes in the 1990s. IEEE switched from base-2 adherence to base-10 in 1997, and on it goes.

So I blame Microsoft.

JR (not verified) said:

October 25, 2019

Permalink

Gotta say Tails 4.0 is a huge step backwards for me. I have been running Tails/Tor from a 2GB live USB drive for years. The .img instead of .iso thing was annoying (I dont want to download a 100+MB program just to install a USB image since usb universal installer never works) but I overcame that with Rufus.

But upon boot, I am informed that an *8GB* drive is needed and Tails fails to load. Needing 4 times the drive to run ??? What gives?

> But upon boot... Tails fails to load [because it wants an 8GB drive]

I don't understand what you mean. LiveUSBs don't work that way. If the image wasn't written correctly, the writer should've told you. If you're trying to install to a hard drive, you're doing it wrong. If it's asking for a hard drive, it's doing something wrong. If it meant 8GB of RAM, I might start to understand. Live-booting images are compressed. Anyway, ask Tails developers.

Ali (not verified) said:

October 28, 2019

Permalink

I heven't been able to use Tor since the last update. I tried re-installing it multiple times now. i keep getting the following error: "The program can't start because api-ms-win-crt-convert-l1-1-0.dll is missing from your computer. Try reinstalling the program to fix this problem."

You're asking in the wrong place. You are talking about Tor Browser, but this post is about the tor network daemon. Read the post titles.

Anyway, run Windows Update or manually install the Universal C Runtime (CRT) update:
https://support.microsoft.com/en-us/help/2999226/update-for-universal-c…
For specifics of what's inside it such as the dll, click "File information".

The preferred method to centrally install the Universal CRT is to use Microsoft Windows Update. The Universal CRT is a Recommended update for all supported Microsoft Windows operating systems, so by default, most machines install it as part of the regular update process. The initial release of the Universal CRT was KB2999226. A later update with various bug fixes was made in KB3118401, and there have been additional updates with further bug fixes and new features. For more recent updates, search support.microsoft.com for Universal C Runtime or Universal CRT.

Not all Microsoft Windows computers regularly install updates by use of Windows Update, and some may not install all Recommended updates. To support the use of applications built by using the Visual Studio 2015 and later C++ toolsets on those machines, there are Universal CRT redistributable files available for offline distribution. Those redistributable files may be downloaded from one of the KB links above. The Universal CRT redistributable requires that the machine has been updated to the current service pack. So, for example, the redistributable for Windows 7 will only install onto Windows 7 SP1, not Windows 7 RTM.

Because the Universal CRT is a fundamental dependency of the C++ libraries, the Visual C++ redistributable (VCRedist) installs the initial version of the Universal CRT (version 10.0.10240) on machines that don't already have one installed. This version is sufficient to satisfy the C++ library dependencies. If your application depends on a more recent version of the Universal CRT, you must use Windows Update to bring your machine fully up-to-date, or install that version explicitly. It's best to install the Universal C Runtime via Windows Update or an MSU before installing the VCRedist, to avoid potential multiple required reboots.

Not all operating systems are eligible for the most recent Universal C Runtime via Windows Update. On Windows 10, the centrally deployed version matches the version of the operating system. To update the Universal C Runtime further, you must update the operating system. For Windows Vista through Windows 8.1, the latest available Universal C Runtime is currently based on the version included in the Windows 10 Anniversary Update, with additional fixes (version 10.0.14393).

....000.....==… (not verified) said:

November 04, 2019

Permalink

Thanks for your work Dr. Nick, is it possible to create a TORRC command to let the user control the minimum level of which nodes version it will connect to which would be more aggressive than the hardcoded Tor version firewall?

This could also allow alpha testing features better in real world, if you wanted to run a client only connect to alpha builds of a certain minimum version.

Probably a command would be needed each for alpha and 1 for stable tor. For instance if only stable tor is set minimum tor will act on alpha command as the built in tor version firewall and the same the other way around. But for testing purposes it might need to accept a higher version than actually exists so you could cut off all connections when testing clients for either the alpha or stable branches. If possible not sure about that but it would be nice.

It would just be nice if somehow the user could have a more hardened version firewall if he chose that adhered to {se},{de} type notations and strictnodes 1.

Thanks

That would be interesting, but a bit dangerous: It's not a great idea for privacy to build paths that look very different from those made by other users. That said, you're right that it might be useful for testing.

Dr.Know (not verified) said:

November 08, 2019

Permalink

Yes, I find it really is only useful for big jumps like 4.15 ect......and other big improvements, I am more concerned with testing those services than blending in perfectly and alot of operators are slow to upgrade or don't even have time to follow certain upgraded developments.

But I am glad you like the idea, I do this manually which is why I ask lol maybe I should say pretty please.....but since it's on your radar hope you can assess it's usefulness and capabilities of allowing user controlled firewall.

It would save me a lot of time. As if certain country codes are set certain actors always like to dump bad nodes with old software which is hard to manually Exclude them when they always change or add and disappear.

But again it is mostly to be up to date with big jumps for testing.

Know (not verified) said:

November 05, 2019

Permalink

Actually, I think it would be better once user tor sets something like Torrc command StableFirewall 4.1.5 or just the first two 4.1 ect......

Than once the firewall adheres to Strictnodes 1 and {se},{ca} ect....isolate weather you want the firewall to adhere individually from the global setting using

EntryNodesUseFirewall 0 or 1 default is 1
MiddleNodesUseFirewall 0 or 1 default is 1
ExitNodesUseFirewall 0 or 1 default is 1

But if StableFirewall is 1 than it adheres globally even when UseEntryGuards 0 is set.