Tails

#2 Updated by intrigeri 2015-03-02 15:52:47

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. Bug #7283 or another crazy trick of ours, that perhaps is not needed with Tor 0.2.6 anymore?

#3 Updated by anonym 2015-03-10 12:32:53

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 2015-03-11 15:19:26

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 Bug #7283.

#5 Updated by intrigeri 2015-03-12 09:34:40

> 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 2015-03-12 15:04:05

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 Feature #15245.

#7 Updated by anonym 2015-03-12 15:42:40

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 Feature #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 2015-03-12 22:45:08

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.

#11 Updated by intrigeri 2015-03-17 10:00:58

> 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 :)

#15 Updated by intrigeri 2015-03-17 11:47:25

>

> 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 2015-03-17 15:17:48

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.