Tor 0.2.7.5 is released and stable

by nickm | November 23, 2015

The Tor 0.2.7 release series is dedicated to the memory of Tor user and privacy advocate Caspar Bowden (1961-2015). Caspar worked tirelessly to advocate human rights regardless of national borders, and oppose the encroachments of mass surveillance. He opposed national exceptionalism, he brought clarity to legal and policy debates, he understood and predicted the impact of mass surveillance on the world, and he laid the groundwork for resisting it. While serving on the Tor Project's board of directors, he brought us his uncompromising focus on technical excellence in the service of humankind. Caspar was an inimitable force for good and a wonderful friend. He was kind, humorous, generous, gallant, and believed we should protect one another without exception. We honor him here for his ideals, his efforts, and his accomplishments. Please honor his memory with works that would make him proud.
Tor 0.2.7.5 is the first stable release in the Tor 0.2.7 series. It makes no changes beyond those in 0.2.7.4-rc; the summary below lists all changes in the 0.2.7 series.
You can download the source from the usual place on the website.
Packages should be up in a few days.
The 0.2.7 series adds a more secure identity key type for relays, improves cryptography performance, resolves several longstanding hidden-service performance issues, improves controller support for hidden services, and includes small bugfixes and performance improvements throughout the program. This release series also includes more tests than before, and significant simplifications to which parts of Tor invoke which others. For a full list of changes, see below.

Changes in version 0.2.7.5 - 2015-11-20

  • New system requirements:
    • Tor no longer includes workarounds to support Libevent versions before 1.3e. Libevent 2.0 or later is recommended. Closes ticket 15248.
    • Tor no longer supports copies of OpenSSL that are missing support for Elliptic Curve Cryptography. (We began using ECC when available in 0.2.4.8-alpha, for more safe and efficient key negotiation.) In particular, support for at least one of P256 or P224 is now required, with manual configuration needed if only P224 is available. Resolves ticket 16140.
    • Tor no longer supports versions of OpenSSL before 1.0. (If you are on an operating system that has not upgraded to OpenSSL 1.0 or later, and you compile Tor from source, you will need to install a more recent OpenSSL to link Tor against.) These versions of OpenSSL are still supported by the OpenSSL, but the numerous cryptographic improvements in later OpenSSL releases makes them a clear choice. Resolves ticket 16034.
  • Major features (controller):
    • Add the ADD_ONION and DEL_ONION commands that allow the creation and management of hidden services via the controller. Closes ticket 6411.
    • New "GETINFO onions/current" and "GETINFO onions/detached" commands to get information about hidden services created via the controller. Part of ticket 6411.
    • New HSFETCH command to launch a request for a hidden service descriptor. Closes ticket 14847.
    • New HSPOST command to upload a hidden service descriptor. Closes ticket 3523. Patch by "DonnchaC".

 

  • Major features (Ed25519 identity keys, Proposal 220):
    • Add support for offline encrypted Ed25519 master keys. To use this feature on your tor relay, run "tor --keygen" to make a new master key (or to make a new signing key if you already have a master key). Closes ticket 13642.
    • All relays now maintain a stronger identity key, using the Ed25519 elliptic curve signature format. This master key is designed so that it can be kept offline. Relays also generate an online signing key, and a set of other Ed25519 keys and certificates. These are all automatically regenerated and rotated as needed. Implements part of ticket 12498.
    • Directory authorities now vote on Ed25519 identity keys along with RSA1024 keys. Implements part of ticket 12498.
    • Directory authorities track which Ed25519 identity keys have been used with which RSA1024 identity keys, and do not allow them to vary freely. Implements part of ticket 12498.
    • Microdescriptors now include Ed25519 identity keys. Implements part of ticket 12498.
    • Add a --newpass option to allow changing or removing the passphrase of an encrypted key with tor --keygen. Implements part of ticket 16769.
    • Add a new OfflineMasterKey option to tell Tor never to try loading or generating a secret Ed25519 identity key. You can use this in combination with tor --keygen to manage offline and/or encrypted Ed25519 keys. Implements ticket 16944.
    • On receiving a HUP signal, check to see whether the Ed25519 signing key has changed, and reload it if so. Closes ticket 16790.
    • Significant usability improvements for Ed25519 key management. Log messages are better, and the code can recover from far more failure conditions. Thanks to "s7r" for reporting and diagnosing so many of these!
  • Major features (ECC performance):
    • Improve the runtime speed of Ed25519 signature verification by using Ed25519-donna's batch verification support. Implements ticket 16533.
    • Improve the speed of Ed25519 operations and Curve25519 keypair generation when built targeting 32 bit x86 platforms with SSE2 available. Implements ticket 16535.
    • Improve the runtime speed of Ed25519 operations by using the public-domain Ed25519-donna by Andrew M. ("floodyberry"). Implements ticket 16467.
    • Improve the runtime speed of the ntor handshake by using an optimized curve25519 basepoint scalarmult implementation from the public-domain Ed25519-donna by Andrew M. ("floodyberry"), based on ideas by Adam Langley. Implements ticket 9663.
  • Major features (Hidden services):
    • Hidden services, if using the EntryNodes option, are required to use more than one EntryNode, in order to avoid a guard discovery attack. (This would only affect people who had configured hidden services and manually specified the EntryNodes option with a single entry-node. The impact was that it would be easy to remotely identify the guard node used by such a hidden service. See ticket for more information.) Fixes ticket 14917.
    • Add the torrc option HiddenServiceNumIntroductionPoints, to specify a fixed number of introduction points. Its maximum value is 10 and default is 3. Using this option can increase a hidden service's reliability under load, at the cost of making it more visible that the hidden service is facing extra load. Closes ticket 4862.
    • Remove the adaptive algorithm for choosing the number of introduction points, which used to change the number of introduction points (poorly) depending on the number of connections the HS sees. Closes ticket 4862.
  • Major features (onion key cross-certification):
    • Relay descriptors now include signatures of their own identity keys, made using the TAP and ntor onion keys. These signatures allow relays to prove ownership of their own onion keys. Because of this change, microdescriptors will no longer need to include RSA identity keys. Implements proposal 228; closes ticket 12499.
  • Major bugfixes (client-side privacy, also in 0.2.6.9):
    • Properly separate out each SOCKSPort when applying stream isolation. The error occurred because each port's session group was being overwritten by a default value when the listener connection was initialized. Fixes bug 16247; bugfix on 0.2.6.3-alpha. Patch by "jojelino".
  • Major bugfixes (hidden service clients, stability, also in 0.2.6.10):
    • Stop refusing to store updated hidden service descriptors on a client. This reverts commit 9407040c59218 (which indeed fixed bug 14219, but introduced a major hidden service reachability regression detailed in bug 16381). This is a temporary fix since we can live with the minor issue in bug 14219 (it just results in some load on the network) but the regression of 16381 is too much of a setback. First-round fix for bug 16381; bugfix on 0.2.6.3-alpha.
  • Major bugfixes (hidden services):
    • Revert commit that made directory authorities assign the HSDir flag to relay without a DirPort; this was bad because such relays can't handle BEGIN_DIR cells. Fixes bug 15850; bugfix on tor-0.2.6.3-alpha.
    • When cannibalizing a circuit for an introduction point, always extend to the chosen exit node (creating a 4 hop circuit). Previously Tor would use the current circuit exit node, which changed the original choice of introduction point, and could cause the hidden service to skip excluded introduction points or reconnect to a skipped introduction point. Fixes bug 16260; bugfix on 0.1.0.1-rc.
  • Major bugfixes (memory leaks):
    • Fix a memory leak in ed25519 batch signature checking. Fixes bug 17398; bugfix on 0.2.6.1-alpha.
  • Major bugfixes (open file limit):
    • The open file limit wasn't checked before calling tor_accept_socket_nonblocking(), which would make Tor exceed the limit. Now, before opening a new socket, Tor validates the open file limit just before, and if the max has been reached, return an error. Fixes bug 16288; bugfix on 0.1.1.1-alpha.
  • Major bugfixes (security, correctness):
    • Fix an error that could cause us to read 4 bytes before the beginning of an openssl string. This bug could be used to cause Tor to crash on systems with unusual malloc implementations, or systems with unusual hardening installed. Fixes bug 17404; bugfix on 0.2.3.6-alpha.
  • Major bugfixes (stability, also in 0.2.6.10):
    • Stop crashing with an assertion failure when parsing certain kinds of malformed or truncated microdescriptors. Fixes bug 16400; bugfix on 0.2.6.1-alpha. Found by "torkeln"; fix based on a patch by "cypherpunks_backup".
    • Stop random client-side assertion failures that could occur when connecting to a busy hidden service, or connecting to a hidden service while a NEWNYM is in progress. Fixes bug 16013; bugfix on 0.1.0.1-rc.
  • Minor features (client, SOCKS):
    • Add GroupWritable and WorldWritable options to unix-socket based SocksPort and ControlPort options. These options apply to a single socket, and override {Control,Socks}SocketsGroupWritable. Closes ticket 15220.
    • Relax the validation done to hostnames in SOCKS5 requests, and allow a single trailing '.' to cope with clients that pass FQDNs using that syntax to explicitly indicate that the domain name is fully-qualified. Fixes bug 16674; bugfix on 0.2.6.2-alpha.
    • Relax the validation of hostnames in SOCKS5 requests, allowing the character '_' to appear, in order to cope with domains observed in the wild that are serving non-RFC compliant records. Resolves ticket 16430.
  • Minor features (client-side privacy):
    • New KeepAliveIsolateSOCKSAuth option to indefinitely extend circuit lifespan when IsolateSOCKSAuth and streams with SOCKS authentication are attached to the circuit. This allows applications like TorBrowser to manage circuit lifetime on their own. Implements feature 15482.
    • When logging malformed hostnames from SOCKS5 requests, respect SafeLogging configuration. Fixes bug 16891; bugfix on 0.1.1.16-rc.
  • Minor features (clock-jump tolerance):
    • Recover better when our clock jumps back many hours, like might happen for Tails or Whonix users who start with a very wrong hardware clock, use Tor to discover a more accurate time, and then fix their clock. Resolves part of ticket 8766.
  • Minor features (command-line interface):
    • Make --hash-password imply --hush to prevent unnecessary noise. Closes ticket 15542. Patch from "cypherpunks".
    • Print a warning whenever we find a relative file path being used as torrc option. Resolves issue 14018.
  • Minor features (compilation):
    • Give a warning as early as possible when trying to build with an unsupported OpenSSL version. Closes ticket 16901.
    • Use C99 variadic macros when the compiler is not GCC. This avoids failing compilations on MSVC, and fixes a log-file-based race condition in our old workarounds. Original patch from Gisle Vanem.
  • Minor features (control protocol):
    • Support network-liveness GETINFO key and NETWORK_LIVENESS event in the control protocol. Resolves ticket 15358.
  • Minor features (controller):
    • Add DirAuthority lines for default directory authorities to the output of the "GETINFO config/defaults" command if not already present. Implements ticket 14840.
    • Controllers can now use "GETINFO hs/client/desc/id/..." to retrieve items from the client's hidden service descriptor cache. Closes ticket 14845.
    • Implement a new controller command "GETINFO status/fresh-relay- descs" to fetch a descriptor/extrainfo pair that was generated on demand just for the controller's use. Implements ticket 14784.
  • Minor features (directory authorities):
    • Directory authorities no longer vote against the "Fast", "Stable", and "HSDir" flags just because they were going to vote against "Running": if the consensus turns out to be that the router was running, then the authority's vote should count. Patch from Peter Retzlaff; closes issue 8712.
  • Minor features (directory authorities, security, also in 0.2.6.9):
    • The HSDir flag given by authorities now requires the Stable flag. For the current network, this results in going from 2887 to 2806 HSDirs. Also, it makes it harder for an attacker to launch a sybil attack by raising the effort for a relay to become Stable to require at the very least 7 days, while maintaining the 96 hours uptime requirement for HSDir. Implements ticket 8243.
  • Minor features (DoS-resistance):
    • Make it harder for attackers to overload hidden services with introductions, by blocking multiple introduction requests on the same circuit. Resolves ticket 15515.
  • Minor features (geoip):
    • Update geoip and geoip6 to the October 9 2015 Maxmind GeoLite2 Country database.
  • Minor features (hidden services):
    • Add the new options "HiddenServiceMaxStreams" and "HiddenServiceMaxStreamsCloseCircuit" to allow hidden services to limit the maximum number of simultaneous streams per circuit, and optionally tear down the circuit when the limit is exceeded. Part of ticket 16052.
    • Client now uses an introduction point failure cache to know when to fetch or keep a descriptor in their cache. Previously, failures were recorded implicitly, but not explicitly remembered. Closes ticket 16389.
    • Relays need to have the Fast flag to get the HSDir flag. As this is being written, we'll go from 2745 HSDirs down to 2342, a ~14% drop. This change should make some attacks against the hidden service directory system harder. Fixes ticket 15963.
    • Turn on hidden service statistics collection by setting the torrc option HiddenServiceStatistics to "1" by default. (This keeps track only of the fraction of traffic used by hidden services, and the total number of hidden services in existence.) Closes ticket 15254.
    • To avoid leaking HS popularity, don't cycle the introduction point when we've handled a fixed number of INTRODUCE2 cells but instead cycle it when a random number of introductions is reached, thus making it more difficult for an attacker to find out the amount of clients that have used the introduction point for a specific HS. Closes ticket 15745.
  • Minor features (logging):
    • Include the Tor version in all LD_BUG log messages, since people tend to cut and paste those into the bugtracker. Implements ticket 15026.
  • Minor features (pluggable transports):
    • When launching managed pluggable transports on Linux systems, attempt to have the kernel deliver a SIGTERM on tor exit if the pluggable transport process is still running. Resolves ticket 15471.
    • When launching managed pluggable transports, setup a valid open stdin in the child process that can be used to detect if tor has terminated. The "TOR_PT_EXIT_ON_STDIN_CLOSE" environment variable can be used by implementations to detect this new behavior. Resolves ticket 15435.
  • Minor bugfixes (torrc exit policies):
    • In each instance above, usage advice is provided to avoid the message. Resolves ticket 16069. Patch by "teor". Fixes part of bug 16069; bugfix on 0.2.4.7-alpha.
    • In torrc, "accept6 *" and "reject6 *" ExitPolicy lines now only produce IPv6 wildcard addresses. Previously they would produce both IPv4 and IPv6 wildcard addresses. Patch by "teor". Fixes part of bug 16069; bugfix on 0.2.4.7-alpha.
    • When parsing torrc ExitPolicies, we now issue an info-level message when expanding an "accept/reject *" line to include both IPv4 and IPv6 wildcard addresses. Related to ticket 16069.
    • When parsing torrc ExitPolicies, we now warn for a number of cases where the user's intent is likely to differ from Tor's actual behavior. These include: using an IPv4 address with an accept6 or reject6 line; using "private" on an accept6 or reject6 line; and including any ExitPolicy lines after accept *:* or reject *:*. Related to ticket 16069.
  • Minor bugfixes (command-line interface):
    • When "--quiet" is provided along with "--validate-config", do not write anything to stdout on success. Fixes bug 14994; bugfix on 0.2.3.3-alpha.
    • When complaining about bad arguments to "--dump-config", use stderr, not stdout.
    • Print usage information for --dump-config when it is used without an argument. Also, fix the error message to use different wording and add newline at the end. Fixes bug 15541; bugfix on 0.2.5.1-alpha.
  • Minor bugfixes (compilation):
    • Fix compilation of sandbox.c with musl-libc. Fixes bug 17347; bugfix on 0.2.5.1-alpha. Patch from 'jamestk'.
    • Repair compilation with the most recent (unreleased, alpha) vesions of OpenSSL 1.1. Fixes part of ticket 17237.
  • Minor bugfixes (compilation, also in 0.2.6.9):
    • Build with --enable-systemd correctly when libsystemd is installed, but systemd is not. Fixes bug 16164; bugfix on 0.2.6.3-alpha. Patch from Peter Palfrader.
  • Minor bugfixes (configuration, unit tests):
    • Only add the default fallback directories when the DirAuthorities, AlternateDirAuthority, and FallbackDir directory config options are set to their defaults. The default fallback directory list is currently empty, this fix will only change tor's behavior when it has default fallback directories. Includes unit tests for consider_adding_dir_servers(). Fixes bug 15642; bugfix on 90f6071d8dc0 in 0.2.4.7-alpha. Patch by "teor".
  • Minor bugfixes (controller):
    • Add the descriptor ID in each HS_DESC control event. It was missing, but specified in control-spec.txt. Fixes bug 15881; bugfix on 0.2.5.2-alpha.
  • Minor bugfixes (correctness):
    • For correctness, avoid modifying a constant string in handle_control_postdescriptor. Fixes bug 15546; bugfix on 0.1.1.16-rc.
    • Remove side-effects from tor_assert() calls. This was harmless, because we never disable assertions, but it is bad style and unnecessary. Fixes bug 15211; bugfix on 0.2.5.5, 0.2.2.36, and 0.2.0.10.
    • When calling channel_free_list(), avoid calling smartlist_remove() while inside a FOREACH loop. This partially reverts commit 17356fe7fd96af where the correct SMARTLIST_DEL_CURRENT was incorrectly removed. Fixes bug 16924; bugfix on 0.2.4.4-alpha.
  • Minor bugfixes (crypto error-handling, also in 0.2.6.10):
    • Check for failures from crypto_early_init, and refuse to continue. A previous typo meant that we could keep going with an uninitialized crypto library, and would have OpenSSL initialize its own PRNG. Fixes bug 16360; bugfix on 0.2.5.2-alpha, introduced when implementing ticket 4900. Patch by "teor".
  • Minor bugfixes (hidden service):
    • Fix an out-of-bounds read when parsing invalid INTRODUCE2 cells on a client authorized hidden service. Fixes bug 15823; bugfix on 0.2.1.6-alpha.
    • Remove an extraneous newline character from the end of hidden service descriptors. Fixes bug 15296; bugfix on 0.2.0.10-alpha.
  • Minor bugfixes (Linux seccomp2 sandbox):
    • Use the sandbox in tor_open_cloexec whether or not O_CLOEXEC is defined. Patch by "teor". Fixes bug 16515; bugfix on 0.2.3.1-alpha.
    • Allow bridge authorities to run correctly under the seccomp2 sandbox. Fixes bug 16964; bugfix on 0.2.5.1-alpha.
    • Add the "hidserv-stats" filename to our sandbox filter for the HiddenServiceStatistics option to work properly. Fixes bug 17354; bugfix on tor-0.2.6.2-alpha. Patch from David Goulet.
  • Minor bugfixes (Linux seccomp2 sandbox, also in 0.2.6.10):
    • Allow pipe() and pipe2() syscalls in the seccomp2 sandbox: we need these when eventfd2() support is missing. Fixes bug 16363; bugfix on 0.2.6.3-alpha. Patch from "teor".
  • Minor bugfixes (Linux seccomp2 sandbox, also in 0.2.6.9):
    • Allow systemd connections to work with the Linux seccomp2 sandbox code. Fixes bug 16212; bugfix on 0.2.6.2-alpha. Patch by Peter Palfrader.
    • Fix sandboxing to work when running as a relay, by allowing the renaming of secret_id_key, and allowing the eventfd2 and futex syscalls. Fixes bug 16244; bugfix on 0.2.6.1-alpha. Patch by Peter Palfrader.
  • Minor bugfixes (logging):
    • When building Tor under Clang, do not include an extra set of parentheses in log messages that include function names. Fixes bug 15269; bugfix on every released version of Tor when compiled with recent enough Clang.
  • Minor bugfixes (network):
    • When attempting to use fallback technique for network interface lookup, disregard loopback and multicast addresses since they are unsuitable for public communications.
  • Minor bugfixes (open file limit):
    • Fix set_max_file_descriptors() to set by default the max open file limit to the current limit when setrlimit() fails. Fixes bug 16274; bugfix on tor- 0.2.0.10-alpha. Patch by dgoulet.
  • Minor bugfixes (portability):
    • Check correctly for Windows socket errors in the workqueue backend. Fixes bug 16741; bugfix on 0.2.6.3-alpha.
    • Try harder to normalize the exit status of the Tor process to the standard-provided range. Fixes bug 16975; bugfix on every version of Tor ever.
    • Use libexecinfo on FreeBSD to enable backtrace support. Fixes part of bug 17151; bugfix on 0.2.5.2-alpha. Patch from Marcin Cieślak.
  • Minor bugfixes (relay):
    • Ensure that worker threads actually exit when a fatal error or shutdown is indicated. This fix doesn't currently affect the behavior of Tor, because Tor workers never indicates fatal error or shutdown except in the unit tests. Fixes bug 16868; bugfix on 0.2.6.3-alpha.
    • Fix a rarely-encountered memory leak when failing to initialize the thread pool. Fixes bug 16631; bugfix on 0.2.6.3-alpha. Patch from "cypherpunks".
    • Unblock threads before releasing the work queue mutex to ensure predictable scheduling behavior. Fixes bug 16644; bugfix on 0.2.6.3-alpha.
  • Minor bugfixes (security, exit policies):
    • ExitPolicyRejectPrivate now also rejects the relay's published IPv6 address (if any), and any publicly routable IPv4 or IPv6 addresses on any local interfaces. ticket 17027. Patch by "teor". Fixes bug 17027; bugfix on 0.2.0.11-alpha.
  • Minor bugfixes (statistics):
    • Disregard the ConnDirectionStatistics torrc options when Tor is not a relay since in that mode of operation no sensible data is being collected and because Tor might run into measurement hiccups when running as a client for some time, then becoming a relay. Fixes bug 15604; bugfix on 0.2.2.35.
  • Minor bugfixes (systemd):
    • Tor's systemd unit file no longer contains extraneous spaces. These spaces would sometimes confuse tools like deb-systemd- helper. Fixes bug 16162; bugfix on 0.2.5.5-alpha.
  • Minor bugfixes (test networks):
    • When self-testing reachability, use ExtendAllowPrivateAddresses to determine if local/private addresses imply reachability. The previous fix used TestingTorNetwork, which implies ExtendAllowPrivateAddresses, but this excluded rare configurations where ExtendAllowPrivateAddresses is set but TestingTorNetwork is not. Fixes bug 15771; bugfix on 0.2.6.1-alpha. Patch by "teor", issue discovered by CJ Ess.
  • Minor bugfixes (tests, also in 0.2.6.9):
    • Fix a crash in the unit tests when built with MSVC2013. Fixes bug 16030; bugfix on 0.2.6.2-alpha. Patch from "NewEraCracker".
  • Code simplification and refactoring:
    • Change the function that's called when we need to retry all downloads so that it only reschedules the downloads to happen immediately, rather than launching them all at once itself. This further simplifies Tor's callgraph.
    • Define WINVER and _WIN32_WINNT centrally, in orconfig.h, in order to ensure they remain consistent and visible everywhere.
    • Move some format-parsing functions out of crypto.c and crypto_curve25519.c into crypto_format.c and/or util_format.c.
    • Move the client-only parts of init_keys() into a separate function. Closes ticket 16763.
    • Move the hacky fallback code out of get_interface_address6() into separate function and get it covered with unit-tests. Resolves ticket 14710.
    • Refactor hidden service client-side cache lookup to intelligently report its various failure cases, and disentangle failure cases involving a lack of introduction points. Closes ticket 14391.
    • Remove some vestigial workarounds for the MSVC6 compiler. We haven't supported that in ages.
    • Remove the unused "nulterminate" argument from buf_pullup().
    • Simplify the microdesc_free() implementation so that it no longer appears (to code analysis tools) to potentially invoke a huge suite of other microdesc functions.
    • Simply the control graph further by deferring the inner body of directory_all_unreachable() into a callback. Closes ticket 16762.
    • The link authentication code has been refactored for better testability and reliability. It now uses code generated with the "trunnel" binary encoding generator, to reduce the risk of bugs due to programmer error. Done as part of ticket 12498.
    • Treat the loss of an owning controller as equivalent to a SIGTERM signal. This removes a tiny amount of duplicated code, and simplifies our callgraph. Closes ticket 16788.
    • Use our own Base64 encoder instead of OpenSSL's, to allow more control over the output. Part of ticket 15652.
    • When generating an event to send to the controller, we no longer put the event over the network immediately. Instead, we queue these events, and use a Libevent callback to deliver them. This change simplifies Tor's callgraph by reducing the number of functions from which all other Tor functions are reachable. Closes ticket 16695.
    • Wrap Windows-only C files inside '#ifdef _WIN32' so that tools that try to scan or compile every file on Unix won't decide that they are broken.
  • Documentation:
    • Fix capitalization of SOCKS in sample torrc. Closes ticket 15609.
    • Improve the descriptions of statistics-related torrc options in the manpage to describe rationale and possible uses cases. Fixes issue 15550.
    • Improve the layout and formatting of ./configure --help messages. Closes ticket 15024. Patch from "cypherpunks".
    • Include a specific and (hopefully) accurate documentation of the torrc file's meta-format in doc/torrc_format.txt. This is mainly of interest to people writing programs to parse or generate torrc files. This document is not a commitment to long-term compatibility; some aspects of the current format are a bit ridiculous. Closes ticket 2325.
    • Include the TUNING document in our source tarball. It is referred to in the ChangeLog and an error message. Fixes bug 16929; bugfix on 0.2.6.1-alpha.
    • Note that HiddenServicePorts can take a unix domain socket. Closes ticket 17364.
    • Recommend a 40 GB example AccountingMax in torrc.sample rather than a 4 GB max. Closes ticket 16742.
    • Standardize on the term "server descriptor" in the manual page. Previously, we had used "router descriptor", "server descriptor", and "relay descriptor" interchangeably. Part of ticket 14987.
    • Advise users on how to configure separate IPv4 and IPv6 exit policies in the manpage and sample torrcs. Related to ticket 16069.
    • Fix an error in the manual page and comments for TestingDirAuthVoteHSDir[IsStrict], which suggested that a HSDir required "ORPort connectivity". While this is true, it is in no way unique to the HSDir flag. Of all the flags, only HSDirs need a DirPort configured in order for the authorities to assign that particular flag. Patch by "teor". Fixed as part of 14882; bugfix on 0.2.6.3-alpha.
    • Fix the usage message of tor-resolve(1) so that it no longer lists the removed -F option. Fixes bug 16913; bugfix on 0.2.2.28-beta.
  • Removed code:
    • Remove `USE_OPENSSL_BASE64` and the corresponding fallback code and always use the internal Base64 decoder. The internal decoder has been part of tor since tor-0.2.0.10-alpha, and no one should be using the OpenSSL one. Part of ticket 15652.
    • Remove the 'tor_strclear()' function; use memwipe() instead. Closes ticket 14922.
    • Remove the code that would try to aggressively flush controller connections while writing to them. This code was introduced in 0.1.2.7-alpha, in order to keep output buffers from exceeding their limits. But there is no longer a maximum output buffer size, and flushing data in this way caused some undesirable recursions in our call graph. Closes ticket 16480.
    • The internal pure-C tor-fw-helper tool is now removed from the Tor distribution, in favor of the pure-Go clone available from https://gitweb.torproject.org/tor-fw-helper.git/ . The libraries used by the C tor-fw-helper are not, in our opinion, very confidence- inspiring in their secure-programming techniques. Closes ticket 13338.
  • Removed features:
    • Remove the (seldom-used) DynamicDHGroups feature. For anti- fingerprinting we now recommend pluggable transports; for forward- secrecy in TLS, we now use the P-256 group. Closes ticket 13736.
    • Remove the HidServDirectoryV2 option. Now all relays offer to store hidden service descriptors. Related to 16543.
    • Remove the VoteOnHidServDirectoriesV2 option, since all authorities have long set it to 1. Closes ticket 16543.
    • Remove the undocumented "--digests" command-line option. It complicated our build process, caused subtle build issues on multiple platforms, and is now redundant since we started including git version identifiers. Closes ticket 14742.
    • Tor no longer contains checks for ancient directory cache versions that didn't know about microdescriptors.
    • Tor no longer contains workarounds for stat files generated by super-old versions of Tor that didn't choose guards sensibly.
  • Testing:
    • The test-network.sh script now supports performance testing. Requires corresponding chutney performance testing changes. Patch by "teor". Closes ticket 14175.
    • Add a new set of callgraph analysis scripts that use clang to produce a list of which Tor functions are reachable from which other Tor functions. We're planning to use these to help simplify our code structure by identifying illogical dependencies.
    • Add new 'test-full' and 'test-full-online' targets to run all tests, including integration tests with stem and chutney.
    • Autodetect CHUTNEY_PATH if the chutney and Tor sources are side- by-side in the same parent directory. Closes ticket 16903. Patch by "teor".
    • Document use of coverity, clang static analyzer, and clang dynamic undefined behavior and address sanitizers in doc/HACKING. Include detailed usage instructions in the blacklist. Patch by "teor". Closes ticket 15817.
    • Make "bridges+hs" the default test network. This tests almost all tor functionality during make test-network, while allowing tests to succeed on non-IPv6 systems. Requires chutney commit 396da92 in test-network-bridges-hs. Closes tickets 16945 (tor) and 16946 (chutney). Patches by "teor".
    • Make the test-workqueue test work on Windows by initializing the network before we begin.
    • New make target (make test-network-all) to run multiple applicable chutney test cases. Patch from Teor; closes 16953.
    • Now that OpenSSL has its own scrypt implementation, add an unit test that checks for interoperability between libscrypt_scrypt() and OpenSSL's EVP_PBE_scrypt() so that we could not use libscrypt and rely on EVP_PBE_scrypt() whenever possible. Resolves ticket 16189.
    • The link authentication protocol code now has extensive tests.
    • The relay descriptor signature testing code now has extensive tests.
    • The test_workqueue program now runs faster, and is enabled by default as a part of "make check".
    • Unit test dns_resolve(), dns_clip_ttl() and dns_get_expiry_ttl() functions in dns.c. Implements a portion of ticket 16831.
    • Use environment variables rather than autoconf substitutions to send variables from the build system to the test scripts. This change should be easier to maintain, and cause 'make distcheck' to work better than before. Fixes bug 17148.
    • When building Tor with testing coverage enabled, run Chutney tests (if any) using the 'tor-cov' coverage binary.
    • When running test-network or test-stem, check for the absence of stem/chutney before doing any build operations.
    • Add a test to verify that the compiler does not eliminate our memwipe() implementation. Closes ticket 15377.
    • Add make rule `check-changes` to verify the format of changes files. Closes ticket 15180.
    • Add unit tests for control_event_is_interesting(). Add a compile- time check that the number of events doesn't exceed the capacity of control_event_t.event_mask. Closes ticket 15431, checks for bugs similar to 13085. Patch by "teor".
    • Command-line argument tests moved to Stem. Resolves ticket 14806.
    • Integrate the ntor, backtrace, and zero-length keys tests into the automake test suite. Closes ticket 15344.
    • Remove assertions during builds to determine Tor's test coverage. We don't want to trigger these even in assertions, so including them artificially makes our branch coverage look worse than it is. This patch provides the new test-stem-full and coverage-html-full configure options. Implements ticket 15400.
    • New TestingDirAuthVote{Exit,Guard,HSDir}IsStrict flags to explicitly manage consensus flags in testing networks. Patch by "robgjansen", modified by "teor". Implements part of ticket 14882.
    • Check for matching value in server response in ntor_ref.py. Fixes bug 15591; bugfix on 0.2.4.8-alpha. Reported and fixed by "joelanders".
    • Set the severity correctly when testing get_interface_addresses_ifaddrs() and get_interface_addresses_win32(), so that the tests fail gracefully instead of triggering an assertion. Fixes bug 15759; bugfix on 0.2.6.3-alpha. Reported by Nicolas Derive.

Comments

Please note that the comment area below has been archived.

November 23, 2015

Permalink

Namaste,

We Love you Caspar! Rest in Peace.

Thank you for all you did while inhabiting a vessel on Earth in contributing to make it a better place.

We will carry your legacy.

Namste,
imu.

November 23, 2015

Permalink

There should be a advice how to keep Relays Fingerprints. A to-do List to update/upgrade. btw when should longstanding relays change to new version? but more important: how to do it the best way (lin, deb)

November 24, 2015

Permalink

Seems that all exit-relays has been for a while, located in France. Even after renewing circuits for many times, the exit-relay still remains there. Randomization of the last step might have been somewhat compromized or is it cloud-based there? The pattern doesn't match with all one have been learning about Tor through the years.

I ran myself a couple of them in my country for sometimes ago. After a while and some hardware upgrading both here and there, I intended to reoperate a single exit-relay and a single relay. That has now been much more difficult than what I expected it would do.

November 24, 2015

Permalink

Dedicating this release to Casper Bowden is really an excellent choice.

People who are not familiar with his work might be interested in this talk at CCCamp 2011 (yup, two years before the revelations by Edward Snowden) and you might notice how excellent his analysis of already publicly available sources has been.

http://ftp.ccc.de:/events/camp2011/video/cccamp11-4589-a_brief_history_…

or (higher qualitiy)

http://ftp.ccc.de:/events/camp2011/video/cccamp11-4589-a_brief_history_…

November 24, 2015

Permalink

Encryption/OS/software backdoors will be mandated in the UK by the "Snoopers charter". How will Tor users in the UK be able to still obtain/use Tor? What is the plan?

Both US and UK politicians are very actively exploiting the Friday 13 Paris attacks to claim that developers are "aiding IS", and this is endangering Tor project. Here's the latest salvo in the Cryptowars:

http://www.telegraph.co.uk/technology/12008689/Why-is-Silicon-Valley-he…
Why is Silicon Valley helping the tech-savvy jihadists?
Clare Foges
21 Nov 2015

> Fiendishly-complex online encryption is providing the safe space for terrorists to plan bloodshed on an industrial scale.
...

> If this is a war we are engaged in, the frontline is online – and the enemy is being aided by Western tech companies. Terrorists want ever-safer spaces to operate in, and the tech giants say “Sure! Here’s an end-to-end encrypted product that is impossible to crack. It’s a lock without a key. Even we don’t have a key.”
>
> It goes back to Edward Snowden, the weaselly inadequate whose grasp for posterity has proved a boon for Isil. They should be gratefully chanting his name in Raqqa, for it was Snowden’s revelations about government surveillance methods that triggered this extraordinary race towards deeper encryption.
...
> In the wake of those tip-offs, tech companies faced a massive PR headache on privacy. And so Google, Apple, Facebook and the rest have been falling over themselves to offer products that no government can break into. Apple declare that they “refuse to add a backdoor into any of our products”.
...
> GCHQ invented encryption.

I urge Tor Project leaders to prepare for direct attacks on Tor making similar wild allegations and citing Roger's own "no backdoors" statement.

It is worrisome that arma and ailanthus etc. have fallen silent immediately after exposing the FBI/CMU misconduct. Is the Project already being threatened by the US government? Why have so many blog comments been removed?

I hope you are all just very busy, but in the current political atmosphere, lengthy silences are troubling.

So the advice - do not use 'ready to use products'! Compile your software statically. Encryption is not so difficult to try. - you will get better understanding. Then nobody can 'mandate' _you_ to follow anything.

Static compiling has nothing to do with this. Static compilation is building an executable which doesn't link against shared libraries. It does not make your binary more secure. Often it makes it less secure, because you have to recompile the whole thing any time a single built-in library it uses has a vulnerability (whereas dynamically compiled binaries can just be secured by updating the afflicted library which it links against).

No way - static linking uses only functionality you needs. Dynamic - brings mass unneeded potentially dangerous functions in insane deep link of such modules. Someone can use these functions against you. Does a designer look through all functions which dynamic/shared libraries compose from - no. Is it possible to construct dinamic/shared library aimed on bringing security holes into your design - yes. So using shared/dinamic libraries often makes your product less secure. Btw look at any forums and be surprised at problems whith 'dll hell'. Anyway try to compile statically and be amused at the small size and high speed of your programme! Logically it's enough to have most functions defined as 'inline static' and let the compiler optimise the programme.

While this static vs dynamic linking discussion is very interesting, I think it's a little outside the scope of OP's point, and the grand scheme of things.

While we are able to compile Tor ourselves -- even deterministically(!) -- remember that the 15-or-so million lines of code comprising the Linux kernel are the ones that are running in ring zero and can really do whatever they want, deterministic builds or not. What about the bootloader running in real mode? UEFI's System Management Mode running on the motherboard's firmware? CPUs with AES-NI extensions for hardware-accelerated encryption? IPMI, Intel AMT? Random peripherals with DMA?

Much as I hate to say it, we are screwed even considering just accidental vulnerabilities, not to mention backdoors. There are too many places for vulnerabilities to creep in. Even if half of the aforementioned technologies were open-source, the needle is still too small, and the haystack is still too big in my opinion.

Anyway, back to the topic at hand: what do backdoor programs like Snooper's Charter mean for Tor? Given everything I just said, I think Tor is ahead of the game. Tor was, as far as I know, one of the first to get deterministic builds. This of course relies on users and package maintainers actually doing deterministic builds, and reading the source code. Since Tor has already been the subject of much academic research, I don't expect that will be a problem.

Secondly, the Tor developers have always been open about the possibility of being approached to add backdoors, so the slightest abnormality tends to get users paranoid. I trust the Tor developers pretty well, but you never know what someone will do when cornered. The TrueCrypt developers had the luxury of being mostly anonymous and independent, but could the Tor Project as an established non-profit company afford to do what TrueCrypt did?

Thirdly, the development and distribution process feels pretty secure. Tor runs as an unprivileged process, can be installed without root, run in a chroot, etc., and binaries, tarballs, and Git commits are all accompanied by a PGP signature with a reasonably credible key. Compare to, for example off the top of my head, the do-everything behemoth that is Systemd, which necessarily runs with elevated privileges, PID 1, installs deeply into the system, and could totally undermine the Tor process if it wanted to. It's hosted on Github with not a signature to be found.

So all in all, I think Tor is ahead of its competitors in a lot of ways when it comes to backdoors, vulnerabilities, auditing, and the like, but we can only hope it's far enough ahead of its adversaries.

November 24, 2015

Permalink

Thanks, Tor people, for all your hard work. I don't really understand the post but I can see it shows you are working very hard to improve Tor and to keep it secure.

November 24, 2015

Permalink

Browser fingerprinting beats Tor any day. Yes, it does. Big corporations use it against Tor, such as Banks and various others.

Do you have a name or a link or anything to back that statement up at all? I don't doubt fingerprinting is a real and serious problem, but without any information to go on we can't do much more than speculate.

Passive browser fingerprinting is very limited in what it can do. The only actual risk of fingerprinting posed by corporations and banks would be active fingerprinting, e.g. javascript-based math library fingerprinting, performance fingerprinting, various forms of GPU fingerprinting, etc. All of those may work in stealth, but there is no way they could do it to deanonymize large numbers of people without people immediately taking notice.

If you use Tor Browser, passive browser fingerprinting is effectively useless. If you use your own browser with a bunch of plugins, then perhaps you'd be right, and fingerprinting would beat the Tor. For example, Chrome orders HTTP headers differently which would show up in highly verbose access logs and packet captures, all browsers have different asynchronous behaviors which shows up in access log timestamps, etc.

The most potent form of fingerprinting against Tor Browser currently which does not require javascript is screen size fingerprinting, which is of limited effectiveness, and is an active attack (it requires using CSS media elements).

Either way, please don't spread FUD unless you have information to back them up. tl;dr passive fingerprinting is not a real issue for Tor Browser users, and active fingerprinting would be noticed very quickly if it were used on any sizable number of users.

November 24, 2015

Permalink

I think this is relevant to the comment spam attacks on the blog and the intense political attacks on Tor and encryption.

An excellent two part article from The Register stresses that these days it is all of them (the governments and mega-corporations) against all of us (the People), and that means Tor must try to prepare state-sponsored and corporate-sponsored targeted attacks. I urge Tor leaders to try to recruit top level malware researchers (not the DARPA/NSA ones, of course!) to help you guard torproject.org network. You can't offer money (not much, anyway) but you can offer the chance, even the likelihood, of capturing the world's most advanced malware.

http://www.theregister.co.uk/2015/11/23/network_defense_attack_learn_ba…
Want to defend your network? Profile the person attacking it
PART 1 – Can't keep them out, so catch them while they’re in
23 Nov 2015
Trevor Pott

http://www.theregister.co.uk/2015/11/24/north_korea_could_have_pwned_so…
North Korea is capable of pwning Sony. Whether it did is another matter
PART 2 – It looked like a training exercise anyway
24 Nov 2015
Trevor Pott

>You can't offer money (not much, anyway) but you can offer the chance, even the likelihood, of capturing the world's most advanced malware.

How can TorProject give them what they already have?

November 25, 2015

Permalink

ftw newer see it before:
Nov 25 01:25:48.000 [err] tor_assertion_failed_(): Bug: src/or/connection.c:3680: connection_handle_event_cb: Assertion connection_state_is_connecting(conn) failed; aborting.
Nov 25 01:25:48.000 [err] Bug: Assertion connection_state_is_connecting(conn) failed in connection_handle_event_cb at src/or/connection.c:3680. (Stack trace not available)

November 29, 2015

In reply to gk

Permalink

Sorry but for security reasons this unit was immediately reloaded...
Maybe used config can help:
SocksPort ipA:portA IsolateDestAddr
DNSPort ipB:portB
OutboundBindAddress ipC
AvoidDiskWrites 1
TruncateLogFile 1
SafeLogging 0
NumEntryGuards N
NumDirectoryGuards N
OptimisticData 0
and a bunch of HSs
HiddenServiceDir
HiddenServicePort numX addrX:portXX
...
HiddenServicePort numZ addrZ:portZZ

November 29, 2015

In reply to gk

Permalink

Sorry have just noticed it was the problem with bufferevent...
So no problems without them ever since.

You mean point a .onion to port 9051? I don't see any harm in doing that as long as you keep the address secret, but do note that "tor over tor" (building a circuit through an existing one) is not recommended because the two circuits could choose the same relay nodes or nodes in the same family or subnet. That being said, I cant think of a case where a control port .onion would be useful, except maybe connecting to your relay's contol port remotely for statistics or something.

Thanks. Its 'for statistics or something'. And we have several remote Tor nodes w/o terminal etc. I just wonder if info about port number someway is used in registering HS with all this buzz about Tor search engines. (Of course port will be changed by 'ControlPort PORT' but anyway.) Btw is 'choose the same relay nodes' twice less secure then using them just once? (I don't mean additional load on Tor network.)

The local port is irrelevant to HSDir registrations. The Tor instance hosting the HS first generates a .onion address and sends it to an HSDir along with an introduction node of its choosing. When a remote user requests said .onion address, the HSDir sends back the intro node, to which the remote user connects to via a circuit of its choosing. The HS host builds and maintains a circuit of its own choosing to the intro node, so traffic goes through the remote user's circuit, through the intro node, and finally the rest of the HS host's circuit. This is all done over the "Tor protocol" ports of each relay (ORPort in torrc). The local port only comes into play when the traffic reaches the HS host's local Tor instance, and is forwarded to the web server or what-have-you on the local machine.

As for choosing the same relay nodes twice: consider when the "inner" tor client chooses for its exit node the same relay as the "outer" client's entrance node. This creates a client-A-B-C-D-E-A-server circuit. The trip through B, C, D and E is basically for naught, because "A" is now communicating directly with the client and the server simultaneously. How does it know which client is connecting to which server? A malicious relay in A's position could "modulate" (pause and resume) traffic flow (as an entrance node) for a given client, then look for outbound traffic exhibiting the same modulated pattern (as an exit node) as it sends it to its final destination. Even without an active attack, the viability of passive attacks (like timing) for a malicious relay in A's position would become much easier since the relay has both the entrance and exit traffic data. This is an extreme example, but even less obvious configurations could be harmful, because each Tor client carefully selects its own nodes (persistent entry guard, nodes from different subnets/families/countries, etc), but an "inner" circuit cannot know anything about an "outer" circuit, thus they can inadvertently cancel each other out.

November 27, 2015

Permalink

I can't wait for this !!!!

THANK YOU !

Looking forward to the expert version soon !

November 27, 2015

Permalink

I am New To Tor. being due to my back being broke twice and neck once , and many other health problem's . I would like to at least keep my mind working(tiny). I would like to know step by step on how to set everything up, that's from a V.M all the way through crypto,what e mail to use etc etc. I am using an older xp pro. I am willing to learn,but need it (baby) step by step. Once i learn i would be willing to help other with paitents . Thanks Very Much Go Tor. If you need my e mail only one that i have is at hotmail (rookie) I know Thanks again...4 all of your help..

Well most importantly, don't use XP. I would say don't use Windows at all, but if it's all you're use to, then at least use a Windows that is not full of multiple known remote vulnerabilities like XP is.

You don't need a VM. Just install the Tor Browser Bundle, it contains everything you need. Set the security slider to "high" if you want to prioritize security, but it's not strictly necessary. And don't download and open documents, because those could contain code which can get your real IP (e.g. wmv videos, Word documents, pdfs, etc). But simply viewing a page in Tor Browser is fine, and you can do that safely without needing to know much about security.

A Torrified VM will protect you against more attacks than the Tor Browser alone. For example, the exploit of older versions of Firefox ESR (which TB is based on) gained remote code execution, and the payload (which was actually rather simple) would send the computer's hostname, MAC address, serial, etc. over a TCP socket to an address thought to be located at the FBI's West Virginia office.

A VM would have spoofed the machine's hostname, MAC address, and serial number, and would have likely blocked or transparently torrified the TCP connection.

To address OP's question, I think Tails would be the best solution in this particular case. It's easy to use, hard to misuse, doesn't require any installation, and doesn't touch the existing operating system. It has a transparent firewall and an "offline mode" for viewing untrusted files. But nothing works unless you use it, so use whatever you feel comfortable with, be it Tor Browser, Tails, or a VM.

November 28, 2015

Permalink

People have always had freedom of communication and i hope you would agree that only those who do not deserve freedom itself should loose this privilege. Just as any prisoner or condemned criminal will be unable to communicate without sanctions to their post, Internet, newspapers, radio or TV. Why then should we be condemned to a life where our privacy is invaded without any proof of wrongdoings or even cause to be suspected?

November 28, 2015

Permalink

"Packages should be up in a few days."

1 week later expert download still shows tor-win32-0.2.6.10.zip

Has it been held back because of errors ?

November 29, 2015

Permalink

Is there an explanation why the binaries (expert download) are still not available? I find it very irritating to receive news of the new stable version via the official mailing list and then not being able to dl and run the new version...

The announcement email still sits in my inbox as a reminder to check back on the web site every now and then. But in a few days it'll be 'out of sight, out of mind' and I'll keep running the old version...

Really annoying and so avoidable.
Regards, Tom

November 30, 2015

Permalink

I'm starting to feel a little paranoid about the delayed release.

Have the TOR devs been "approached" ???

Something wrong with the new version OR does it fix an exploit which has the TLA worried and they had to stop it being released ???

Just healthy paranoia. :)

November 30, 2015

Permalink

Towards Measuring Unobservability in Anonymous Communication Systems

by Fang Binxing

Anonymous communication technique is one of the main privacy-preserving techniques, which has been widely used to protect Internet users’ privacy. However, existing anonymous communication systems are particularly vulnerable to traffic analysis, and researchers have been improving unobservability of systems against Internet censorship and surveillance. However, how to quantify the degree of unobservability is a key challenge in anonymous communication systems. We model anonymous communication systems as an alternating turing machine, and analyze adversaries’ threat model. Based on this model, this paper proposes a relative entropy approach that allows to quantify the degree of unobservability for anonymous communication systems. The degree of unobservability is based on the probabilities of the observed flow patterns by attackers. We also apply this approach to measure the pluggable transports of TOR, and show how to calculate it for comparing the level of unobservability of these systems. The experimental results show that it is useful to evaluate the level of unobservability of anonymous communication systems. Finally, we present the conclusion and discuss future work on measuring unobservability in anonymous communication systems.

http://crad.ict.ac.cn/CN/abstract/abstract3031.shtml

December 01, 2015

Permalink

Guuuys listen up.. shouldnt the dom.storage option be disabled inside about:config in Torbrowser? I cant see why you left it enabled by default.. Im gonna disable it my self

So that websites and malicious exit nodes can see if it's you at the other end by testing for a disabled dom.storage setting? Tor Browser already blocks persistent storage (of many kinds) at a lower level (if in doubt use Tails). You can check this by creating a copy of your Tor Browser directory, then viewing a site known to use dom.storage, then diff'ing the two directories.

If you do find that it is saving dom.storage data persistently, file a bug report, but in the mean time changing random settings in about:config will only open you up to fingerprinting attacks.

December 03, 2015

Permalink

There is something wrong here.

No actual release yet, this has either been handled very badly, or there is some third party intervention.

My paranoia status is 10

"Actual release" meaning what? Source tarballs are available at https://www.torproject.org/download/download.html.en . How long it will take to get into bundles is based on Tor Browser's release cycle. A lot of distros already have 0.2.7.5. It's just the Windows binaries we're waiting on as far as I can tell.

I don't keep up with the Windows binaries, so I don't know how long after the source release it usually takes.

Perhaps though the maintainers should start posting "I have not been approached" in the days after a source release.

December 05, 2015

Permalink

Really, no actual release yet ?

Is TOR only for those who know how to compile now ? What about everyone else ?

December 06, 2015

Permalink

Will there be an "Expert" release soon ?

I would really appreciate an official release, I understand some are swapping an unofficial build.

It's not really fair to those who are unable to compile their own, forcing them to download third party versions.

December 07, 2015

Permalink

"It's just the Windows binaries we're waiting on as far as I can tell."

That's a considerable amount of users, probably most of them.

Are the Tor devs holding out for payment for the windows version or something ?

No. The official tor binaries for Windows are currently built while building Tor Browser. There will be a new release next Tuesday containing 0.2.7.5. Until then you can basically use the tor binary shipped with the latest alpha release as 0.2.7.4-rc is essentially the same as 0.2.7.5.

December 10, 2015

Permalink

Although I see the windows binaries will be released on Tuesday, I have to say this is a disappointing launch for the new Tor.

Imagine a new person to Tor reading this. The premature announcement, protracted, half cocked release makes my beloved Tor look unprofessional.

Please think of Tor's image and reputation, many new in-experienced users will be put off Tor if this is their first visit.

I appreciate many of you will hate "windoze" of any flavour, however it is used by most people and probably by many who actually need protection. Treating the windows users of Tor as less than to others will not build a trusting relationship.

Please make sure all OS's are catered for, even those you hate, before announcing a new version is ready. All that has happened with this release is windoze users feel let down.

This is not an ungrateful rant, I just want Tor to look it's best at all times, as do we all.