Project

General

Profile

Feature #8925

Feature #7934: Upgrade to Tor 0.2.6.x

Test Tor 0.2.6.x in the context of Tails

Added by intrigeri almost 5 years ago. Updated almost 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
02/20/2015
Due date:
% Done:

100%

Feature Branch:
feature/8925-tor-0.2.6
Type of work:
Test
Blueprint:
Starter:
Affected tool:

Description

0.2.6.3-alpha is out, and this branch is in hard feature freeze. Would be a great time to check if it breaks anything for us (hint: time sync'ing).

History

#1 Updated by intrigeri almost 5 years ago

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10
  • Feature Branch set to feature/8925-tor-0.2.6

#2 Updated by intrigeri almost 5 years ago

Passes the test suite entirely, except whatever we do when bridges configuration is chosen makes the tor process crash. Tor Launcher says "Could not connect to Tor control port.", and indeed Tor has segfaulted. /var/log/tor/log reads:

<Mar 02 15:00:46.000 [notice] Tor 0.2.6.3-alpha (git-a8fbe3b035e0cb1f) opening new log file.
Mar 02 15:00:46.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Mar 02 15:00:47.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Mar 02 15:00:47.000 [notice] Bootstrapped 0%: Starting
Mar 02 15:00:47.000 [notice] Delaying directory fetches: DisableNetwork is set.
Mar 02 15:00:47.000 [notice] New control connection opened from 127.0.0.1.
Mar 02 15:00:47.000 [notice] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
Mar 02 15:00:47.000 [notice] Caching new entry debian-tor for debian-tor
Mar 02 15:00:47.000 [notice] Tor 0.2.6.3-alpha (git-a8fbe3b035e0cb1f) opening log file.
Mar 02 15:00:47.000 [warn] Your log may contain sensitive information - you're logging more than "notice". Don't log unless it serves an important reason. Overwrite the log afterwards.
Mar 02 15:00:47.000 [info] cell_ewma_set_scale_factor(): Disabled cell_ewma algorithm because of value in Default value
Mar 02 15:00:47.000 [info] options_act(): Worker-related options changed. Rotating workers.

============================================================ T= 1425308447
Tor 0.2.6.3-alpha (git-a8fbe3b035e0cb1f) died: Caught signal 11
/usr/bin/tor(+0x128f2e)[0xf7707f2e]
/lib/i386-linux-gnu/libpthread.so.0(pthread_mutex_lock+0x1d)[0xf7198e8d]
/lib/i386-linux-gnu/libpthread.so.0(pthread_mutex_lock+0x1d)[0xf7198e8d]
/lib/i386-linux-gnu/libc.so.6(pthread_mutex_lock+0x36)[0xf728cd76]
/usr/bin/tor(tor_mutex_acquire+0x2c)[0xf77220cc]

After manually starting the tor service again, killing tor-launcher, and manually starting /usr/local/sbin/tails-tor-launcher from a root terminal, Tor bootstraps successfully.

anonym, may you please have a look? It might be related to e.g. #7283 or another crazy trick of ours, that perhaps is not needed with Tor 0.2.6 anymore?

#3 Updated by anonym almost 5 years ago

Actually, Tor Launcher seems to have nothing to do with this. This fixes it for me:

--- a/config/chroot_local-includes/etc/NetworkManager/dispatcher.d/10-tor.sh
+++ b/config/chroot_local-includes/etc/NetworkManager/dispatcher.d/10-tor.sh
@@ -49,7 +49,6 @@ if [ "$(tails_netconf)" = "obstacle" ]; then
    # when no bridge is used the severity is "warn". tordate/20-time.sh
    # depends on grepping these error messages, so we temporarily
    # increase Tor's logging severity.
-   tor_control_setconf "Log=\"info file ${TOR_LOG}\"" 

    /usr/local/sbin/tails-tor-launcher &
 fi

#4 Updated by anonym almost 5 years ago

Indeed, any try to SETCONF Log=... makes Tor segfault, and I've verified that it's not our shell library that's broken by doing it all manually with netcat (which of course ends up being equivalent, oh well). Actually, SETCONF Log is enough to make Tor go boom. Note that it doesn't matter if we are using bridge mode. Also note that this doesn't affect Vidalia's logging facility since it's using the event listener, and not SETCONF Log in any way.

In other news, I pushed commit 37f7e24 (and a small fixup in commit 53ce7cd), which removes our in-tree Tor Launcher and makes us use the Tor Browser's bundled Tor Launcher, which will fix #7283.

#5 Updated by intrigeri almost 5 years ago

Actually, SETCONF Log is enough to make Tor go boom.

Excellent debugging! Are you going to report this to Tor, or should I?

#6 Updated by anonym almost 5 years ago

intrigeri wrote:

Actually, SETCONF Log is enough to make Tor go boom.

Excellent debugging! Are you going to report this to Tor, or should I?

Reported as Tor bug #15245.

#7 Updated by anonym almost 5 years ago

anonym wrote:

intrigeri wrote:

Actually, SETCONF Log is enough to make Tor go boom.

Excellent debugging! Are you going to report this to Tor, or should I?

Reported as Tor bug #15245.

Wow, already fixed! So in the next Tor rc we'll be able to test all time syncing stuff. Currently this bug prevents us from testing it with bridges, since the SETCONF Log=... thing we get the segfault from is related to that.

#8 Updated by anonym almost 5 years ago

anonym wrote:

So in the next Tor rc we'll be able to test all time syncing stuff. Currently this bug prevents us from testing it with bridges [...]

I can confirm that the non-bridge scenarios of time_syncing.feature passes just fine on Tor 0.2.6.4-rc.

#9 Updated by intrigeri almost 5 years ago

  • Assignee changed from intrigeri to anonym
  • QA Check set to Info Needed

I see commit:6a6093e added in that branch. Let's say it's fine, even if unrelated, because we'll merge this branch soonish. However, it brings one undocumented change, that is replacing --app with -?-app in the regexp. Why is that? If you can do it really soon, please rewrite the branch's history so that this change is in its own commit, that explains why we need it.

Also, shall I merge this branch into experimental, or is it too early in your opinion?

Once we've made up our mind on these points, I'll close this ticket as resolved, and the follow-ups will be tracked by #7934.

#10 Updated by anonym almost 5 years ago

  • Assignee changed from anonym to intrigeri

intrigeri wrote:

I see commit:6a6093e added in that branch. Let's say it's fine, even if unrelated, because we'll merge this branch soonish. However, it brings one undocumented change, that is replacing --app with -?-app in the regexp. Why is that? If you can do it really soon, please rewrite the branch's history so that this change is in its own commit, that explains why we need it.

Firefox accepts both single and double dash for its options. Here we used to grep for double dash only, but apparently we start Tor Launcher using single dash. So the Tor Launcher killing code is broken twice over. But, yeah, this is unrelated to this branch, and I'm unsure why I pushed it here since it's a regression and should be fixed in 1.3.1. Created #9067 + new branch with this commit (and updated commit message).

Would you mind if I dropped the commit from this branch to reduce the Git pollution?

Also, shall I merge this branch into experimental, or is it too early in your opinion?

At least wait until my question about dropping the commit is resolved.

#11 Updated by intrigeri almost 5 years ago

Would you mind if I dropped the commit from this branch to reduce the Git pollution?

Please do so, if you can do it, say, within 72 hours :)

#12 Updated by intrigeri almost 5 years ago

  • Assignee changed from intrigeri to anonym
  • QA Check changed from Info Needed to Dev Needed

#13 Updated by anonym almost 5 years ago

  • Assignee changed from anonym to intrigeri

intrigeri wrote:

Would you mind if I dropped the commit from this branch to reduce the Git pollution?

Please do so, if you can do it, say, within 72 hours :)

Done.

I tried to merge it into experimental, but he APT level merge (tails-merge-suite feature-8925-tor-0.2.6 experimental) failed:

basename: missing operand
Try 'basename --help' for more information.
Error: Too few arguments for command 'copy'!
Syntax: reprepro [-C <component> ] [-A <architecture>] [-T <packagetype>] copy <destination-distribution> <source-distribution> <package-names to pull>
There have been errors!
xargs: reprepro: exited with status 255; aborting

#14 Updated by anonym almost 5 years ago

  • Status changed from In Progress to Resolved
  • Assignee deleted (intrigeri)
  • % Done changed from 10 to 100
  • QA Check changed from Dev Needed to Pass

anonym wrote:

I tried to merge it into experimental, but he APT level merge (tails-merge-suite feature-8925-tor-0.2.6 experimental) failed:

Nevermind. There's of course no APT suite involved here (was thinking of the branch for Tor 0.2.5.11). Sorry for the noise! Experimental updated!

#15 Updated by intrigeri almost 5 years ago

> basename: missing operand
> Try 'basename --help' for more information.
> Error: Too few arguments for command 'copy'!
> Syntax: reprepro [-C <component> ] [-A <architecture>] [-T <packagetype>] copy
> <destination-distribution> <source-distribution> <package-names to pull>
> There have been errors!
> xargs: reprepro: exited with status 255; aborting
> 

Seems like tails-merge-suite should not try to merge an empty suite into anything.
Please file a low prio bug if you can be bothered to.

#16 Updated by anonym almost 5 years ago

intrigeri wrote:

Seems like tails-merge-suite should not try to merge an empty suite into anything.
Please file a low prio bug if you can be bothered to.

#9068

#17 Updated by BitingBird almost 5 years ago

  • Target version changed from Tails_1.3.2 to Tails_1.3.1

Also available in: Atom PDF