New alpha release: Tor 0.4.4.2-alpha

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

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

This is the second alpha release in the 0.4.4.x series. It fixes a few bugs in the previous release, and solves a few usability, compatibility, and portability issues.

This release also fixes TROVE-2020-001, a medium-severity denial of service vulnerability affecting all versions of Tor when compiled with the NSS encryption library. (This is not the default configuration.) Using this vulnerability, an attacker could cause an affected Tor instance to crash remotely. This issue is also tracked as CVE-2020- 15572. Anybody running a version of Tor built with the NSS library should upgrade to 0.3.5.11, 0.4.2.8, 0.4.3.6, or 0.4.4.2-alpha or later. If you're running with OpenSSL, this bug doesn't affect your Tor.

Changes in version 0.4.4.2-alpha - 2020-07-09

• Major bugfixes (NSS, security):
  • Fix a crash due to an out-of-bound memory access when Tor is compiled with NSS support. Fixes bug 33119; bugfix on 0.3.5.1-alpha. This issue is also tracked as TROVE-2020-001 and CVE-2020-15572.
• Minor features (bootstrap reporting):
  • Report more detailed reasons for bootstrap failure when the failure happens due to a TLS error. Previously we would just call these errors "MISC" when they happened during read, and "DONE" when they happened during any other TLS operation. Closes ticket 32622.

• Minor features (directory authority):
  • Authorities now recommend the protocol versions that are supported by Tor 0.3.5 and later. (Earlier versions of Tor have been deprecated since January of this year.) This recommendation will cause older clients and relays to give a warning on startup, or when they download a consensus directory. Closes ticket 32696.
• Minor features (entry guards):
  • Reinstate support for GUARD NEW/UP/DOWN control port events. Closes ticket 40001.
• Minor features (linux seccomp2 sandbox, portability):
  • Allow Tor to build on platforms where it doesn't know how to report which syscall caused the linux seccomp2 sandbox to fail. This change should make the sandbox code more portable to less common Linux architectures. Closes ticket 34382.
  • Permit the unlinkat() syscall, which some Libc implementations use to implement unlink(). Closes ticket 33346.
• Minor bugfix (CI, Windows):
  • Use the correct 64-bit printf format when compiling with MINGW on Appveyor. Fixes bug 40026; bugfix on 0.3.5.5-alpha.
• Minor bugfix (onion service v3 client):
  • Remove a BUG() warning that could occur naturally. Fixes bug 34087; bugfix on 0.3.2.1-alpha.
• Minor bugfix (SOCKS, onion service client):
  • Detect v3 onion service addresses of the wrong length when returning the F6 ExtendedErrors code. Fixes bug 33873; bugfix on 0.4.3.1-alpha.
• Minor bugfixes (compiler warnings):
  • Fix a compiler warning on platforms with 32-bit time_t values. Fixes bug 40028; bugfix on 0.3.2.8-rc.
• Minor bugfixes (control port, onion service):
  • Consistently use 'address' in "Invalid v3 address" response to ONION_CLIENT_AUTH commands. Previously, we would sometimes say 'addr'. Fixes bug 40005; bugfix on 0.4.3.1-alpha.
• Minor bugfixes (logging):
  • Downgrade a noisy log message that could occur naturally when receiving an extrainfo document that we no longer want. Fixes bug 16016; bugfix on 0.2.6.3-alpha.
• Minor bugfixes (onion services v3):
  • Avoid a non-fatal assertion failure in certain edge-cases when opening an intro circuit as a client. Fixes bug 34084; bugfix on 0.3.2.1-alpha.
• Deprecated features (onion service v2):
  • Add a deprecation warning for version 2 onion services. Closes ticket 40003.
• Removed features (IPv6, revert):
  • Revert the change in the default value of ClientPreferIPv6OrPort: it breaks the torsocks use case. The SOCKS resolve command has no mechanism to ask for a specific address family (v4 or v6), and so prioritizing IPv6 when an IPv4 address is requested on the SOCKS interface resulted in a failure. Tor Browser explicitly sets PreferIPv6, so this should not affect the majority of our users. Closes ticket 33796; bugfix on 0.4.4.1-alpha.