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,
The v0.5 binary is substantially larger than the v0.4 binary (7204KB vs.5408KB, both built with Go v1.4.2).
Is this expected behavior with the newer version of obfs4proxy?
On Wednesday, April 15, 2015 5:19pm, "Yawning Angel" yawning@schwanenlied.me said:
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev 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,
-- Yawning Angel
On Thu, 16 Apr 2015 14:03:58 -0400 (EDT) "Steve Snyder" swsnyder@snydernet.net wrote:
The v0.5 binary is substantially larger than the v0.4 binary (7204KB vs.5408KB, both built with Go v1.4.2).
Is this expected behavior with the newer version of obfs4proxy?
Building on linux/amd64 with 1.4.2 I get:
* 0.0.4 7441792 * 0.0.5 7424544
If I strip either binary I get something in the 5 MiB range, so that might be where the difference is coming from, though I would strongly discourage doing so as it is not something that is supported by the toolchain developers[0], and if a binary that has been stripped breaks, I'm not going to do anything about it beyond saying "don't do that".
Regards,
On Thu, Apr 16, 2015 at 06:48:53PM +0000, Yawning Angel wrote:
On Thu, 16 Apr 2015 14:03:58 -0400 (EDT) "Steve Snyder" swsnyder@snydernet.net wrote:
The v0.5 binary is substantially larger than the v0.4 binary (7204KB vs.5408KB, both built with Go v1.4.2).
Is this expected behavior with the newer version of obfs4proxy?
Building on linux/amd64 with 1.4.2 I get:
- 0.0.4 7441792
- 0.0.5 7424544
If I strip either binary I get something in the 5 MiB range, so that might be where the difference is coming from, though I would strongly discourage doing so as it is not something that is supported by the toolchain developers[0], and if a binary that has been stripped breaks, I'm not going to do anything about it beyond saying "don't do that".
In Tor Browser we build with go build -ldflags '-s'
https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/de...
Check discussion here: https://trac.torproject.org/projects/tor/ticket/12649
David Fifield
-
David Fifield -
Steve Snyder -
Yawning Angel