We have a new stable release today. If you build Tor from source, you can download the source code for 0.4.4.6 on the download page. Packages should be available within the next several weeks, with a new Tor Browser likely next week.
Tor 0.4.4.6 is the second stable release in the 0.4.4.x series. It backports fixes from later releases, including a fix for TROVE-2020- 005, a security issue that could be used, under certain cases, by an adversary to observe traffic patterns on a limited number of circuits intended for a different relay.
Changes in version 0.4.4.6 - 2020-11-12
Major bugfixes (security, backport from 0.4.5.1-alpha):
When completing a channel, relays now check more thoroughly to make sure that it matches any pending circuits before attaching those circuits. Previously, address correctness and Ed25519 identities were not checked in this case, but only when extending circuits on an existing channel. Fixes bug 40080; bugfix on 0.2.7.2-alpha. Resolves TROVE-2020-005.
Minor features (directory authorities, backport from 0.4.5.1-alpha):
Authorities now list a different set of protocols as required and recommended. These lists have been chosen so that only truly recommended and/or required protocols are included, and so that clients using 0.2.9 or later will continue to work (even though they are not supported), whereas only relays running 0.3.5 or later will meet the requirements. Closes ticket 40162.
Make it possible to specify multiple ConsensusParams torrc lines. Now directory authority operators can for example put the main ConsensusParams config in one torrc file and then add to it from a different torrc file. Closes ticket 40164.
There's a new alpha release available for download. If you build Tor from source, you can download the source code for Tor 0.4.5.1-alpha from the download page on the website. Packages should be available over the coming weeks, with a new alpha Tor Browser release some time this month, assuming we get #40172 figured out.
Remember, this is an alpha release: you should only run this if you'd like to find and report more bugs than usual. We'll be trying to put out putting out stable backport releases in the next week or so.
Tor 0.4.5.1-alpha is the first alpha release in the 0.4.5.x series. It improves support for IPv6, address discovery and self-testing, code metrics and tracing.
This release also fixes TROVE-2020-005, a security issue that could be used, under certain cases, by an adversary to observe traffic patterns on a limited number of circuits intended for a different relay. To mount this attack, the adversary would need to actively extend circuits to an incorrect address, as well as compromise a relay's legacy RSA-1024 key. We'll be backporting this fix to other release series soon, after it has had some testing.
Here are the changes since 0.4.4.5.
Changes in version 0.4.5.1-alpha - 2020-11-01
Major features (build):
When building Tor, first link all object files into a single static library. This may help with embedding Tor in other programs. Note that most Tor functions do not constitute a part of a stable or supported API: only those functions in tor_api.h should be used if embedding Tor. Closes ticket 40127.
Major features (metrics):
Introduce a new MetricsPort which exposes, through an HTTP interface, a series of metrics that tor collects at runtime. At the moment, the only supported output format is Prometheus data model. Closes ticket 40063. See the manual page for more information and security considerations.
After months of work, we have a new stable release series!
If you build Tor from source, you can download the source
code for 0.4.4.5 on the download page.
Packages should be available within the next several weeks, with a new Tor Browser by some time next week.
Tor 0.4.4.5 is the first stable release in the 0.4.4.x series. This series improves our guard selection algorithms, adds v3 onion balance support, improves the amount of code that can be disabled when running without relay support, and includes numerous small bugfixes and enhancements. It also lays the ground for some IPv6 features that we'll be developing more in the next (0.4.5) series.
Per our support policy, we support each stable release series for nine months after its first stable release, or three months after the first stable release of the next series: whichever is longer. This means that 0.4.4.x will be supported until around June 2021--or later, if 0.4.5.x is later than anticipated.
Note also that support for 0.4.2.x has just ended; support for 0.4.3 will continue until Feb 15, 2021. We still plan to continue supporting 0.3.5.x, our long-term stable series, until Feb 2022.
Below are the changes since 0.4.3.6-rc. For a complete list of changes since 0.4.4.4-rc, see the ChangeLog file.
Changes in version 0.4.4.5 - 2020-09-15
Major features (Proposal 310, performance + security):
Implements Proposal 310, "Bandaid on guard selection". Proposal 310 solves load-balancing issues with older versions of the guard selection algorithm, and improves its security. Under this new algorithm, a newly selected guard never becomes Primary unless all previously sampled guards are unreachable. Implements recommendation from 32088. (Proposal 310 is linked to the CLAPS project researching optimal client location-aware path selections. This project is a collaboration between the UCLouvain Crypto Group, the U.S. Naval Research Laboratory, and Princeton University.)
Major features (fallback directory list):
Replace the 148 fallback directories originally included in Tor 0.4.1.4-rc (of which around 105 are still functional) with a list of 144 fallbacks generated in July 2020. Closes ticket 40061.
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.4-rc from the download page. Packages should be available over the coming weeks, with a new alpha Tor Browser release likely in the coming weeks.
Remember, this is a release candidate, not a a stable release: you should only run this if you'd like to find and report more bugs than usual.
Tor 0.4.4.4-rc is the first release candidate in its series. It fixes several bugs in previous versions, including some that caused annoying behavior for relay and bridge operators.
Changes in version 0.4.4.4-rc - 2020-08-13
Minor features (security):
Channels using obsolete versions of the Tor link protocol are no longer allowed to circumvent address-canonicity checks. (This is only a minor issue, since such channels have no way to set ed25519 keys, and therefore should always be rejected for circuits that specify ed25519 identities.) Closes ticket 40081.
Minor features (defense in depth):
Wipe more data from connection address fields before returning them to the memory heap. Closes ticket 6198.
Starting August 1, every donation we receive during the month of August will count towards the Bug Smash Fund 2020. The Bug Smash Fund allows the Tor Project to find and fix bugs in our software and conduct routine maintenance.
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.3-alpha from the download page on the website. Packages should be available over the coming weeks, with a new alpha Tor Browser release by mid-August.
Remember, this is an alpha release: you should only run this if you'd like to find and report more bugs than usual.
Tor 0.4.4.3-alpha fixes several annoyances in previous versions, including one affecting NSS users, and several affecting the Linux seccomp2 sandbox.
Changes in version 0.4.4.3-alpha - 2020-07-27
Major features (fallback directory list):
Replace the 148 fallback directories originally included in Tor 0.4.1.4-rc (of which around 105 are still functional) with a list of 144 fallbacks generated in July 2020. Closes ticket 40061.
Major bugfixes (NSS):
When running with NSS enabled, make sure that NSS knows to expect nonblocking sockets. Previously, we set our TCP sockets as nonblocking, but did not tell NSS, which in turn could lead to unexpected blocking behavior. Fixes bug 40035; bugfix on 0.3.5.1-alpha.
At the beginning of August 2019, we asked you to help us build our very first Bug Smash Fund. This fund will ensure that the Tor Project has a healthy reserve earmarked for maintenance work and smashing the bugs necessary to keep Tor Browser, the Tor network, and the many tools that rely on Tor strong, safe, and running smoothly. We want to share a final update on the work the 2019 Bug Smash Fund made possible.
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.1-alpha from the download page. Packages should be available over the coming weeks, with a new alpha Tor Browser release by early July.
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 first alpha release in the 0.4.4.x series. It improves our guard selection algorithms, improves the amount of code that can be disabled when running without relay support, and includes numerous small bugfixes and enhancements. It also lays the ground for some IPv6 features that we'll be developing more in the next (0.4.5) series.
Here are the changes since 0.4.3.5.
Changes in version 0.4.4.1-alpha - 2020-06-16
Major features (Proposal 310, performance + security):
Implements Proposal 310, "Bandaid on guard selection". Proposal 310 solves load-balancing issues with older versions of the guard selection algorithm, and improves its security. Under this new algorithm, a newly selected guard never becomes Primary unless all previously sampled guards are unreachable. Implements recommendation from 32088. (Proposal 310 is linked to the CLAPS project researching optimal client location-aware path selections. This project is a collaboration between the UCLouvain Crypto Group, the U.S. Naval Research Laboratory, and Princeton University.)
Major features (IPv6, relay):
Consider IPv6-only EXTEND2 cells valid on relays. Log a protocol warning if the IPv4 or IPv6 address is an internal address, and internal addresses are not allowed. But continue to use the other address, if it is valid. Closes ticket 33817.
If a relay can extend over IPv4 and IPv6, and both addresses are provided, it chooses between them uniformly at random. Closes ticket 33817.
Re-use existing IPv6 connections for circuit extends. Closes ticket 33817.
Relays may extend circuits over IPv6, if the relay has an IPv6 ORPort, and the client supplies the other relay's IPv6 ORPort in the EXTEND2 cell. IPv6 extends will be used by the relay IPv6 ORPort self-tests in 33222. Closes ticket 33817.
