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 oiyfgiixvl.tudasnich.de. 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):
- 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.
Comments
Please note that the comment area below has been archived.
For what it's worth, I'm…
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.
And what's the point of…
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…
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.
gpg tells me the signature…
gpg tells me the signature for 0.4.2.6 was made with 7A02B3521DC75C542BA015456AFEE6D49E92B601 which I don't have. I found this https://2019.sedvblmbog.tudasnich.de/docs/signing-keys which is apparently out of date, and this https://ijpaagiacu.tudasnich.de/tbb/how-to-verify-signature/ which is TBB related. So what do I do?
Hm, you're right that this…
Hm, you're right that this key isn't exactly easy to find. (I looked around for a couple of minutes and didn't run into it.)
Anyway, thanks for verifying the signature! For now you can find my key at the "people" page at https://sedvblmbog.tudasnich.de/about/people/ . I'll open a bug against the website to try to make it easier to locate.
Thanks, it worked. >I'll…
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.
#5 should read 'Repeat 2-3'…
#5 should read 'Repeat 2-3'. Sorry for any confusion.
> when posting the previous…
> when posting the previous comment, after I hit 'Preview' and then 'Save' the page started reloading in a loop
Enable Javascript. (Standard or Safer security level.)
https://trac.torproject.org/projects/tor/ticket/22530
>Enable Javascript. …
>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.
I'm getting a bunch of bug…
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,…
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…
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…
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…
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