Custom Query (24299 matches)


Show under each result:

Results (55 - 57 of 24299)

Ticket Resolution Summary Owner Reporter
#1134 fixed Our still handles --with-tor-group arma

Even though the Group torrc option is obsolete as of 0.2.0.x, our script still handles --with-tor-group

Then our contributed tor.spec file still tries to pass in things like %configure --with-tor-user=%{toruser} --with-tor-group=%{torgroup}

Also, contrib/osx/Tor launches tor with the --group option, which Tor ignores:

$TORCMD -f "$TORCONF" --runasdaemon 1 --pidfile "$TORPID" --data

directory "$TORDATA" --user "$TORUSER" --group "$TORGROUP" --log "notice file $T ORLOG" &

We should change the packages so they stop trying to call the obsolete Group config option, and change to either ignore it or complain.

[Automatically added by flyspray2trac: Operating System: All]

#1135 fixed Fedora init scripts kill all tor processes mikeperry

Instead of using the Tor pidfile, the Fedora init scripts end up doing a 'killall tor' on stop and restart.

This has the nasty effect of killing all other running tors on your system, in addition to the system one.

[Automatically added by flyspray2trac: Operating System: All]

#1138 fixed If bridge authority is unreachable, client doesn't fallback to bridge mwenge arma

When a Tor client starts up using a bridge, and UpdateBridgesFromAuthority is set (which it is when Vidalia configures you to use a bridge), Tor will go to the authority first and look up the bridge by fingerprint.

If the bridge authority doesn't have the bridge, or Tor doesn't know the fingerprint, then Tor will fall back to asking the bridge directly.

If the bridge authority is filtered, though, then Tor will never notice that the bridge authority lookup failed. So it will never fall back. Fail.

Our workaround for now is to stop giving out fingerprints via bridgedb.

[Automatically added by flyspray2trac: Operating System: All]

Note: See TracQuery for help on using queries.