[tor-dev] (Py)Obfsproxy Debian packages
desnacked at riseup.net
Wed Mar 27 22:59:45 UTC 2013
Another issue that Lunar raised in IRC is whether bridge operators
will have to change their torrc after they upgrade to the new
The answer (unfortunately) is yes; the obfsproxy torrc line will have
to change in two ways after an upgrade:
a) Bridge operators will have to change their ServerTransportPlugin
line to include new transports. So for example, after the upcoming
upgrade, they will have to change:
"ServerTransportPlugin obfs2 /usr/local/bin/obfsproxy --managed"
"ServerTransportPlugin obfs2,obfs3 /usr/local/bin/obfsproxy managed" .
This will be necessary till ticket #3725 is implemented, or till we
have better obfuscated bridge bundles, or till Linux distro
packages can somehow change tor's configuration.
b) In the current typical
"ServerTransportPlugin obfs2 /usr/local/bin/obfsproxy --managed" line,
"--managed" will have to be replaced with "managed" after the
This has to do with the way Python obfsproxy does
command-line-argument parsing, and how argparse subparses are still
a bit sucky: http://bugs.python.org/issue9253 . I haven't found a
nice solution for this, except from not using subparses but this
will require a big codebase change.
BTW, this will only happen the first time a user upgrades from
C-Obfsproxy to Python-obfsproxy.
Since the manual torrc update is not so easy to avoid, my suggestion
is to add a post-install hook to the obfsproxy packages that say "Hey,
thanks for upgrading obfsproxy. Don't forget to change your torrc line
to X". What do you think?
( Lunar suggested dodging b) by scanning the sys.argv for "--managed"
and inplace replace it with "managed" before the CLI parsing
happens. This is extremely evil, but it's not too hard to implement
and might even work. If we decide that Python-obfsproxy MUST
recognize "--managed", I might consider this. )
More information about the tor-dev