Another issue that Lunar raised in IRC is whether bridge operators will have to change their torrc after they upgrade to the new obfsproxy package.
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" to "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 upgrade.
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. )