Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T05:36:57Zhttps://gitlab.torproject.org/legacy/trac/-/issues/20251Mac Sierra Rend stream2020-06-13T05:36:57ZTracMac Sierra Rend streamFresh install of Tor Browser following the download of the latest version of Tor Browser from the official website (with signature confirmed).
Removed ALL previous directory related to Tor so this really is a fresh start as much fresh as...Fresh install of Tor Browser following the download of the latest version of Tor Browser from the official website (with signature confirmed).
Removed ALL previous directory related to Tor so this really is a fresh start as much fresh as "find" command cannot find any mention of TorBrowser on the hard drive.
PS: same behaviour with latest version of Tor Browser following the upgrade to Mac Sierra (hence the reason I think this is a problem on Mac Sierra and not Tor itself).
Install tor and configure obfuscation 4
Start tor
(so far so good most of the time)
Try to access ANY tor website
Browse it for a while.
Suddenly, no more connection at all
Need to stop Tor Browser and start a new Tor Browser (from scratch, not a new window) to retrieve some connection.
Repeat
Cry
Here is a log:
27/9/16, 2:15:16.000 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
27/9/16, 2:15:16.000 [NOTICE] Opening Socks listener on 127.0.0.1:9150
27/9/16, 2:15:17.600 [NOTICE] Bootstrapped 5%: Connecting to directory server
27/9/16, 2:15:17.600 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server
27/9/16, 2:15:18.900 [NOTICE] Bootstrapped 15%: Establishing an encrypted directory connection
27/9/16, 2:15:19.100 [NOTICE] Bootstrapped 20%: Asking for networkstatus consensus
27/9/16, 2:15:19.500 [NOTICE] new bridge descriptor 'XXXXX' (fresh): XXXXXX at XXX.XXX.XXX.XXX
27/9/16, 2:15:19.500 [NOTICE] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
27/9/16, 2:15:20.100 [NOTICE] Bootstrapped 25%: Loading networkstatus consensus
27/9/16, 2:15:25.100 [NOTICE] Bootstrapped 80%: Connecting to the Tor network
27/9/16, 2:15:25.900 [NOTICE] Bootstrapped 90%: Establishing a Tor circuit
27/9/16, 2:15:26.900 [NOTICE] Tor has successfully opened a circuit. Looks like client functionality is working.
27/9/16, 2:15:26.900 [NOTICE] Bootstrapped 100%: Done
27/9/16, 2:15:28.100 [NOTICE] New control connection opened from 127.0.0.1.
27/9/16, 2:15:28.300 [NOTICE] New control connection opened from 127.0.0.1.
27/9/16, 2:19:34.900 [NOTICE] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
27/9/16, 2:19:34.900 [NOTICE] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
27/9/16, 2:19:34.900 [NOTICE] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
27/9/16, 2:19:34.900 [NOTICE] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
27/9/16, 2:19:34.900 [NOTICE] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
27/9/16, 2:19:34.900 [NOTICE] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
27/9/16, 2:21:27.900 [NOTICE] Tried for 120 seconds to get a connection to [scrubbed]:443. Giving up. (waiting for circuit)
27/9/16, 2:21:35.900 [NOTICE] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
27/9/16, 2:21:35.900 [NOTICE] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
27/9/16, 2:21:35.900 [NOTICE] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
27/9/16, 2:21:35.900 [NOTICE] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
27/9/16, 2:21:35.900 [NOTICE] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
27/9/16, 2:21:35.900 [NOTICE] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
27/9/16, 2:23:36.900 [NOTICE] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
27/9/16, 2:23:36.900 [NOTICE] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
27/9/16, 2:23:36.900 [NOTICE] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
27/9/16, 2:23:36.900 [NOTICE] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
27/9/16, 2:23:36.900 [NOTICE] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
27/9/16, 2:23:36.900 [NOTICE] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
**Trac**:
**Username**: metabaronhttps://gitlab.torproject.org/legacy/trac/-/issues/14211--data-dir argument is not properly recognized.2020-06-13T03:51:34ZTrac--data-dir argument is not properly recognized.Summing up the following command does not work:
```
bin/obfsproxy --log-file=obfsproxy.log --log-min-severity=debug \
scramblesuit --data-dir=/path/to/data --password=VERYREALPASSWORD \
--dest=172.31.9.199:1195 server 0.0.0.0:80
```
...Summing up the following command does not work:
```
bin/obfsproxy --log-file=obfsproxy.log --log-min-severity=debug \
scramblesuit --data-dir=/path/to/data --password=VERYREALPASSWORD \
--dest=172.31.9.199:1195 server 0.0.0.0:80
```
The `--data-dir` if not recognized as a parameter is invoked after the obfuscation protocol.
References:
https://lists.torproject.org/pipermail/tor-talk/2015-January/036461.html
https://lists.torproject.org/pipermail/tor-talk/2015-January/036463.html
**Trac**:
**Username**: masterkorphttps://gitlab.torproject.org/legacy/trac/-/issues/13040Get bananaphone merged in obfsproxy2020-06-13T03:28:36ZGeorge KadianakisGet bananaphone merged in obfsproxyLet's get this PT merged upstream!
David has already done most of the job:
https://bananaphone.readthedocs.org/en/latest/Let's get this PT merged upstream!
David has already done most of the job:
https://bananaphone.readthedocs.org/en/latest/https://gitlab.torproject.org/legacy/trac/-/issues/12879Obfsproxy has incorrect Error type2020-06-13T03:25:08ZTracObfsproxy has incorrect Error typeIn the socks.py file of obfsproxy there is a small bug with the csv reader.
in line 133: `except csvError, err:` should be `except csv.Error, err:`. csvError does not exist and I think its just missing the period.
**Trac**:
**Usernam...In the socks.py file of obfsproxy there is a small bug with the csv reader.
in line 133: `except csvError, err:` should be `except csv.Error, err:`. csvError does not exist and I think its just missing the period.
**Trac**:
**Username**: RushingWookiehttps://gitlab.torproject.org/legacy/trac/-/issues/12836scramblesuit: 'State' object has no attribute 'closingThreshold'2020-06-13T03:24:20ZGeorge Kadianakisscramblesuit: 'State' object has no attribute 'closingThreshold'Got this with on a bridge with `obfsproxy-0.2.11`:
```
[ERROR] Unhandled Error
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/Twisted-13.2.0-py2.7-linux-x86_64.egg/twisted/python/log.py", line 88, in ca...Got this with on a bridge with `obfsproxy-0.2.11`:
```
[ERROR] Unhandled Error
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/Twisted-13.2.0-py2.7-linux-x86_64.egg/twisted/python/log.py", line 88, in callWithLogger
return callWithContext({"system": lp}, func, *args, **kw)
File "/usr/local/lib/python2.7/dist-packages/Twisted-13.2.0-py2.7-linux-x86_64.egg/twisted/python/log.py", line 73, in callWithContext
return context.call({ILogContext: newCtx}, func, *args, **kw)
File "/usr/local/lib/python2.7/dist-packages/Twisted-13.2.0-py2.7-linux-x86_64.egg/twisted/python/context.py", line 118, in callWithContext
return self.currentContext().callWithContext(ctx, func, *args, **kw)
File "/usr/local/lib/python2.7/dist-packages/Twisted-13.2.0-py2.7-linux-x86_64.egg/twisted/python/context.py", line 81, in callWithContext
return func(*args,**kw)
--- <exception caught here> ---
File "/usr/local/lib/python2.7/dist-packages/Twisted-13.2.0-py2.7-linux-x86_64.egg/twisted/internet/posixbase.py", line 614, in _doReadOrWrite
why = selectable.doRead()
File "/usr/local/lib/python2.7/dist-packages/Twisted-13.2.0-py2.7-linux-x86_64.egg/twisted/internet/tcp.py", line 215, in doRead
return self._dataReceived(data)
File "/usr/local/lib/python2.7/dist-packages/Twisted-13.2.0-py2.7-linux-x86_64.egg/twisted/internet/tcp.py", line 221, in _dataReceived
rval = self.protocol.dataReceived(data)
File "/usr/local/lib/python2.7/dist-packages/obfsproxy-0.2.11-py2.7.egg/obfsproxy/network/network.py", line 320, in dataReceived
self.circuit.dataReceived(self.buffer, self)
File "/usr/local/lib/python2.7/dist-packages/obfsproxy-0.2.11-py2.7.egg/obfsproxy/network/network.py", line 161, in dataReceived
self.transport.receivedDownstream(data)
File "/usr/local/lib/python2.7/dist-packages/obfsproxy-0.2.11-py2.7.egg/obfsproxy/transports/scramblesuit/scramblesuit.py", line 495, in receivedDownstream
if self.drainedHandshake > self.srvState.closingThreshold:
exceptions.AttributeError: 'State' object has no attribute 'closingThreshold'
```https://gitlab.torproject.org/legacy/trac/-/issues/11355Provide obfsproxy nightlies in our debian repositories2020-06-13T03:03:10ZGeorge KadianakisProvide obfsproxy nightlies in our debian repositoriesPeople are asking for obfsproxy nightlies (#10954). It would be brilliant if people could add our debian repo, and get the latest obfsproxy master through it.
How can I help you do this?
No hurry on this one. I mainly made this ticket ...People are asking for obfsproxy nightlies (#10954). It would be brilliant if people could add our debian repo, and get the latest obfsproxy master through it.
How can I help you do this?
No hurry on this one. I mainly made this ticket because #10954 was not very specific.
Thanks!LunarLunarhttps://gitlab.torproject.org/legacy/trac/-/issues/11354Make obfsproxy more fork-friendly2020-06-13T03:07:31ZGeorge KadianakisMake obfsproxy more fork-friendlyPTs need to support a few PT interfaces. For example:
a) The managed-mode PT configuration protocol
b) SOCKS support (also support for proposal229)
c) Extended ORPort (and eventually TransportControlPort)
d) Proxy support to connect to p...PTs need to support a few PT interfaces. For example:
a) The managed-mode PT configuration protocol
b) SOCKS support (also support for proposal229)
c) Extended ORPort (and eventually TransportControlPort)
d) Proxy support to connect to proxies
pyptlib can help with (a), but does nothing about the other points (e.g. check #7903).
It has been suggested that instead of trying to fit those features in pyptlib, we instead implement them in obfsproxy, and suggest to people to use obfsproxy to developer their PTs.
However, it is the case that obfsproxy is optimized for the "app that supports multiple PTs" use case, and not for the "app that can be forked to support your PT".
If we get more people interested in writing PTs, it might make sense to start designing/fork obfsproxy with that use case in mind.https://gitlab.torproject.org/legacy/trac/-/issues/11203ScrambleSuit CSPRNG for Probability Distributions2020-06-13T03:00:09ZYawning AngelScrambleSuit CSPRNG for Probability DistributionsAs discussed in #10893, ScrambleSuit should use a CSPRNG when generating/sampling the probability distributions for the packet length and inter packet arrival times.
I have went ahead and implemented this in a branch at https://github.c...As discussed in #10893, ScrambleSuit should use a CSPRNG when generating/sampling the probability distributions for the packet length and inter packet arrival times.
I have went ahead and implemented this in a branch at https://github.com/yawning/obfsproxy/tree/ctr_drbg
It appears to work though packet distributions for existing bridges will change when they update to use the new PRNG (for obvious reasons). There also are some unit tests that use the NIST AES CTR test vectors to make sure that the bytes that are expected to come out with a given key/initial counter do.
phw said I should be doing development vs the scramblesuit repo, but since the plan is to fold the repo with history into obfsproxy, I did it the other way. If needed, I will move the ctr_drbg module into scramblesuit/transports and make a scramblesuit branch for this, but since it's not a critical thing, merging this can wait till after the repo madness is done.https://gitlab.torproject.org/legacy/trac/-/issues/11197obfsproxy should provide congestion feedback2020-06-13T02:59:59ZYawning Angelobfsproxy should provide congestion feedbackI went over this in IRC tonight to a poor GSOC student who was thinking about doing a CBR plugin, so I'll file a bug while it's fresh on my mind.
Currently there is nothing in place to prevent unbound buffer growth in obfsproxy. This p...I went over this in IRC tonight to a poor GSOC student who was thinking about doing a CBR plugin, so I'll file a bug while it's fresh on my mind.
Currently there is nothing in place to prevent unbound buffer growth in obfsproxy. This problem arises when the bottleneck link is extremely narrow.
For example, examine the following network topology:
Client <-> obfsproxy <-> 14.4 kbit modem <-> ISP <-> 100 Mbit <-> obfsproxy <-> Server
The Client opens a connection, and initiates a bulk download from the Server. Since there is no mechanism to indicate congestion, the outgoing buffer in the Server side obfsproxy process will grow because feedback from the Client in the form of the shrinking TCP/IP receive window will not get propagated.
The same thing will happen on the Client side with a bulk upload, because the loopback interface has a gigantic amount of bandwidth compared to the bottleneck link.
Twisted connections have a producer/consumer interface (and can handle stopping reading once the send buffer reaches a certain threshold 'self.bufferSize'), so refactoring the base transport to use this interface to glue the upstream/downstream together would be the "correct" approach to solving this problem.
See https://twistedmatrix.com/documents/current/core/howto/producers.html for more details.https://gitlab.torproject.org/legacy/trac/-/issues/11190obfsproxy shebang should point to "python2", not "python"2020-06-13T02:59:48ZYawning Angelobfsproxy shebang should point to "python2", not "python"It currently points at "python" which is not version specific and will break horribly on systems where the default system python is python3.
This isn't a issue when it is installed with setup.py, but was when I tried a TBB nightly a few...It currently points at "python" which is not version specific and will break horribly on systems where the default system python is python3.
This isn't a issue when it is installed with setup.py, but was when I tried a TBB nightly a few days ago. As far as I can tell every system that has python2.x installed with have a "python2" symlink so changing the shebang won't break places where this works now, but will allow it to work on more systems without breaking in horrible unintuitive ways for the user.https://gitlab.torproject.org/legacy/trac/-/issues/11134obfsproxy's SOCKS server should send success response post handshake2020-06-13T14:34:35ZYawning Angelobfsproxy's SOCKS server should send success response post handshakeCurrently the obfsproxy SOCKS server sends the response back to tor immediately after the TCP/IP connection has been established, instead of after the underlying transport has been fully initialized.
This behavior is incorrect, and shou...Currently the obfsproxy SOCKS server sends the response back to tor immediately after the TCP/IP connection has been established, instead of after the underlying transport has been fully initialized.
This behavior is incorrect, and should be changed to each of the underlying transports signalling that they are ready to relay data after they manage to handshake.
With the current SOCKSv4Protocol based listener this would require further monkey patching which may be a good argument for defering this till after #9221 or similar gets merged.https://gitlab.torproject.org/legacy/trac/-/issues/11093obfsproxy should use C implementation of UniformDH2020-06-13T02:57:56ZGeorge Kadianakisobfsproxy should use C implementation of UniformDHWe are currently using a C implementation of UniformDH that is quite slow (even with gmpy2 for mod exp).
Yawning implemented UniformDH in C using OpenSSL and we should use his library.
He posted an obfsproxy patch in #11015 :
https://t...We are currently using a C implementation of UniformDH that is quite slow (even with gmpy2 for mod exp).
Yawning implemented UniformDH in C using OpenSSL and we should use his library.
He posted an obfsproxy patch in #11015 :
https://trac.torproject.org/projects/tor/attachment/ticket/11015/0001-Add-support-for-using-py-uniformdh.patch
And the implementation can be found in:
https://github.com/Yawning/py-uniformdhhttps://gitlab.torproject.org/legacy/trac/-/issues/11050pycrypto's AES implementation is not constant time2020-06-13T02:57:18ZYawning Angelpycrypto's AES implementation is not constant timeThis is a non-issue when AES-NI is supported by the host CPU since a separate code path is taken.
https://github.com/dlitz/pycrypto/blob/master/src/AES.c
It's not too bad in the pluggable transport case since traffic is super-enciphere...This is a non-issue when AES-NI is supported by the host CPU since a separate code path is taken.
https://github.com/dlitz/pycrypto/blob/master/src/AES.c
It's not too bad in the pluggable transport case since traffic is super-enciphered, the session keys are ephemeral, and actually extracting sufficiently accurate timing information is probably non-trivial, but it probably should be addressed somehow.https://gitlab.torproject.org/legacy/trac/-/issues/10782Improve the spec of UniformDH2020-06-13T02:52:23ZGeorge KadianakisImprove the spec of UniformDHUniformDH is used by obfs3 and scramblesuit currently, and it might get used by more projects in the future. Yawning suggested to improve its spec to make its adoption easier.
Yawning suggested adding test vectors. We can look at test v...UniformDH is used by obfs3 and scramblesuit currently, and it might get used by more projects in the future. Yawning suggested to improve its spec to make its adoption easier.
Yawning suggested adding test vectors. We can look at test vectors of other key exchange protocols to see how they should look like. Example:
https://tools.ietf.org/html/rfc6932#appendix-A.1
Some more suggestions:
```
14:54 < Yawning> *looks at the list of gotchas*
14:54 < Yawning> spec should clarify that 0s are inserted if the public key is shorter than 1536 bits (probably obvious)
14:55 < Yawning> Should clarify that abs(p - X) is sent (99% sure that's what happens)
14:55 < Yawning> spec says to simply raise the public key, when it's another mod exp operation
14:56 < Yawning> apart from "wtb test vectors" those where the things i found
15:00 < Yawning> I also was sort of sad that MAX_PADDING isn't a power of 2, but probably too late to change that and that might have been deliberate
```https://gitlab.torproject.org/legacy/trac/-/issues/10371Obfsproxy memory leak2020-06-13T02:44:12ZTracObfsproxy memory leakHi everyone,
I have installed Obfsproxy from Tor project Debian and Python repositories (one v0.2.3 and the other v0.2.4) on my Ubuntu 12.04 LTS. Unfortunately both of them has memory leak problem and if too many users start using the s...Hi everyone,
I have installed Obfsproxy from Tor project Debian and Python repositories (one v0.2.3 and the other v0.2.4) on my Ubuntu 12.04 LTS. Unfortunately both of them has memory leak problem and if too many users start using the server, it makes the RAM full and crashes by itself. How can I generate a full report from this memory leak and place it here to help developers fix the issue?
Thanks.
**Trac**:
**Username**: taher12112https://gitlab.torproject.org/legacy/trac/-/issues/10134Create bananaphone transport for obfsproxy2020-06-13T02:39:45ZGeorge KadianakisCreate bananaphone transport for obfsproxydavid415 has started writing an obfsproxy module for bananaphone.
Code can be found here:
https://github.com/david415/obfsproxy
Discussion thread:
https://lists.torproject.org/pipermail/tor-dev/2013-November/005737.htmldavid415 has started writing an obfsproxy module for bananaphone.
Code can be found here:
https://github.com/david415/obfsproxy
Discussion thread:
https://lists.torproject.org/pipermail/tor-dev/2013-November/005737.htmlhttps://gitlab.torproject.org/legacy/trac/-/issues/9902need separate Obfsproxy Windows binary2020-06-13T02:34:55ZTracneed separate Obfsproxy Windows binaryI am using Tor Expert Bundle in Windows. Adding obfs2/obfs3 bridges to torrc always get warnings like this:
```
[warn] We were supposed to connect to bridge 'xxx.xxx.xxx.xxx:xxxxx' using pluggable transport 'obfs2', but we can't find a ...I am using Tor Expert Bundle in Windows. Adding obfs2/obfs3 bridges to torrc always get warnings like this:
```
[warn] We were supposed to connect to bridge 'xxx.xxx.xxx.xxx:xxxxx' using pluggable transport 'obfs2', but we can't find a pluggable transport proxy supporting 'obfs2'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
```
Tor Expert Bundle does not include any pluggable, and as far as I know, obfsproxy does not provide separate binary neither, except the the whole big Tor Browser bundle. I would like keeping use "lightweight" Tor Expert Bundle with obfs support. Could you please provide separate Obfsproxy for Windows?
Thanks.
**Trac**:
**Username**: mosesofmasonhttps://gitlab.torproject.org/legacy/trac/-/issues/9825-v returns 'unknown' for Obfsproxy.exe from '2.4.17-beta-2-pt3'2020-06-13T02:33:00Zbastik-v returns 'unknown' for Obfsproxy.exe from '2.4.17-beta-2-pt3'> obfsproxy.exe -v
prints out
> unknown
It was included in 'tor-pluggable-transports-browser-2.4.17-beta-2-pt3_en-US.exe' and its (obfsproxy.exe) checksums are:
```
SHA-1: 8690778C86542ABC3596C65EF42903E943C843A9
SHA-256: F75A997308B6...> obfsproxy.exe -v
prints out
> unknown
It was included in 'tor-pluggable-transports-browser-2.4.17-beta-2-pt3_en-US.exe' and its (obfsproxy.exe) checksums are:
```
SHA-1: 8690778C86542ABC3596C65EF42903E943C843A9
SHA-256: F75A997308B689335AEA9705BF7DF57EEA0636CB7C2EB7D75BCAC41389F0F84F
SHA-512: 89459D5189C2490C22FA63AC8509AEF8B7902B38174C73BB2902C57F73DFAFC4EC42B1C361ADDBEB019D7709882589594D94FD264FD20A2712592326596B1107
```https://gitlab.torproject.org/legacy/trac/-/issues/7532Count unique IPs in an anonymous way2020-06-13T04:05:38ZGeorge KadianakisCount unique IPs in an anonymous wayCurrently, pyobfsproxy (and obfsproxy) keep a list of IPs (or IP hashes) in memory to count connected unique IPs.
Velope suggested that we should find a more privacy-preserving way of counting unique IPs, and he is right.
Aaron suggest...Currently, pyobfsproxy (and obfsproxy) keep a list of IPs (or IP hashes) in memory to count connected unique IPs.
Velope suggested that we should find a more privacy-preserving way of counting unique IPs, and he is right.
Aaron suggested to look into https://git.eff.org/?p=cryptolog.git
and nick suggested to "use a bloom filter; count bits; get a probabilistic answer".Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/6264obfsproxy: Add support for dropping privileges and chrooting2020-06-13T01:19:12ZTracobfsproxy: Add support for dropping privileges and chrooting```
[PATCH 1/2] Make obfsproxy drop privileges if requested
Added --user and --group arguments which will make obfsproxy drop privileges
and switch to the given user/group.
The code for droping privileges is shamelessly taken from the ...```
[PATCH 1/2] Make obfsproxy drop privileges if requested
Added --user and --group arguments which will make obfsproxy drop privileges
and switch to the given user/group.
The code for droping privileges is shamelessly taken from the Tor project and
adopted to obfsproxy. The switch_id() function in src/common/compat.c was used.
Signed-off-by: David Sommerseth <dazo@users.sourceforge.net>
---
configure.ac | 3 +
src/external.c | 16 +++++++-
src/main.c | 120 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
src/managed.c | 10 +++++
4 files changed, 147 insertions(+), 2 deletions(-)
[PATCH 2/2] Added support for chrooting obfsproxy
This patch adds --chroot=<dir> which will chroot the process as soon
as possible.
For more info about chrooting, see this URL:
<http://www.unixwiz.net/techtips/chroot-practices.html>
Signed-off-by: David Sommerseth <dazo@users.sourceforge.net>
---
src/main.c | 27 +++++++++++++++++++++++++--
1 files changed, 25 insertions(+), 2 deletions(-)
```
**Trac**:
**Username**: dazo