Tor 0.2.4.26 and 0.2.5.11 are released

by nickm | March 24, 2015

Hello! I released Tor 0.2.4.26 and 0.2.5.11 last week. This is the formal announcement.

(Per usual practice with non-critical stable releases, I've delayed
the tor-announce announcement to give distributions have a chance to
make packages. If you are a packager and you didn't notice that,
please let me know and I'll put you on the list of people I notify
extra-early about new releases.)

Tor 0.2.4 and 0.2.5 are stable release series. Going forward, they will continue to only receive patches for really serious issues.

You can get the source code for Tor 0.2.4.26 and 0.2.5.11 from the download page, or at https://dist.torproject.org/. If you're running TorBrowser 4.0.5, you already have Tor 0.2.5.11. Remember to check the signatures!

The changelogs follow below...

Tor 0.2.4.26 includes an updated list of directory authorities. It also backports a couple of stability and security bugfixes from 0.2.5 and beyond.

Changes in version 0.2.4.26 - 2015-03-17

  • Directory authority changes:
    • Remove turtles as a directory authority.
    • Add longclaw as a new (v3) directory authority. This implements ticket 13296. This keeps the directory authority count at 9.
    • The directory authority Faravahar has a new IP address. This closes ticket 14487.
  • Major bugfixes (exit node stability, also in 0.2.6.3-alpha):
    • Fix an assertion failure that could occur under high DNS load. Fixes bug 14129; bugfix on Tor 0.0.7rc1. Found by "jowr"; diagnosed and fixed by "cypherpunks".
  • Major bugfixes (relay, stability, possible security, also in 0.2.6.4-rc):
    • Fix a bug that could lead to a relay crashing with an assertion failure if a buffer of exactly the wrong layout was passed to buf_pullup() at exactly the wrong time. Fixes bug 15083; bugfix on 0.2.0.10-alpha. Patch from 'cypherpunks'.
    • Do not assert if the 'data' pointer on a buffer is advanced to the very end of the buffer; log a BUG message instead. Only assert if it is past that point. Fixes bug 15083; bugfix on 0.2.0.10-alpha.
  • Minor features (geoip):
    • Update geoip to the March 3 2015 Maxmind GeoLite2 Country database.
    • Update geoip6 to the March 3 2015 Maxmind GeoLite2 Country database.

Tor 0.2.5.11 is the second stable release in the 0.2.5 series.
It backports several bugfixes from the 0.2.6 branch, including a couple of medium-level security fixes for relays and exit nodes. It also updates the list of directory authorities.

Changes in version 0.2.5.11 - 2015-03-17

  • Directory authority changes:
    • Remove turtles as a directory authority.
    • Add longclaw as a new (v3) directory authority. This implements ticket 13296. This keeps the directory authority count at 9.
    • The directory authority Faravahar has a new IP address. This closes ticket 14487.
  • Major bugfixes (crash, OSX, security):
    • Fix a remote denial-of-service opportunity caused by a bug in OSX's _strlcat_chk() function. Fixes bug 15205; bug first appeared in OSX 10.9.
  • Major bugfixes (relay, stability, possible security):
    • Fix a bug that could lead to a relay crashing with an assertion failure if a buffer of exactly the wrong layout was passed to buf_pullup() at exactly the wrong time. Fixes bug 15083; bugfix on 0.2.0.10-alpha. Patch from 'cypherpunks'.
    • Do not assert if the 'data' pointer on a buffer is advanced to the very end of the buffer; log a BUG message instead. Only assert if it is past that point. Fixes bug 15083; bugfix on 0.2.0.10-alpha.
  • Major bugfixes (exit node stability):
    • Fix an assertion failure that could occur under high DNS load. Fixes bug 14129; bugfix on Tor 0.0.7rc1. Found by "jowr"; diagnosed and fixed by "cypherpunks".
  • Major bugfixes (Linux seccomp2 sandbox):
    • Upon receiving sighup with the seccomp2 sandbox enabled, do not crash during attempts to call wait4. Fixes bug 15088; bugfix on 0.2.5.1-alpha. Patch from "sanic".
  • Minor features (controller):
    • New "GETINFO bw-event-cache" to get information about recent bandwidth events. Closes ticket 14128. Useful for controllers to get recent bandwidth history after the fix for ticket 13988.
  • Minor features (geoip):
    • Update geoip to the March 3 2015 Maxmind GeoLite2 Country database.
    • Update geoip6 to the March 3 2015 Maxmind GeoLite2 Country database.
  • Minor bugfixes (client, automapping):
    • Avoid crashing on torrc lines for VirtualAddrNetworkIPv[4|6] when no value follows the option. Fixes bug 14142; bugfix on 0.2.4.7-alpha. Patch by "teor".
    • Fix a memory leak when using AutomapHostsOnResolve. Fixes bug 14195; bugfix on 0.1.0.1-rc.
  • Minor bugfixes (compilation):
    • Build without warnings with the stock OpenSSL srtp.h header, which has a duplicate declaration of SSL_get_selected_srtp_profile(). Fixes bug 14220; this is OpenSSL's bug, not ours.
  • Minor bugfixes (directory authority):
    • Allow directory authorities to fetch more data from one another if they find themselves missing lots of votes. Previously, they had been bumping against the 10 MB queued data limit. Fixes bug 14261; bugfix on 0.1.2.5-alpha.
    • Enlarge the buffer to read bwauth generated files to avoid an issue when parsing the file in dirserv_read_measured_bandwidths(). Fixes bug 14125; bugfix on 0.2.2.1-alpha.
  • Minor bugfixes (statistics):
    • Increase period over which bandwidth observations are aggregated from 15 minutes to 4 hours. Fixes bug 13988; bugfix on 0.0.8pre1.
  • Minor bugfixes (preventative security, C safety):
    • When reading a hexadecimal, base-32, or base-64 encoded value from a string, always overwrite the whole output buffer. This prevents some bugs where we would look at (but fortunately, not reveal) uninitialized memory on the stack. Fixes bug 14013; bugfix on all versions of Tor.

Comments

Please note that the comment area below has been archived.

March 24, 2015

Permalink

When will we be able to compile Tor comfortably on Microsoft Windows using Visual Studio?

yes mingw works fine, well in my case i used mingw32. tor doesnt compile in x64 target anyway. does it?
cygwin also works fine for rc and aplha win builds compiled on your own easily. if you wonder why tor.exe gets much bigger than usual, ;) try this from msys:
strip tor.exe

March 24, 2015

Permalink

I really love the idea of having a tor browser but when I start to look for certain things inside the deep web I am unable to find them I really would like to know what to do.

March 24, 2015

Permalink

I get the following error upon downloading the new update!

WARNING: This key is not certified with a trusted signature!

March 24, 2015

Permalink

PROBLEM: please explain:

No problem with manually Guard entry in torcc with guardnode has 2.5.10.
In Tails.

The same Guard nodes has changed to 2.5.11: you can NOT set these nodes as
Entry Guard. Hop 0 discarded.

Do on purpose?

hello you have written my error log i see daily in logs when my connection is marked as down in state file from tor not found hop 0 for path... if i delete state file from tor datadirectory and restart tor, it connects normally to the entry guard. the guard gets marked as down by mistake, very often resulting in no circiuts because first hop cant be found any longer. this is much anoying. i set 3 entry guards in torrc entrynode as it was default behaiviour for a while ago. but it only resulting in all guards marked as down after some longer amount of time. :( my entry guard is long uptime stable tagged longlived. this is client issue. same happen if you hibernate or standby os when resume the entry gets marked as down and tor client connects to the next available. this is not secure! if you see this error again. delete consensus and state files from datadirectory than you can use your guard again on that client try it out ;) may fill a bug please in trac i didnt use that before to report anything. i experienced the same on orbot when the network state changes from wifi to mobile internet...

March 24, 2015

Permalink

Surfing with Tails.

You can disable Disable Networking,Enable Networking and set new/custom torcc entry without any problem yet.

NOW something completely different:

Now his don't work?
Tor nodes/Guard Nodes has changed to 2.5.11.
It's working not or rather sometimes.
Long time Connection failed/Hop 0 discarded.

Same with changing torcc entries while tor is running.
Sometimes its working again:
"[Notice] Tor now sees network activity. Restoring circuit build timeout recording. Network was down for xxx seconds during xx circuit attempts."

Can you explain?

March 25, 2015

Permalink

Hola,
Tell me! how do we do regarding the bookmarks,it seems that they are lost during the process of upgrading.
Is there anyway to transfer them.

Gracias
M Fouchet

March 25, 2015

Permalink

Hi just a thought, Why doesn't Tails implement Grsecurity/PAX on the kernel, kinda like Liberte Linux?

F. Rosenblum

March 27, 2015

Permalink

OT, and I hope a false alarm, but someone at Tor Project should know in case this signals a serious problem:

Tried to upgrade tor, openssl, gnutls from Debian-Squeeze-LTS and got error message about the long term signing key:

http://http.debian.net squeeze-lts Release: The following signatures were invalid: BADSIG 8B48AD6246925553 Debian Archive Automatic Signing Key (7.0/wheezy)

Used apt-key list to list the keys, then used a keyserver to obtain them and found this key was allegedly revoked on 17 Mar 2015:

pub 4096R/46925553 created: 2012-04-27 expires: 2020-04-25 usage: SC
trust: unknown validity: unknown
This key was revoked on 2014-03-17 by RSA key 46925553 Debian Archive Automatic Signing Key (7.0/wheezy)
sub 4096R/ADD6B7E2 created: 2012-04-27 revoked: 2014-03-17 usage: E
[ unknown] (1). Debian Archive Automatic Signing Key (7.0/wheezy)

uid Debian Archive Automatic Signing Key (7.0/wheezy)
sig!3 7E7B8AC9 2012-04-27 Joerg Jaspert
sig!3 46925553 2012-04-27 [self-signature]

I tried again a few hours later and either a newer key verified or I've been popped. Our principal enemy has mastered the art of faking MD-5 hashes, but for what its worth, here are some important ones checked against what is in /var/lib/dpkg/info (but that can't be trusted if cert improperly issued by CA was used to MITM, I think):

8778f24ee05d16da848f12301b7ef6e6 /usr/bin/tor
8778f24ee05d16da848f12301b7ef6e6 /usr/bin/tor
d7e3e170a75611f864b243fc37640a59 /usr/bin/torify
d7e3e170a75611f864b243fc37640a59 /usr/bin/torify
02d3256d633903ca92a833a4d0108e7a /usr/bin/openssl
02d3256d633903ca92a833a4d0108e7a /usr/bin/openssl
5efecc698ef3cf80decd191f87207cde /usr/lib/libgnutls-openssl.so.26.14.12
5efecc698ef3cf80decd191f87207cde /usr/lib/libgnutls-openssl.so.26.14.12

This occurs in the context of

* a reported current attack on github

* previous attacks on kernel.org (which hosts the mirror where I got the allegedly correctly signed upgrades)

* the Debian ugrades mentioned above and the emergency fix to Tails is intended to fix the fake "Google" certs blacklisted by Mozilla.

* the new Tails key is signed by some Debian developers, so I want to maximize my confidence that I have the correct keys.

* failure to download the latest Tails (right size, but wrong hash and hence signature fails to verify)

* problems contacting webmail server so currently can't use email

Thanks to all at the Project for their hard work, and for their new found resolution to try to make things difficult for governments which don't like Open Access, social justice, environmental advocates.

March 27, 2015

Permalink

> Why doesn't Tails implement Grsecurity/PAX on the kernel, kinda like Liberte Linux?

Tails is a separate project. Maybe someone affiliated with Tails will provide an authoritative answer, but from browsing their documentation page, I think the answer is that AppArmor is easier to adapt to Tails, but currently trying to adapt Grsecurity/PAX would break too many things or even open unforeseen vulnerabilities. Tails tends to take a conservative approach to defense, which I think is wise in the current atmosphere of cyberwarriors running amok.

March 29, 2015

Permalink

Hello. Using Meek - Google in TBB 4.0.5 is much slower* than normal tor speed received in TBB 4.0.3 with Meek - Google.
So I had gone back to 4.0.3 until this is fixed.
I know speed of internet is not a simple problem, but I have tested this again and again, no effect. 4.0.5 meek-google is much slow and unusable while meek-google in 4.0.3 is at normal expected tor speed.

I guess this sounds like bad report without extra info, but if you tell how, I can give more info on it. But please I wish someone else in this blog will test this to confirm.

March 30, 2015

Permalink

There is still no Windows version of this release available under https://dist.torproject.org/win32/.

Only on the download page on torproject.org (https://www.torproject.org/download/download.html.en) you can get version 0.2.5.11 (Windows "Expert Bundle"), but this seems to be completely different from the older ones and the ones at https://dist.torproject.org/win32/. They contain some DLLs and also doesn't show any console output.

Okay now I found out that there is no console output is a known issue (https://trac.torproject.org/projects/tor/ticket/13819) but I'm still curious where the standalone exe is...

If you want a newer standalone exe, you can download one of the Tor Browsers and then just take the tor.exe from it. That's the same tor.exe you'll get from the expert package.

April 03, 2015

In reply to arma

Permalink

Yes, but you still have to copy all the DLLs too. So it's not really a standalone exe.

March 31, 2015

Permalink

Why only tor plain (aka 'expert bundle') or the browser bundle? What happened to the vidalia bundle options? Why make things harder for people that want to run nodes on windows? Or is vidalia no longer compatible with current versions of tor?

vidalia is obsolete and it doenst support ipv6.
connect ipv6 ip and see how it breaks the view...it splits the ip by second ":" as vidalia thinks this is a port! fail! no this bug is unreported