New releases: Tor 0.4.2.6 and 0.4.1.8

We have two new stable releases today. If you build Tor from source, you can download the source code for 0.4.2.6 from the download page on our website. Packages should be available within the next several weeks, with a new Tor Browser by mid-February.

We've also put out an update for our older stable 0.4.1.x series: 0.4.1.8 (changelog), which you can download at dist.torproject.org. Note that the currently supported release series are now 0.3.5.x (LTS), 0.4.1.x, 0.4.2.x, and 0.4.3.x (in alpha).  The 0.2.9.x series became unsupported on January 1, and support for 0.4.0.x will end on February 2.

This is the second stable release in the 0.4.2.x series. It backports several bugfixes from 0.4.3.1-alpha, including some that had affected the Linux seccomp2 sandbox or Windows services. If you're running with one of those configurations, you'll probably want to upgrade; otherwise, you should be fine with 0.4.2.5.

Changes in version 0.4.2.6 - 2020-01-30

  • Major bugfixes (linux seccomp sandbox, backport from 0.4.3.1-alpha):
    • Correct how we use libseccomp. Particularly, stop assuming that rules are applied in a particular order or that more rules are processed after the first match. Neither is the case! In libseccomp <2.4.0 this led to some rules having no effect. libseccomp 2.4.0 changed how rules are generated, leading to a different ordering, which in turn led to a fatal crash during startup. Fixes bug 29819; bugfix on 0.2.5.1-alpha. Patch by Peter Gerber.
    • Fix crash when reloading logging configuration while the experimental sandbox is enabled. Fixes bug 32841; bugfix on 0.4.1.7. Patch by Peter Gerber.
  • Minor bugfixes (correctness checks, backport from 0.4.3.1-alpha):
    • Use GCC/Clang's printf-checking feature to make sure that tor_assertf() arguments are correctly typed. Fixes bug 32765; bugfix on 0.4.1.1-alpha.

 

  • Minor bugfixes (logging, crash, backport from 0.4.3.1-alpha):
    • Avoid a possible crash when trying to log a (fatal) assertion failure about mismatched magic numbers in configuration objects. Fixes bug 32771; bugfix on 0.4.2.1-alpha.
  • Minor bugfixes (testing, backport from 0.4.3.1-alpha):
    • When TOR_DISABLE_PRACTRACKER is set, do not apply it to the test_practracker.sh script. Doing so caused a test failure. Fixes bug 32705; bugfix on 0.4.2.1-alpha.
    • When TOR_DISABLE_PRACTRACKER is set, log a notice to stderr when skipping practracker checks. Fixes bug 32705; bugfix on 0.4.2.1-alpha.
  • Minor bugfixes (windows service, backport from 0.4.3.1-alpha):
    • Initialize the publish/subscribe system when running as a windows service. Fixes bug 32778; bugfix on 0.4.1.1-alpha.
  • Testing (backport from 0.4.3.1-alpha):
    • Turn off Tor's Sandbox in Chutney jobs, and run those jobs on Ubuntu Bionic. Turning off the Sandbox is a work-around, until we fix the sandbox errors in 32722. Closes ticket 32240.
    • Re-enable the Travis CI macOS Chutney build, but don't let it prevent the Travis job from finishing. (The Travis macOS jobs are slow, so we don't want to have it delay the whole CI process.) Closes ticket 32629.
  • Testing (continuous integration, backport from 0.4.3.1-alpha):
    • Use zstd in our Travis Linux builds. Closes ticket 32242.

For what it's worth, I'm going to be a little more strict about moderating off-topic comments here than I have been for the past few release posts. If you're asking a question about Tor Browser, the Tor website, or the latest anti-censorship situation in some particular country, and you don't see the comment get approved here, that's why.

Anonymous

January 31, 2020

Permalink

And what's the point of enabling a client-only build in TOR? Including a client-only build in Tor Browser won't significantly reduce its size, the Firefox part of the Tor Browser is way bigger than the TOR part?

There are a lot of things that can embed Tor, and Tor Browser isn't the only one. If you're looking at lightweight chat apps for instance, or targeting a mobile enviornment, then savings on download size start to look pretty attractive.

Thanks, it worked.

>I'll open a bug against the website

While you're at it: when posting the previous comment, after I hit 'Preview' and then 'Save' the page started reloading in a loop, had to manually interrupt it with Escape. Just caught a similar (or the same) bug after a double 'Preview':

1. Open TorBrowser / invoke 'New Identity'.
2. Enter a comment (with captcha and all) and press 'Preview'.
3. On the preview page press 'Preview' again -> the page goes into a reload loop.
4. Interrupt with Escape.
5. Repeat 1-3 and optionally press 'Preview' some more -> everything works fine.

>Enable Javascript.

Violates my privacy and security policies. Also posting evidently does work so reload loops are more of a nuisance. Thanks for the ticket link though.

Anonymous

February 21, 2020

Permalink

I'm getting a bunch of bug errors popping up on a bridge relay. Should I be worried about that?

"Feb 21 17:48:17.000 [warn] Couldn't rotate onion key.
Feb 21 17:48:17.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/relay/router.c:2365: router_rebuild_descriptor: Non-fatal assertion !(desc_gen_reason == NULL) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.2.6 )
Feb 21 17:48:17.000 [warn] Bug: Tor 0.4.2.6: Non-fatal assertion !(desc_gen_reason == NULL) failed in router_rebuild_descriptor at ../src/feature/relay/router.c:2365. Stack trace: (on Tor 0.4.2.6 )
Feb 21 17:48:17.000 [warn] Bug: /usr/bin/tor(log_backtrace_impl+0x6d) [0x64843d] (on Tor 0.4.2.6 )
Feb 21 17:48:17.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0x10a) [0x6437da] (on Tor 0.4.2.6 )
Feb 21 17:48:17.000 [warn] Bug: /usr/bin/tor(router_rebuild_descriptor+0x166) [0x576a86] (on Tor 0.4.2.6 )
Feb 21 17:48:17.000 [warn] Bug: /usr/bin/tor(+0x13417b) [0x57117b] (on Tor 0.4.2.6 )
Feb 21 17:48:17.000 [warn] Bug: /usr/bin/tor(+0x5e67e) [0x49b67e] (on Tor 0.4.2.6 )
Feb 21 17:48:17.000 [warn] Bug: /lib/i386-linux-gnu/libevent-2.1.so.6(+0x20b7b) [0xb7d91b7b] (on Tor 0.4.2.6 )
Feb 21 17:48:17.000 [warn] Bug: /lib/i386-linux-gnu/libevent-2.1.so.6(event_base_loop+0x4d1) [0xb7d923b1] (on Tor 0.4.2.6 )
Feb 21 17:48:17.000 [warn] Bug: /usr/bin/tor(tor_libevent_run_event_loop+0x30) [0x5d83a0] (on Tor 0.4.2.6 )
Feb 21 17:48:17.000 [warn] Bug: /usr/bin/tor(do_main_loop+0x107) [0x49a847] (on Tor 0.4.2.6 )
Feb 21 17:48:17.000 [warn] Bug: /usr/bin/tor(run_tor_main_loop+0x16d) [0x486a3d] (on Tor 0.4.2.6 )
Feb 21 17:48:17.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x105d) [0x487e5d] (on Tor 0.4.2.6 )
Feb 21 17:48:17.000 [warn] Bug: /usr/bin/tor(tor_main+0x3f) [0x48525f] (on Tor 0.4.2.6 )
Feb 21 17:48:17.000 [warn] Bug: /usr/bin/tor(main+0x32) [0x484dd2] (on Tor 0.4.2.6 )
Feb 21 17:48:17.000 [warn] Bug: /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0xb7687b41] (on Tor 0.4.2.6 )
Feb 21 17:48:17.000 [warn] Bug: /usr/bin/tor(_start+0x31) [0x484e31] (on Tor 0.4.2.6 )"

Ouch. That is unpleasant, but I don't think it's anything to worry about. If you can, could you open a bug report at trac.torproject.org? Stuff that it would help to know is:
* how frequently does this happen?
* what OS are you on?
* are you low on disk space, and are the permissions on your keys directory set correctly?
* Did you upgrade from a previous version of Tor, or is this a new installation?

thanks!

Is this bad?=====>
/var/lib/tor/keys# ls -l
total 28
-rwxr-xr-x 1 root debian-tor 64 Jan 24 02:03 ed25519_master_id_public_key
-rwxr-xr-x 1 root debian-tor 96 Jan 24 02:03 ed25519_master_id_secret_key
-rw------- 1 debian-tor debian-tor 172 Feb 22 03:00 ed25519_signing_cert
-rw------- 1 debian-tor debian-tor 96 Feb 22 03:00 ed25519_signing_secret_key
-rwxr-xr-x 1 root debian-tor 887 Jan 24 02:03 secret_id_key
-rwxr-xr-x 1 root debian-tor 887 Jan 24 02:03 secret_onion_key
-rwxr-xr-x 1 root debian-tor 96 Jan 24 02:03 secret_onion_key_ntor

Yikes. See how the secret keys are all owned by root, and only root-writable? That's not a great sign. They should be owned by the Tor user, I think. But that shouldn't stop Tor from rotating them, I think.

First thing to do is make sure that users other than debian-tor can't see the contents of those files. If they can be read by another user, you might need to replace all your relay's keys entirely, if you think it's possible they've been read by somebody besides you. You can just delete them away, and Tor will make a new set of keys and behave like a new relay.

If the keys are still secure, try making sure that they're owned by debian-tor, not root. They should also be mode 600 or 660, definitely not 755. Also check the ownership and permissions on the keys directory; it should be mode 700 or 770.

I think they were still secure. changed the permissions as requested.

# ls -l
total 36
-rw------- 1 debian-tor debian-tor 64 Jan 24 02:03 ed25519_master_id_public_key
-rw------- 1 debian-tor debian-tor 96 Jan 24 02:03 ed25519_master_id_secret_key
-rw------- 1 debian-tor debian-tor 172 Feb 22 03:00 ed25519_signing_cert
-rw------- 1 debian-tor debian-tor 96 Feb 22 03:00 ed25519_signing_secret_key
-rw------- 1 debian-tor debian-tor 887 Jan 24 02:03 secret_id_key
-rw------- 1 debian-tor debian-tor 892 Feb 24 03:48 secret_onion_key
-rw------- 1 debian-tor debian-tor 96 Feb 24 03:48 secret_onion_key_ntor
-rw------- 1 debian-tor debian-tor 96 Jan 24 02:03 secret_onion_key_ntor.old
-rw------- 1 debian-tor debian-tor 887 Jan 24 02:03 secret_onion_key.old

Join the discussion...

We encourage respectful, on-topic comments. Comments that violate our Code of Conduct will be deleted. Off-topic comments may be deleted at the discretion of the post moderator. Please do not comment as a way to receive support or report bugs on a post unrelated to a release. If you are looking for support, please see our support portal or ways to get in touch with us.

This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.

1 + 1 =
Solve this simple math problem and enter the result. E.g. for 1+3, enter 4.