New release: Tor 0.4.5.8

by nickm | May 10, 2021

We have a new stable release today. If you build Tor from source, you can download the source code for Tor 0.4.5.8 on the download page. Packages should be available within the next several weeks, with a new Tor Browser likely next week.

Tor 0.4.5.8 fixes several bugs in earlier version, backporting fixes from the 0.4.6.x series.

Changes in version 0.4.5.8 - 2021-05-10

  • Minor features (compatibility, Linux seccomp sandbox, backport from 0.4.6.3-rc):
    • Add a workaround to enable the Linux sandbox to work correctly with Glibc 2.33. This version of Glibc has started using the fstatat() system call, which previously our sandbox did not allow. Closes ticket 40382; see the ticket for a discussion of trade-offs.
  • Minor features (compilation, backport from 0.4.6.3-rc):
    • Make the autoconf script build correctly with autoconf versions 2.70 and later. Closes part of ticket 40335.

 

  • Minor features (fallback directory list, backport from 0.4.6.2-alpha):
    • Regenerate the list of fallback directories to contain a new set of 200 relays. Closes ticket 40265.
  • Minor features (geoip data):
    • Update the geoip files to match the IPFire Location Database, as retrieved on 2021/05/07.
  • Minor features (onion services):
    • Add warning message when connecting to now deprecated v2 onion services. As announced, Tor 0.4.5.x is the last series that will support v2 onions. Closes ticket 40373.
  • Minor bugfixes (bridge, pluggable transport, backport from 0.4.6.2-alpha):
    • Fix a regression that made it impossible start Tor using a bridge line with a transport name and no fingerprint. Fixes bug 40360; bugfix on 0.4.5.4-rc.
  • Minor bugfixes (build, cross-compilation, backport from 0.4.6.3-rc):
    • Allow a custom "ar" for cross-compilation. Our previous build script had used the $AR environment variable in most places, but it missed one. Fixes bug 40369; bugfix on 0.4.5.1-alpha.
  • Minor bugfixes (channel, DoS, backport from 0.4.6.2-alpha):
    • Fix a non-fatal BUG() message due to a too-early free of a string, when listing a client connection from the DoS defenses subsystem. Fixes bug 40345; bugfix on 0.4.3.4-rc.
  • Minor bugfixes (compiler warnings, backport from 0.4.6.3-rc):
    • Fix an indentation problem that led to a warning from GCC 11.1.1. Fixes bug 40380; bugfix on 0.3.0.1-alpha.
  • Minor bugfixes (controller, backport from 0.4.6.1-alpha):
    • Fix a "BUG" warning that would appear when a controller chooses the first hop for a circuit, and that circuit completes. Fixes bug 40285; bugfix on 0.3.2.1-alpha.
  • Minor bugfixes (onion service, client, memory leak, backport from 0.4.6.3-rc):
    • Fix a bug where an expired cached descriptor could get overwritten with a new one without freeing it, leading to a memory leak. Fixes bug 40356; bugfix on 0.3.5.1-alpha.
  • Minor bugfixes (testing, BSD, backport from 0.4.6.2-alpha):
    • Fix pattern-matching errors when patterns expand to invalid paths on BSD systems. Fixes bug 40318; bugfix on 0.4.5.1-alpha. Patch by Daniel Pinto.

Comments

Please note that the comment area below has been archived.

Anonymous (not verified) said:

May 11, 2021

Permalink

Thank you tor people :)

> Packages should be available within the next several weeks, with a new Tor Browser likely next week.

Hey I have a question I just thought of. I use qubes-whonix where the tor client runs in a separate VM and the browser's bundled Tor client is disabled. However the browser's built-in auto-update mechanism is not disabled in whonix.

Does this create a fingerprinting risk for whonix users during the time between when the browser updates itself, and when the Tor client package ships? I.e. due to using mismatched versions of Tor Browser and Tor client, compared to regular users who are using the bundled tor client?

I'm not a developer, but I don't think a mismatch of daemon versions would create a fingerprinting risk for TBB. If I understand correctly, your tor daemon is visible to only your first relay (guard or bridge), but the traffic and metadata of your browser (or any torified application that uses the daemon as a proxy) are encrypted from your daemon to the end of the circuit of relays. The exit relay doesn't receive data about your tor daemon as far as I know, but there's always the possibility of unstudied forms of traffic analysis and timing analysis.

Make sure the tor daemon that isn't bundled has its torrc file configured similarly to the one for the bundled daemon, e.g. not selecting or excluding specific sets of nodes or configuring other options that could increase your fingerprint.