Hello all,
I just tagged obfs4proxy-0.0.5, this time with improvements for both clients and servers. All users are recommended to upgrade. Special thanks to mvdan for various code cleanups.
Tarball/Signature: https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.5.... https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.5....
Changes in version 0.0.5 - 2015-04-15:
- Go vet/fmt fixes, and misc. code cleanups. Patches by mvdan.
- Changed the go.net import path to the new location (golang.org/x/net).
- Added limited support for detecting if the parent process crashes.
- Support for tor feature #15335 (stdin based termination notification).
- Moved the leveled logging wrappers into common/log so they are usable in transport implementations.
- Added a DEBUG log level.
- Use a bundled SOCKS 5 server instead of goptlib's SocksListener.
The big features are:
- obfs4proxy now tries really hard to detect if the parent process has crashed, using various system specific hacks (and the new and improved tor assisted mechanism in #15335). This should reduce defunct obfs4proxy processes when tor happens to crash without tearing down the obfs4proxy instance.
- Instead of using goptlib's SOCKS4a server, obfs4proxy now includes a SOCKS5 implementation, bringing IPv6 support to clients. Note that running IPv6 bridges has always worked (though dual stack configs are currently somewhat broken due to a tor PT configuration protocol limitation).
Notes for packagers:
- Like in obfs4proxy-0.0.5, one of the upstream dependency locations has changed. (code.google.com/p/go.net -> golang.org/x/net).
As far as I am aware, migrating to the new package immediately is not required though, should be done sooner rather than later due to the impending deprecation of code.google.com.
To temporarily continue to build against the old go.net dependency, please revert: aed4b723891db1be34eb866a03c62806b58ac148
- It is *strongly* recommended that packages be built against goptlib-0.4 or newer to work around tor bug #15240. Without this workaround, certain bridges will fail to operate correctly when the ExtORPort is enabled (the Tor side fix is in tor-0.2.6.5-rc and newer).
Questions, comments, feedback appreciated,