[tor-commits] [torsocks/master] Move man pages and configuration files to docs folder
hoganrobert at torproject.org
hoganrobert at torproject.org
Sun Feb 27 12:56:17 UTC 2011
commit ac681d8428a08d030ab3ab4608eddf9529159f6e
Author: Robert Hogan <robert at roberthogan.net>
Date: Sun Feb 27 12:39:21 2011 +0000
Move man pages and configuration files to docs folder
---
Makefile.am | 2 +-
configure.in | 4 +-
doc/SOCKS4.protocol | 150 ---------------------------
doc/SOCKS5 | 2 -
doc/socks-extensions.txt | 79 --------------
doc/socks/SOCKS4.protocol | 150 +++++++++++++++++++++++++++
doc/socks/SOCKS5 | 2 +
doc/socks/socks-extensions.txt | 79 ++++++++++++++
doc/torsocks.1.in | 63 ++++++++++++
doc/torsocks.8.in | 189 ++++++++++++++++++++++++++++++++++
doc/torsocks.conf | 56 ++++++++++
doc/torsocks.conf.5.in | 214 +++++++++++++++++++++++++++++++++++++++
doc/tsocks.conf.complex.example | 47 +++++++++
doc/tsocks.conf.simple.example | 16 +++
doc/usewithtor.1.in | 57 ++++++++++
src/Makefile.am | 17 ---
src/torsocks.1.in | 63 ------------
src/torsocks.8.in | 189 ----------------------------------
src/torsocks.conf | 56 ----------
src/torsocks.conf.5.in | 214 ---------------------------------------
src/tsocks.conf.complex.example | 47 ---------
src/tsocks.conf.simple.example | 16 ---
src/usewithtor.1.in | 57 ----------
23 files changed, 876 insertions(+), 893 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 44a7fbd..0ef8147 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2,4 +2,4 @@
# have all needed files, that a GNU package needs
AUTOMAKE_OPTIONS = foreign 1.4
-SUBDIRS = src test
+SUBDIRS = src doc test
diff --git a/configure.in b/configure.in
index f74a3fd..a89fa0e 100644
--- a/configure.in
+++ b/configure.in
@@ -634,10 +634,10 @@ AC_SUBST(LIBTOOL_DEPS)
AC_ENABLE_SHARED
AC_ENABLE_STATIC
-AC_CONFIG_FILES([src/usewithtor src/torsocks src/torsocks.conf.5 src/torsocks.8 src/usewithtor.1 src/torsocks.1])
+AC_CONFIG_FILES([src/usewithtor src/torsocks doc/torsocks.conf.5 doc/torsocks.8 doc/usewithtor.1 doc/torsocks.1])
dnl Output the Makefile for libtorsocks
-AC_OUTPUT(Makefile src/Makefile)
+AC_OUTPUT(Makefile src/Makefile doc/Makefile)
dnl Output the Makefile for test/test_torsocks.
dnl Dump any LDFLAGS that were only required for linking libtorsocks, such as -dynamiclib on OSX.
diff --git a/doc/SOCKS4.protocol b/doc/SOCKS4.protocol
deleted file mode 100644
index 50fa5a7..0000000
--- a/doc/SOCKS4.protocol
+++ /dev/null
@@ -1,150 +0,0 @@
- SOCKS: A protocol for TCP proxy across firewalls
-
- Ying-Da Lee
- yingda at best.com or yingda at esd.sgi.com
-
-SOCKS was originally developed by David Koblas and subsequently modified
-and extended by me to its current running version -- version 4. It is a
-protocol that relays TCP sessions at a firewall host to allow application
-users transparent access across the firewall. Because the protocol is
-independent of application protocols, it can be (and has been) used for
-many different services, such as telnet, ftp, finger, whois, gopher, WWW,
-etc. Access control can be applied at the beginning of each TCP session;
-thereafter the server simply relays the data between the client and the
-application server, incurring minimum processing overhead. Since SOCKS
-never has to know anything about the application protocol, it should also
-be easy for it to accommodate applications which use encryption to protect
-their traffic from nosey snoopers.
-
-Two operations are defined: CONNECT and BIND.
-
-1) CONNECT
-
-The client connects to the SOCKS server and sends a CONNECT request when
-it wants to establish a connection to an application server. The client
-includes in the request packet the IP address and the port number of the
-destination host, and userid, in the following format.
-
- +----+----+----+----+----+----+----+----+----+----+....+----+
- | VN | CD | DSTPORT | DSTIP | USERID |NULL|
- +----+----+----+----+----+----+----+----+----+----+....+----+
- # of bytes: 1 1 2 4 variable 1
-
-VN is the SOCKS protocol version number and should be 4. CD is the
-SOCKS command code and should be 1 for CONNECT request. NULL is a byte
-of all zero bits.
-
-The SOCKS server checks to see whether such a request should be granted
-based on any combination of source IP address, destination IP address,
-destination port number, the userid, and information it may obtain by
-consulting IDENT, cf. RFC 1413. If the request is granted, the SOCKS
-server makes a connection to the specified port of the destination host.
-A reply packet is sent to the client when this connection is established,
-or when the request is rejected or the operation fails.
-
- +----+----+----+----+----+----+----+----+
- | VN | CD | DSTPORT | DSTIP |
- +----+----+----+----+----+----+----+----+
- # of bytes: 1 1 2 4
-
-VN is the version of the reply code and should be 0. CD is the result
-code with one of the following values:
-
- 90: request granted
- 91: request rejected or failed
- 92: request rejected becasue SOCKS server cannot connect to
- identd on the client
- 93: request rejected because the client program and identd
- report different user-ids
-
-The remaining fields are ignored.
-
-The SOCKS server closes its connection immediately after notifying
-the client of a failed or rejected request. For a successful request,
-the SOCKS server gets ready to relay traffic on both directions. This
-enables the client to do I/O on its connection as if it were directly
-connected to the application server.
-
-
-2) BIND
-
-The client connects to the SOCKS server and sends a BIND request when
-it wants to prepare for an inbound connection from an application server.
-This should only happen after a primary connection to the application
-server has been established with a CONNECT. Typically, this is part of
-the sequence of actions:
-
--bind(): obtain a socket
--getsockname(): get the IP address and port number of the socket
--listen(): ready to accept call from the application server
--use the primary connection to inform the application server of
- the IP address and the port number that it should connect to.
--accept(): accept a connection from the application server
-
-The purpose of SOCKS BIND operation is to support such a sequence
-but using a socket on the SOCKS server rather than on the client.
-
-The client includes in the request packet the IP address of the
-application server, the destination port used in the primary connection,
-and the userid.
-
- +----+----+----+----+----+----+----+----+----+----+....+----+
- | VN | CD | DSTPORT | DSTIP | USERID |NULL|
- +----+----+----+----+----+----+----+----+----+----+....+----+
- # of bytes: 1 1 2 4 variable 1
-
-VN is again 4 for the SOCKS protocol version number. CD must be 2 to
-indicate BIND request.
-
-The SOCKS server uses the client information to decide whether the
-request is to be granted. The reply it sends back to the client has
-the same format as the reply for CONNECT request, i.e.,
-
- +----+----+----+----+----+----+----+----+
- | VN | CD | DSTPORT | DSTIP |
- +----+----+----+----+----+----+----+----+
- # of bytes: 1 1 2 4
-
-VN is the version of the reply code and should be 0. CD is the result
-code with one of the following values:
-
- 90: request granted
- 91: request rejected or failed
- 92: request rejected becasue SOCKS server cannot connect to
- identd on the client
- 93: request rejected because the client program and identd
- report different user-ids.
-
-However, for a granted request (CD is 90), the DSTPORT and DSTIP fields
-are meaningful. In that case, the SOCKS server obtains a socket to wait
-for an incoming connection and sends the port number and the IP address
-of that socket to the client in DSTPORT and DSTIP, respectively. If the
-DSTIP in the reply is 0 (the value of constant INADDR_ANY), then the
-client should replace it with the IP address of the SOCKS server to which
-the cleint is connected. (This happens if the SOCKS server is not a
-multi-homed host.) In the typical scenario, these two numbers are
-made available to the application client prgram via the result of the
-subsequent getsockname() call. The application protocol must provide a
-way for these two pieces of information to be sent from the client to
-the application server so that it can initiate the connection, which
-connects it to the SOCKS server rather than directly to the application
-client as it normally would.
-
-The SOCKS server sends a second reply packet to the client when the
-anticipated connection from the application server is established.
-The SOCKS server checks the IP address of the originating host against
-the value of DSTIP specified in the client's BIND request. If a mismatch
-is found, the CD field in the second reply is set to 91 and the SOCKS
-server closes both connections. If the two match, CD in the second
-reply is set to 90 and the SOCKS server gets ready to relay the traffic
-on its two connections. From then on the client does I/O on its connection
-to the SOCKS server as if it were directly connected to the application
-server.
-
-
-
-For both CONNECT and BIND operations, the server sets a time limit
-(2 minutes in current CSTC implementation) for the establishment of its
-connection with the application server. If the connection is still not
-establiched when the time limit expires, the server closes its connection
-to the client and gives up.
diff --git a/doc/SOCKS5 b/doc/SOCKS5
deleted file mode 100644
index 40dfcbd..0000000
--- a/doc/SOCKS5
+++ /dev/null
@@ -1,2 +0,0 @@
-http://www.ietf.org/rfc/rfc1928.txt
-
diff --git a/doc/socks-extensions.txt b/doc/socks-extensions.txt
deleted file mode 100644
index 99e2b51..0000000
--- a/doc/socks-extensions.txt
+++ /dev/null
@@ -1,79 +0,0 @@
-$Id: socks-extensions.txt,v 1.1 2008-06-18 21:17:02 hoganrobert Exp $
-Tor's extensions to the SOCKS protocol
-
-1. Overview
-
- The SOCKS protocol provides a generic interface for TCP proxies. Client
- software connects to a SOCKS server via TCP, and requests a TCP connection
- to another address and port. The SOCKS server establishes the connection,
- and reports success or failure to the client. After the connection has
- been established, the client application uses the TCP stream as usual.
-
- Tor supports SOCKS4 as defined in [1], SOCKS4A as defined in [2], and
- SOCKS5 as defined in [3].
-
- The stickiest issue for Tor in supporting clients, in practice, is forcing
- DNS lookups to occur at the OR side: if clients do their own DNS lookup,
- the DNS server can learn which addresses the client wants to reach.
- SOCKS4 supports addressing by IPv4 address; SOCKS4A is a kludge on top of
- SOCKS4 to allow addressing by hostname; SOCKS5 supports IPv4, IPv6, and
- hostnames.
-
-1.1. Extent of support
-
- Tor supports the SOCKS4, SOCKS4A, and SOCKS5 standards, except as follows:
-
- BOTH:
- - The BIND command is not supported.
-
- SOCKS4,4A:
- - SOCKS4 usernames are ignored.
-
- SOCKS5:
- - The (SOCKS5) "UDP ASSOCIATE" command is not supported.
- - IPv6 is not supported in CONNECT commands.
- - Only the "NO AUTHENTICATION" (SOCKS5) authentication method [00] is
- supported.
-
-2. Name lookup
-
- As an extension to SOCKS4A and SOCKS5, Tor implements a new command value,
- "RESOLVE" [F0]. When Tor receives a "RESOLVE" SOCKS command, it initiates
- a remote lookup of the hostname provided as the target address in the SOCKS
- request. The reply is either an error (if the address couldn't be
- resolved) or a success response. In the case of success, the address is
- stored in the portion of the SOCKS response reserved for remote IP address.
-
- (We support RESOLVE in SOCKS4 too, even though it is unnecessary.)
-
- For SOCKS5 only, we support reverse resolution with a new command value,
- "RESOLVE_PTR" [F1]. In response to a "RESOLVE_PTR" SOCKS5 command with
- an IPv4 address as its target, Tor attempts to find the canonical
- hostname for that IPv4 record, and returns it in the "server bound
- address" portion of the reply.
- (This command was not supported before Tor 0.1.2.2-alpha.)
-
-3. Other command extensions.
-
- Tor 0.1.2.4-alpha added a new command value: "CONNECT_DIR" [F2].
- In this case, Tor will open an encrypted direct TCP connection to the
- directory port of the Tor server specified by address:port (the port
- specified should be the ORPort of the server). It uses a one-hop tunnel
- and a "BEGIN_DIR" relay cell to accomplish this secure connection.
-
- The F2 command value was removed in Tor 0.2.0.10-alpha in favor of a
- new use_begindir flag in edge_connection_t.
-
-4. HTTP-resistance
-
- Tor checks the first byte of each SOCKS request to see whether it looks
- more like an HTTP request (that is, it starts with a "G", "H", or "P"). If
- so, Tor returns a small webpage, telling the user that his/her browser is
- misconfigured. This is helpful for the many users who mistakenly try to
- use Tor as an HTTP proxy instead of a SOCKS proxy.
-
-References:
- [1] http://archive.socks.permeo.com/protocol/socks4.protocol
- [2] http://archive.socks.permeo.com/protocol/socks4a.protocol
- [3] SOCKS5: RFC1928
-
diff --git a/doc/socks/SOCKS4.protocol b/doc/socks/SOCKS4.protocol
new file mode 100644
index 0000000..50fa5a7
--- /dev/null
+++ b/doc/socks/SOCKS4.protocol
@@ -0,0 +1,150 @@
+ SOCKS: A protocol for TCP proxy across firewalls
+
+ Ying-Da Lee
+ yingda at best.com or yingda at esd.sgi.com
+
+SOCKS was originally developed by David Koblas and subsequently modified
+and extended by me to its current running version -- version 4. It is a
+protocol that relays TCP sessions at a firewall host to allow application
+users transparent access across the firewall. Because the protocol is
+independent of application protocols, it can be (and has been) used for
+many different services, such as telnet, ftp, finger, whois, gopher, WWW,
+etc. Access control can be applied at the beginning of each TCP session;
+thereafter the server simply relays the data between the client and the
+application server, incurring minimum processing overhead. Since SOCKS
+never has to know anything about the application protocol, it should also
+be easy for it to accommodate applications which use encryption to protect
+their traffic from nosey snoopers.
+
+Two operations are defined: CONNECT and BIND.
+
+1) CONNECT
+
+The client connects to the SOCKS server and sends a CONNECT request when
+it wants to establish a connection to an application server. The client
+includes in the request packet the IP address and the port number of the
+destination host, and userid, in the following format.
+
+ +----+----+----+----+----+----+----+----+----+----+....+----+
+ | VN | CD | DSTPORT | DSTIP | USERID |NULL|
+ +----+----+----+----+----+----+----+----+----+----+....+----+
+ # of bytes: 1 1 2 4 variable 1
+
+VN is the SOCKS protocol version number and should be 4. CD is the
+SOCKS command code and should be 1 for CONNECT request. NULL is a byte
+of all zero bits.
+
+The SOCKS server checks to see whether such a request should be granted
+based on any combination of source IP address, destination IP address,
+destination port number, the userid, and information it may obtain by
+consulting IDENT, cf. RFC 1413. If the request is granted, the SOCKS
+server makes a connection to the specified port of the destination host.
+A reply packet is sent to the client when this connection is established,
+or when the request is rejected or the operation fails.
+
+ +----+----+----+----+----+----+----+----+
+ | VN | CD | DSTPORT | DSTIP |
+ +----+----+----+----+----+----+----+----+
+ # of bytes: 1 1 2 4
+
+VN is the version of the reply code and should be 0. CD is the result
+code with one of the following values:
+
+ 90: request granted
+ 91: request rejected or failed
+ 92: request rejected becasue SOCKS server cannot connect to
+ identd on the client
+ 93: request rejected because the client program and identd
+ report different user-ids
+
+The remaining fields are ignored.
+
+The SOCKS server closes its connection immediately after notifying
+the client of a failed or rejected request. For a successful request,
+the SOCKS server gets ready to relay traffic on both directions. This
+enables the client to do I/O on its connection as if it were directly
+connected to the application server.
+
+
+2) BIND
+
+The client connects to the SOCKS server and sends a BIND request when
+it wants to prepare for an inbound connection from an application server.
+This should only happen after a primary connection to the application
+server has been established with a CONNECT. Typically, this is part of
+the sequence of actions:
+
+-bind(): obtain a socket
+-getsockname(): get the IP address and port number of the socket
+-listen(): ready to accept call from the application server
+-use the primary connection to inform the application server of
+ the IP address and the port number that it should connect to.
+-accept(): accept a connection from the application server
+
+The purpose of SOCKS BIND operation is to support such a sequence
+but using a socket on the SOCKS server rather than on the client.
+
+The client includes in the request packet the IP address of the
+application server, the destination port used in the primary connection,
+and the userid.
+
+ +----+----+----+----+----+----+----+----+----+----+....+----+
+ | VN | CD | DSTPORT | DSTIP | USERID |NULL|
+ +----+----+----+----+----+----+----+----+----+----+....+----+
+ # of bytes: 1 1 2 4 variable 1
+
+VN is again 4 for the SOCKS protocol version number. CD must be 2 to
+indicate BIND request.
+
+The SOCKS server uses the client information to decide whether the
+request is to be granted. The reply it sends back to the client has
+the same format as the reply for CONNECT request, i.e.,
+
+ +----+----+----+----+----+----+----+----+
+ | VN | CD | DSTPORT | DSTIP |
+ +----+----+----+----+----+----+----+----+
+ # of bytes: 1 1 2 4
+
+VN is the version of the reply code and should be 0. CD is the result
+code with one of the following values:
+
+ 90: request granted
+ 91: request rejected or failed
+ 92: request rejected becasue SOCKS server cannot connect to
+ identd on the client
+ 93: request rejected because the client program and identd
+ report different user-ids.
+
+However, for a granted request (CD is 90), the DSTPORT and DSTIP fields
+are meaningful. In that case, the SOCKS server obtains a socket to wait
+for an incoming connection and sends the port number and the IP address
+of that socket to the client in DSTPORT and DSTIP, respectively. If the
+DSTIP in the reply is 0 (the value of constant INADDR_ANY), then the
+client should replace it with the IP address of the SOCKS server to which
+the cleint is connected. (This happens if the SOCKS server is not a
+multi-homed host.) In the typical scenario, these two numbers are
+made available to the application client prgram via the result of the
+subsequent getsockname() call. The application protocol must provide a
+way for these two pieces of information to be sent from the client to
+the application server so that it can initiate the connection, which
+connects it to the SOCKS server rather than directly to the application
+client as it normally would.
+
+The SOCKS server sends a second reply packet to the client when the
+anticipated connection from the application server is established.
+The SOCKS server checks the IP address of the originating host against
+the value of DSTIP specified in the client's BIND request. If a mismatch
+is found, the CD field in the second reply is set to 91 and the SOCKS
+server closes both connections. If the two match, CD in the second
+reply is set to 90 and the SOCKS server gets ready to relay the traffic
+on its two connections. From then on the client does I/O on its connection
+to the SOCKS server as if it were directly connected to the application
+server.
+
+
+
+For both CONNECT and BIND operations, the server sets a time limit
+(2 minutes in current CSTC implementation) for the establishment of its
+connection with the application server. If the connection is still not
+establiched when the time limit expires, the server closes its connection
+to the client and gives up.
diff --git a/doc/socks/SOCKS5 b/doc/socks/SOCKS5
new file mode 100644
index 0000000..40dfcbd
--- /dev/null
+++ b/doc/socks/SOCKS5
@@ -0,0 +1,2 @@
+http://www.ietf.org/rfc/rfc1928.txt
+
diff --git a/doc/socks/socks-extensions.txt b/doc/socks/socks-extensions.txt
new file mode 100644
index 0000000..99e2b51
--- /dev/null
+++ b/doc/socks/socks-extensions.txt
@@ -0,0 +1,79 @@
+$Id: socks-extensions.txt,v 1.1 2008-06-18 21:17:02 hoganrobert Exp $
+Tor's extensions to the SOCKS protocol
+
+1. Overview
+
+ The SOCKS protocol provides a generic interface for TCP proxies. Client
+ software connects to a SOCKS server via TCP, and requests a TCP connection
+ to another address and port. The SOCKS server establishes the connection,
+ and reports success or failure to the client. After the connection has
+ been established, the client application uses the TCP stream as usual.
+
+ Tor supports SOCKS4 as defined in [1], SOCKS4A as defined in [2], and
+ SOCKS5 as defined in [3].
+
+ The stickiest issue for Tor in supporting clients, in practice, is forcing
+ DNS lookups to occur at the OR side: if clients do their own DNS lookup,
+ the DNS server can learn which addresses the client wants to reach.
+ SOCKS4 supports addressing by IPv4 address; SOCKS4A is a kludge on top of
+ SOCKS4 to allow addressing by hostname; SOCKS5 supports IPv4, IPv6, and
+ hostnames.
+
+1.1. Extent of support
+
+ Tor supports the SOCKS4, SOCKS4A, and SOCKS5 standards, except as follows:
+
+ BOTH:
+ - The BIND command is not supported.
+
+ SOCKS4,4A:
+ - SOCKS4 usernames are ignored.
+
+ SOCKS5:
+ - The (SOCKS5) "UDP ASSOCIATE" command is not supported.
+ - IPv6 is not supported in CONNECT commands.
+ - Only the "NO AUTHENTICATION" (SOCKS5) authentication method [00] is
+ supported.
+
+2. Name lookup
+
+ As an extension to SOCKS4A and SOCKS5, Tor implements a new command value,
+ "RESOLVE" [F0]. When Tor receives a "RESOLVE" SOCKS command, it initiates
+ a remote lookup of the hostname provided as the target address in the SOCKS
+ request. The reply is either an error (if the address couldn't be
+ resolved) or a success response. In the case of success, the address is
+ stored in the portion of the SOCKS response reserved for remote IP address.
+
+ (We support RESOLVE in SOCKS4 too, even though it is unnecessary.)
+
+ For SOCKS5 only, we support reverse resolution with a new command value,
+ "RESOLVE_PTR" [F1]. In response to a "RESOLVE_PTR" SOCKS5 command with
+ an IPv4 address as its target, Tor attempts to find the canonical
+ hostname for that IPv4 record, and returns it in the "server bound
+ address" portion of the reply.
+ (This command was not supported before Tor 0.1.2.2-alpha.)
+
+3. Other command extensions.
+
+ Tor 0.1.2.4-alpha added a new command value: "CONNECT_DIR" [F2].
+ In this case, Tor will open an encrypted direct TCP connection to the
+ directory port of the Tor server specified by address:port (the port
+ specified should be the ORPort of the server). It uses a one-hop tunnel
+ and a "BEGIN_DIR" relay cell to accomplish this secure connection.
+
+ The F2 command value was removed in Tor 0.2.0.10-alpha in favor of a
+ new use_begindir flag in edge_connection_t.
+
+4. HTTP-resistance
+
+ Tor checks the first byte of each SOCKS request to see whether it looks
+ more like an HTTP request (that is, it starts with a "G", "H", or "P"). If
+ so, Tor returns a small webpage, telling the user that his/her browser is
+ misconfigured. This is helpful for the many users who mistakenly try to
+ use Tor as an HTTP proxy instead of a SOCKS proxy.
+
+References:
+ [1] http://archive.socks.permeo.com/protocol/socks4.protocol
+ [2] http://archive.socks.permeo.com/protocol/socks4a.protocol
+ [3] SOCKS5: RFC1928
+
diff --git a/doc/torsocks.1.in b/doc/torsocks.1.in
new file mode 100644
index 0000000..b383859
--- /dev/null
+++ b/doc/torsocks.1.in
@@ -0,0 +1,63 @@
+.TH TORSOCKS 1 "" "TORSOCKS"
+
+.SH NAME
+.BR torsocks
+\- Shell wrapper to simplify the use of the torsocks(8) library to
+transparently allow an application to use a SOCKS proxy. Basically a renamed, patched tsocks.
+.SH SYNOPSIS
+.B torsocks
+.RB [application\ [application's\ arguments]]
+.br
+or
+.B torsocks
+.RB [on|off]
+.br
+or
+.B torsocks
+.SH DESCRIPTION
+.B torsocks
+is a wrapper between the torsocks library and the application what you
+would like to run socksified.
+.SH SUMMARY
+
+By default, torsocks will assume that it should connect to the SOCKS proxy
+running at 127.0.0.1 on port 9050. This is the default address and port for
+Tor's socks server on most installations.
+
+In order to use a configuration file, you must set the environment variable
+TORSOCKS_CONF_FILE with the location of the file.
+
+If TORSOCKS_CONF_FILE is not set, torsocks will attempt to read the configuration
+file at @CONFDIR@/torsocks.conf. If that file cannot be read, torsocks will
+use sensible defaults for most Tor installations, i.e. it will assume that
+you want to use a SOCKS proxy running at 127.0.0.1 (localhost) on port 9050.
+
+For further information on configuration, see
+.B torsocks.conf(5).
+
+.SH OPTIONS
+.IP \fB[application\ \fB[application's\ arguments]]
+run the application as specified with the environment (LD_PRELOAD) set
+such that torsocks(8) will transparently proxy SOCKS connections in
+that program
+.IP \fB[on|off]
+this option adds or removes torsocks(8) from the LD_PRELOAD environment
+variable. When torsocks(8) is in this variable all executed
+applications are automatically socksified. If you want to
+use this function, you HAVE to source the shell script from yours,
+like this: "source /usr/bin/torsocks" or ". /usr/bin/torsocks"
+.br
+Example:
+.br
+". torsocks on" -- add the torsocks lib to LD_PRELOAD
+.br
+". torsocks off" -- remove the torsocks lib from LD_PRELOAD
+.IP \fB[show|sh]
+show the current value of the LD_PRELOAD variable
+.IP \fB<without\ any\ argument>
+create a new shell with LD_PRELOAD including torsocks(8).
+.PP
+.SH AUTHOR
+This script was created by Tamas SZERB <toma at rulez.org> for the debian
+package of tsocks. It (along with this manual page) have since been
+adapted into the torsocks project and modified.
diff --git a/doc/torsocks.8.in b/doc/torsocks.8.in
new file mode 100644
index 0000000..0cda513
--- /dev/null
+++ b/doc/torsocks.8.in
@@ -0,0 +1,189 @@
+.TH TORSOCKS 8 "" "Shaun Clowes" \" -*-
+ \" nroff -*
+
+.SH NAME
+.BR torsocks
+\- Library for intercepting outgoing network connections and
+redirecting them through a SOCKS server.
+
+.SH SYNOPSIS
+
+Set LD_PRELOAD to load the library then use applications as normal
+
+The syntax to force preload of the library for different shells is
+specified below:
+
+Bash, Ksh and Bourne shell -
+
+export LD_PRELOAD=/lib/libtorsocks.so
+
+C Shell -
+
+setenv LD_PRELOAD=/lib/libtorsocks.so
+
+This process can be automated (for Bash, Bourne and Korn shell
+users) for a single command or for all commands in a shell session
+by using the torsocks(1) script
+
+You can also setup torsocks in such a way that all processes
+automatically use it, a very useful configuration. For more
+information on this configuration see the CAVEATS section of this
+manual page.
+
+.SH DESCRIPTION
+
+.BR torsocks
+is a library to allow transparent SOCKS proxying. It wraps the normal
+connect() function. When a connection is attempted, it consults the
+configuration file (which is defined at configure time but defaults to
+/etc/torsocks.conf) and determines if the IP address specified is local. If
+it is not, the library redirects the connection to a SOCKS server
+specified in the configuration file. It then negotiates that connection
+with the SOCKS server and passes the connection back to the calling
+program.
+
+.BR torsocks
+is designed for use in machines which are firewalled from then
+internet. It avoids the need to recompile applications like lynx or
+telnet so they can use SOCKS to reach the internet. It behaves much like
+the SOCKSified TCP/IP stacks seen on other platforms.
+
+.SS ARGUMENTS
+Most arguments to
+.BR torsocks
+are provided in the configuration file (the location of which is defined
+at configure time by the \-\-with\-conf=<file> argument but defaults to
+/etc/torsocks.conf). The structure of this file is documented in torsocks.conf(8)
+
+Some configuration options can be specified at run time using environment
+variables as follows:
+
+.TP
+.I TORSOCKS_CONFFILE
+This environment variable overrides the default location of the torsocks
+configuration file. This variable is not honored if the program torsocks
+is embedded in is setuid. In addition this environment variable can
+be compiled out of torsocks with the \-\-disable\-envconf argument to
+configure at build time
+
+.TP
+.I TORSOCKS_DEBUG
+This environment variable sets the level of debug output that should be
+generated by torsocks (debug output is generated in the form of output to
+standard error). If this variable is not present by default the logging
+level is set to 0 which indicates that only error messages should be output.
+Setting it to higher values will cause torsocks to generate more messages
+describing what it is doing. If set to \-1 torsocks will output absolutely no
+error or debugging messages. This is only needed if torsocks output interferes
+with a program it is embedded in. Message output can be permanently compiled
+out of torsocks by specifying the \-\-disable\-debug option to configure at
+build time
+
+.TP
+.I TORSOCKS_DEBUG_FILE
+This option can be used to redirect the torsocks output (which would normally
+be sent to standard error) to a file. This variable is not honored if the
+program torsocks is embedded in is setuid. For programs where torsocks output
+interferes with normal operation this option is generally better than
+disabling messages (with TORSOCKS_DEBUG = \-1)
+
+.TP
+.I TORSOCKS_USERNAME
+This environment variable can be used to specify the username to be used when
+version 5 SOCKS servers request username/password authentication. This
+overrides the default username that can be specified in the configuration
+file using 'default_user', see torsocks.conf(8) for more information. This
+variable is ignored for version 4 SOCKS servers.
+
+.TP
+.I TORSOCKS_PASSWORD
+This environment variable can be used to specify the password to be used when
+version 5 SOCKS servers request username/password authentication. This
+overrides the default password that can be specified in the configuration
+file using 'default_pass', see torsocks.conf(8) for more information. This
+variable is ignored for version 4 SOCKS servers.
+
+.SS DNS ISSUES
+.BR torsocks
+will normally not be able to send DNS queries through a SOCKS server since
+SOCKS V4 works on TCP and DNS normally uses UDP. Version 1.5 and up do
+however provide a method to force DNS lookups to use TCP, which then makes
+them proxyable. This option can only enabled at compile time, please
+consult the INSTALL file for more information.
+
+.SS ERRORS
+.BR torsocks
+will generate error messages and print them to stderr when there are
+problems with the configuration file or the SOCKS negotiation with the
+server if the TORSOCKS_DEBUG environment variable is not set to \-1 or and
+\-\-disable\-debug was not specified at compile time. This output may cause
+some problems with programs that redirect standard error.
+
+.SS CAVEATS
+.BR torsocks
+will not in the above configuration be able to provide SOCKS proxying to
+setuid applications or applications that are not run from a shell. You can
+force all applications to LD_PRELOAD the library by placing the path to
+libtorsocks in /etc/ld.so.preload. Please make sure you correctly enter the
+full path to the library in this file if you do this. If you get it wrong,
+you will be UNABLE TO DO ANYTHING with the machine and will have to boot
+it with a rescue disk and remove the file (or try the saveme program, see
+the INSTALL file for more info). THIS IS A ***WARNING***, please be
+careful. Also be sure the library is in the root filesystem as all hell
+will break loose if the directory it is in is not available at boot time.
+
+.SH BUGS
+
+.BR torsocks
+can only proxy outgoing TCP connections
+
+.BR torsocks
+does NOT work correctly with asynchronous sockets (though it does work with
+non blocking sockets). This bug would be very difficult to fix and there
+appears to be no demand for it (I know of no major application that uses
+asynchronous sockets)
+
+.BR torsocks
+is NOT fully RFC compliant in its implementation of version 5 of SOCKS, it
+only supports the 'username and password' or 'no authentication'
+authentication methods. The RFC specifies GSSAPI must be supported by any
+compliant implementation. I haven't done this, anyone want to help?
+
+.BR torsocks
+can force the libc resolver to use TCP for name queries, if it does this
+it does it regardless of whether or not the DNS to be queried is local or
+not. This introduces overhead and should only be used when needed.
+
+.BR torsocks
+uses ELF dynamic loader features to intercept dynamic function calls from
+programs in which it is embedded. As a result, it cannot trace the
+actions of statically linked executables, non-ELF executables, or
+executables that make system calls directly with the system call trap or
+through the syscall() routine.
+
+.SH FILES
+ at CONFDIR@/torsocks.conf - default torsocks configuration file
+
+.SH SEE ALSO
+torsocks.conf(5)
+torsocks(1)
+usewithtor(1)
+
+.SH AUTHOR
+Shaun Clowes (delius at progsoc.uts.edu.au)
+
+.SH COPYRIGHT
+Copyright 2000 Shaun Clowes
+
+Renamed for use by torsocks to avoid conflict with tsocks by Robert Hogan.
+
+torsocks and its documentation may be freely copied under the terms and
+conditions of version 2 of the GNU General Public License, as published
+by the Free Software Foundation (Cambridge, Massachusetts, United
+States of America).
+
+This documentation is based on the documentation for logwrites, another
+shared library interceptor. One line of code from it was used in
+torsocks and a lot of the documentation :) logwrites is by
+adam at yggdrasil.com (Adam J. Richter) and can be had from ftp.yggdrasil.com
+pub/dist/pkg
diff --git a/doc/torsocks.conf b/doc/torsocks.conf
new file mode 100644
index 0000000..8cc1b2c
--- /dev/null
+++ b/doc/torsocks.conf
@@ -0,0 +1,56 @@
+# This is the configuration for libtorsocks (transparent socks) for use
+# with tor, which is providing a socks server on port 9050 by default.
+#
+# Lines beginning with # and blank lines are ignored
+#
+# The basic idea is to specify:
+# - Local subnets - Networks that can be accessed directly without
+# assistance from a socks server
+# - Paths - Paths are basically lists of networks and a socks server
+# which can be used to reach these networks
+# - Default server - A socks server which should be used to access
+# networks for which no path is available
+# Much more documentation than provided in these comments can be found in
+# torsocks.conf(5) and usewithtor(1) manpages.
+
+# We specify local as 127.0.0.0 - 127.191.255.255 because the
+# Tor MAPADDRESS virtual IP range is the rest of net 127.
+# Torsocks also treats as local all the subnets that Tor does.
+local = 127.0.0.0/255.128.0.0
+local = 127.128.0.0/255.192.0.0
+local = 169.254.0.0/255.255.0.0
+local = 172.16.0.0/255.240.0.0
+local = 192.168.0.0/255.255.0.0
+
+# Default server
+# For connections that aren't to the local subnets
+# the server at 127.0.0.1 should be used (again, hostnames could be used
+# too, see note above)
+server = 127.0.0.1
+
+# SOCKS server type defaults to 4
+#server_type = 5
+
+# The port defaults to 1080 but I've stated it here for clarity
+server_port = 9050
+
+# Username and password (if required on a SOCKSv5 server)
+#default_user =
+#default_pass =
+
+# Paths
+# For this example this machine needs to access 150.0.0.0/255.255.0.0 as
+# well as port 80 on the network 150.1.0.0/255.255.0.0 through
+# the socks 5 server at 10.1.7.25 (if this machines hostname was
+# "socks.hello.com" we could also specify that, unless --disable-hostnames
+# was specified to ./configure).
+
+#path {
+# reaches = 150.0.0.0/255.255.0.0
+# reaches = 150.1.0.0:80/255.255.0.0
+# server = 10.1.7.25
+# server_type = 5
+# default_user = delius
+# default_pass = hello
+#}
+#
diff --git a/doc/torsocks.conf.5.in b/doc/torsocks.conf.5.in
new file mode 100644
index 0000000..7cd22d8
--- /dev/null
+++ b/doc/torsocks.conf.5.in
@@ -0,0 +1,214 @@
+.TH TORSOCKS.CONF 5 "" "Robert Hogan" \" -*-
+ \" nroff -*
+
+.SH NAME
+.BR torsocks.conf
+\- configuration file for torsocks(8)
+
+.SH SUMMARY
+
+By default, torsocks will assume that it should connect to the SOCKS proxy
+running at 127.0.0.1 on port 9050. This is the default address and port for
+Tor's socks server on most installations. If you are running a normal Tor
+installation and have no special requirements, then you should not need to
+create, edit or invoke a configuration file when using torsocks.
+
+Your installation of torsocks includes a default configuration file
+that contains values sensible for use with most Tor installations. The
+installation location for your default configuration file is:
+
+ @CONFDIR@/torsocks.conf
+
+In order to use a configuration file, you must set the environment variable
+TORSOCKS_CONF_FILE with the location of the file.
+
+If TORSOCKS_CONF_FILE is not set, torsocks will attempt to read the configuration
+file at @CONFDIR@/torsocks.conf. If that file cannot be read, torsocks will
+use sensible defaults for most Tor installations, i.e. it will assume that
+you want to use a SOCKS proxy running at 127.0.0.1 (localhost) on port 9050.
+
+An example of typical usage is provided under the 'example' heading at the
+end of this manual page. The script 'usewithtor' provided with your torsocks
+installation will set this environment variable for you, and load the
+configuration file provided with your installation.
+
+If you want to use a custom file in a different location, you should set the
+environment variable yourself and then use the torsocks command, rather than
+usewithtor.
+
+.SH OVERVIEW
+
+The configuration for torsocks can be anything from two lines to hundreds of
+lines based on the needs at any particular site. The basic idea is to define
+any networks the machine can access directly (i.e without the use of a
+SOCKS server) and define one or many SOCKS servers to be used to access
+other networks (including a 'default' server).
+
+Local networks are declared using the 'local' keyword in the configuration
+file. When applications attempt to connect to machines in networks marked
+as local torsocks will not attempt to use a SOCKS server to negotiate the
+connection.
+
+Obviously if a connection is not to a locally accessible network it will need
+to be proxied over a SOCKS server. However, many installations have several
+different SOCKS servers to be used to access different internal (and external)
+networks. For this reason the configuration file allows the definition of
+`paths' as well as a default SOCKS server.
+
+Paths are declared as blocks in the configuration file. That is, they begin
+with a 'path {' line in the configuration file and end with a '}' line. Inside
+this block directives should be used to declare a SOCKS server (as documented
+later in this manual page) and 'reaches' directives should be used to declare
+networks and even destination ports in those networks that this server should
+be used to reach. N.B Each path MUST define a SOCKS server and contain one or
+more 'reaches' directives.
+
+SOCKS server declaration directives that are not contained within a 'path'
+block define the default SOCKS server. If torsocks needs to connect to a machine
+via a SOCKS server (i.e it isn't a network declared as 'local') and no 'path'
+has declared it can reach that network via a 'reaches' directive this server
+is used to negotiate the connection.
+
+.SH CONFIGURATION SYNTAX
+
+The basic structure of all lines in the configuration file is:
+
+.RS
+<directive> = <parameters>
+.RE
+
+The exception to this is 'path' blocks which look like:
+
+.RS
+path {
+.RS
+<directive> = <parameters>
+.RE
+}
+.RE
+
+Empty lines are ignored and all input on a line after a '#' character is
+ignored.
+
+.SS DIRECTIVES
+The following directives are used in the torsocks configuration file:
+
+.TP
+.I server
+The IP address of the SOCKS server (e.g "server = 10.1.4.253"). Only one
+server may be specified per path block, or one outside a path
+block (to define the default server). Unless \-\-disable-hostnames was
+specified to configure at compile time the server can be specified as
+a hostname (e.g "server = socks.nec.com")
+
+.TP
+.I server_port
+The port on which the SOCKS server receives requests. Only one server_port
+may be specified per path block, or one outside a path (for the default
+server). This directive is not required if the server is on the
+standard port (1080).
+
+.TP
+.I server_type
+SOCKS version used by the server. Versions 4 and 5 are supported (but both
+for only the connect operation). The default is 4. Only one server_type
+may be specified per path block, or one outside a path (for the default
+server).
+
+You can use the inspectorsocks utility to determine the type of server, see
+the 'UTILITIES' section later in this manual page.
+
+.TP
+.I default_user
+This specifies the default username to be used for username and password
+authentication in SOCKS version 5. In order to determine the username to
+use (if the socks server requires username and password authentication)
+torsocks first looks for the environment variable TSOCKS_USERNAME, then
+looks for this configuration option, then tries to get the local username.
+This option is not valid for SOCKS version 4 servers. Only one default_user
+may be specified per path block, or one outside a path (for the default
+server)
+
+.TP
+.I default_pass
+This specified the default password to be used for username and password
+authentication in SOCKS version 5. In order to determine the password to
+use (if the socks server requires username and password authentication)
+torsocks first looks for the environment variable TSOCKS_PASSWORD, then
+looks for this configuration option. This option is not valid for SOCKS
+version 4 servers. Onle one default_pass may be specified per path block,
+or one outside a path (for the default server)
+
+.TP
+.I local
+An IP/Subnet pair specifying a network which may be accessed directly without
+proxying through a SOCKS server (e.g "local = 10.0.0.0/255.0.0.0").
+Obviously all SOCKS server IP addresses must be in networks specified as
+local, otherwise torsocks would need a SOCKS server to reach SOCKS servers.
+
+.TP
+.I reaches
+This directive is only valid inside a path block. Its parameter is formed
+as IP[:startport[\-endport]]/Subnet and it specifies a network (and a range
+of ports on that network) that can be accessed by the SOCKS server specified
+in this path block. For example, in a path block "reaches =
+150.0.0.0:80-1024/255.0.0.0" indicates to torsocks that the SOCKS server
+specified in the current path block should be used to access any IPs in the
+range 150.0.0.0 to 150.255.255.255 when the connection request is for ports
+80-1024.
+
+.TP
+.I tordns_enable
+This enables the use of the 'tordns' feature in torsocks, which overrides the
+standard C library name resolution calls to use SOCKS. The default value is
+`true'.
+
+.TP
+.I tordns_deadpool_range
+Tor hidden sites do not have real IP addresses. This specifies what range of
+IP addresses will be handed to the application as "cookies" for .onion names.
+Of course, you should pick a block of addresses which you aren't going to ever
+need to actually connect to. The default value is '127.0.69.0/255.255.255.0'.
+
+.TP
+.I tordns_cache_size
+This specifies the number of IP addresses looked up through SOCKS to cache.
+The default value is 256. Each entry consumes 260 bytes of memory, so the
+default adds 66,560 bytes of overhead to each 'torified' process. NOTE: if
+the number of IP addresses in tordns_deadpool_range is less than the value
+specified for tordns_cache_size, then the cache will be shrunk to fit the
+deadpool range. This is to prevent duplicate deadpool addresses from ever
+appearing in the cache.
+
+.SH UTILITIES
+torsocks comes with two utilities that can be useful in creating and verifying
+the torsocks configuration file.
+
+.SH EXAMPLE
+
+ export TORSOCKS_CONF_FILE=$PWD/torsocks.conf
+ torsocks ssh account at sshserver.com
+
+.SH SEE ALSO
+torsocks(8)
+
+.SH AUTHOR
+Robert Hogan (robert at roberthogan.net)
+Shaun Clowes (delius at progsoc.uts.edu.au)
+
+.SH COPYRIGHT
+Copyright 2009 Robert Hogan
+Copyright 2000 Shaun Clowes
+
+Renamed for use by torsocks to avoid conflict with torsocks by Robert Hogan.
+
+torsocks and its documentation may be freely copied under the terms and
+conditions of version 2 of the GNU General Public License, as published
+by the Free Software Foundation (Cambridge, Massachusetts, United
+States of America).
+
+This documentation is based on the documentation for logwrites, another
+shared library interceptor. One line of code from it was used in
+torsocks and a lot of the documentation :) logwrites is by
+adam at yggdrasil.com (Adam J. Richter) and can be had from ftp.yggdrasil.com
+pub/dist/pkg
diff --git a/doc/tsocks.conf.complex.example b/doc/tsocks.conf.complex.example
new file mode 100644
index 0000000..bdeea24
--- /dev/null
+++ b/doc/tsocks.conf.complex.example
@@ -0,0 +1,47 @@
+# This is the configuration for libtsocks (transparent socks)
+# Lines beginning with # and blank lines are ignored
+#
+# The basic idea is to specify:
+# - Local subnets - Networks that can be accessed directly without
+# assistance from a socks server
+# - Paths - Paths are basically lists of networks and a socks server
+# which can be used to reach these networks
+# - Default server - A socks server which should be used to access
+# networks for which no path is available
+# Much more documentation than provided in these comments can be found in
+# the man pages, tsocks(8) and tsocks.conf(8)
+
+# Local networks
+# For this example this machine can directly access 192.168.0.0/255.255.255.0
+# (192.168.0.*) and 10.0.0.0/255.0.0.0 (10.*)
+
+local = 192.168.0.0/255.255.255.0
+local = 10.0.0.0/255.0.0.0
+
+# Paths
+# For this example this machine needs to access 150.0.0.0/255.255.0.0 as
+# well as port 80 on the network 150.1.0.0/255.255.0.0 through
+# the socks 5 server at 10.1.7.25 (if this machines hostname was
+# "socks.hello.com" we could also specify that, unless --disable-hostnames
+# was specified to ./configure).
+
+path {
+ reaches = 150.0.0.0/255.255.0.0
+ reaches = 150.1.0.0:80/255.255.0.0
+ server = 10.1.7.25
+ server_type = 5
+ default_user = delius
+ default_pass = hello
+}
+
+# Default server
+# For connections that aren't to the local subnets or to 150.0.0.0/255.255.0.0
+# the server at 192.168.0.1 should be used (again, hostnames could be used
+# too, see note above)
+
+server = 192.168.0.1
+# Server type defaults to 4 so we need to specify it as 5 for this one
+server_type = 5
+# The port defaults to 1080 but I've stated it here for clarity
+server_port = 1080
+
diff --git a/doc/tsocks.conf.simple.example b/doc/tsocks.conf.simple.example
new file mode 100644
index 0000000..bf2a695
--- /dev/null
+++ b/doc/tsocks.conf.simple.example
@@ -0,0 +1,16 @@
+# This is the configuration for libtsocks (transparent socks)
+# Lines beginning with # and blank lines are ignored
+#
+# This sample configuration shows the simplest (and most common) use of
+# tsocks. This is a basic LAN, this machine can access anything on the
+# local ethernet (192.168.0.*) but anything else has to use the SOCKS version
+# 4 server on the firewall. Further details can be found in the man pages,
+# tsocks(8) and tsocks.conf(5) and a more complex example is presented in
+# tsocks.conf.complex.example
+
+# We can access 192.168.0.* directly
+local = 192.168.0.0/255.255.255.0
+
+# Otherwise we use the server
+server = 192.168.0.1
+
diff --git a/doc/usewithtor.1.in b/doc/usewithtor.1.in
new file mode 100644
index 0000000..c7500cb
--- /dev/null
+++ b/doc/usewithtor.1.in
@@ -0,0 +1,57 @@
+.TH USEWITHTOR 1 "" "USEWITHTOR"
+
+.SH NAME
+.BR usewithtor
+\- Shell wrapper to simplify the use of the torsocks(8) library to
+transparently allow an application to use a SOCKS proxy.
+
+.SH SYNOPSIS
+.B usewithtor
+.RB [application\ [application's\ arguments]]
+.br
+.SH DESCRIPTION
+.B usewithtor
+is a wrapper between the torsocks library and the application what you
+would like to run socksified.
+
+.SH OPTIONS
+.IP \fB[application\ \fB[application's\ arguments]]
+run the application as specified with the environment (LD_PRELOAD) set
+such that torsocks(8) will transparently proxy SOCKS connections in
+that program.
+
+.SH USEWITHTOR VERSUS TORSOCKS
+.B usewithtor
+runs
+.B torsocks(1)
+with the default configuration file,
+located at
+.B @CONFDIR@/torsocks.conf.
+Running torsocks(1) directly means
+that no configuration file will be used (unless you manually set the
+TORSOCKS_CONF_FILE or TSOCKS_CONF_FILE environment variable), instead
+.B torsocks(8)
+will
+use defaults that are sensible for most Tor installations.
+
+.SH USEWITHTOR VERSUS TORIFY
+.B usewithtor(1)
+and
+.B torify(1)
+intend to achieve the same ends for most
+practical purposes. However
+.B torify(1)
+will use a default tsocks installation if one exists.
+.B Usewithtor(1)
+will only ever use a
+.B torsocks(8)
+installation.
+
+.SH SEE ALSO
+torsocks.conf(5)
+torsocks(1)
+usewithtor(1)
+
+.SH AUTHOR
+Robert Hogan (robert at roberthogan.net).This script is very similar to torify(1),
+provided by the Tor project.
\ No newline at end of file
diff --git a/src/Makefile.am b/src/Makefile.am
index cb69714..d6da8f3 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -2,27 +2,10 @@
libdir = @libdir@/torsocks
-# Install configuration file
-usewithtorconfdir = $(CONFDIR)/
-usewithtorconf_DATA = torsocks.conf
-
# Install invocation scripts
bin_SCRIPTS = torsocks usewithtor
INSTALL_SCRIPT = $(install_sh) -c -m 755
-# Install man pages
-torsocksmanpagedir = $(mandir)/man1
-torsocksmanpage_DATA = torsocks.1
-
-torsocks8manpagedir = $(mandir)/man8
-torsocks8manpage_DATA = torsocks.8
-
-usewithtormanpagedir = $(mandir)/man1
-usewithtormanpage_DATA = usewithtor.1
-
-torsocksconfmanpagedir = $(mandir)/man5
-torsocksconfmanpage_DATA = torsocks.conf.5
-
# Install main library to $(prefix)/lib/tor (must match torsocks.in)
lib_LTLIBRARIES = libtorsocks.la
libtorsocks_la_SOURCES = torsocks.c common.c parser.c dead_pool.c darwin_warts.c socks.c
diff --git a/src/torsocks.1.in b/src/torsocks.1.in
deleted file mode 100644
index b383859..0000000
--- a/src/torsocks.1.in
+++ /dev/null
@@ -1,63 +0,0 @@
-.TH TORSOCKS 1 "" "TORSOCKS"
-
-.SH NAME
-.BR torsocks
-\- Shell wrapper to simplify the use of the torsocks(8) library to
-transparently allow an application to use a SOCKS proxy. Basically a renamed, patched tsocks.
-.SH SYNOPSIS
-.B torsocks
-.RB [application\ [application's\ arguments]]
-.br
-or
-.B torsocks
-.RB [on|off]
-.br
-or
-.B torsocks
-.SH DESCRIPTION
-.B torsocks
-is a wrapper between the torsocks library and the application what you
-would like to run socksified.
-.SH SUMMARY
-
-By default, torsocks will assume that it should connect to the SOCKS proxy
-running at 127.0.0.1 on port 9050. This is the default address and port for
-Tor's socks server on most installations.
-
-In order to use a configuration file, you must set the environment variable
-TORSOCKS_CONF_FILE with the location of the file.
-
-If TORSOCKS_CONF_FILE is not set, torsocks will attempt to read the configuration
-file at @CONFDIR@/torsocks.conf. If that file cannot be read, torsocks will
-use sensible defaults for most Tor installations, i.e. it will assume that
-you want to use a SOCKS proxy running at 127.0.0.1 (localhost) on port 9050.
-
-For further information on configuration, see
-.B torsocks.conf(5).
-
-.SH OPTIONS
-.IP \fB[application\ \fB[application's\ arguments]]
-run the application as specified with the environment (LD_PRELOAD) set
-such that torsocks(8) will transparently proxy SOCKS connections in
-that program
-.IP \fB[on|off]
-this option adds or removes torsocks(8) from the LD_PRELOAD environment
-variable. When torsocks(8) is in this variable all executed
-applications are automatically socksified. If you want to
-use this function, you HAVE to source the shell script from yours,
-like this: "source /usr/bin/torsocks" or ". /usr/bin/torsocks"
-.br
-Example:
-.br
-". torsocks on" -- add the torsocks lib to LD_PRELOAD
-.br
-". torsocks off" -- remove the torsocks lib from LD_PRELOAD
-.IP \fB[show|sh]
-show the current value of the LD_PRELOAD variable
-.IP \fB<without\ any\ argument>
-create a new shell with LD_PRELOAD including torsocks(8).
-.PP
-.SH AUTHOR
-This script was created by Tamas SZERB <toma at rulez.org> for the debian
-package of tsocks. It (along with this manual page) have since been
-adapted into the torsocks project and modified.
diff --git a/src/torsocks.8.in b/src/torsocks.8.in
deleted file mode 100644
index 0cda513..0000000
--- a/src/torsocks.8.in
+++ /dev/null
@@ -1,189 +0,0 @@
-.TH TORSOCKS 8 "" "Shaun Clowes" \" -*-
- \" nroff -*
-
-.SH NAME
-.BR torsocks
-\- Library for intercepting outgoing network connections and
-redirecting them through a SOCKS server.
-
-.SH SYNOPSIS
-
-Set LD_PRELOAD to load the library then use applications as normal
-
-The syntax to force preload of the library for different shells is
-specified below:
-
-Bash, Ksh and Bourne shell -
-
-export LD_PRELOAD=/lib/libtorsocks.so
-
-C Shell -
-
-setenv LD_PRELOAD=/lib/libtorsocks.so
-
-This process can be automated (for Bash, Bourne and Korn shell
-users) for a single command or for all commands in a shell session
-by using the torsocks(1) script
-
-You can also setup torsocks in such a way that all processes
-automatically use it, a very useful configuration. For more
-information on this configuration see the CAVEATS section of this
-manual page.
-
-.SH DESCRIPTION
-
-.BR torsocks
-is a library to allow transparent SOCKS proxying. It wraps the normal
-connect() function. When a connection is attempted, it consults the
-configuration file (which is defined at configure time but defaults to
-/etc/torsocks.conf) and determines if the IP address specified is local. If
-it is not, the library redirects the connection to a SOCKS server
-specified in the configuration file. It then negotiates that connection
-with the SOCKS server and passes the connection back to the calling
-program.
-
-.BR torsocks
-is designed for use in machines which are firewalled from then
-internet. It avoids the need to recompile applications like lynx or
-telnet so they can use SOCKS to reach the internet. It behaves much like
-the SOCKSified TCP/IP stacks seen on other platforms.
-
-.SS ARGUMENTS
-Most arguments to
-.BR torsocks
-are provided in the configuration file (the location of which is defined
-at configure time by the \-\-with\-conf=<file> argument but defaults to
-/etc/torsocks.conf). The structure of this file is documented in torsocks.conf(8)
-
-Some configuration options can be specified at run time using environment
-variables as follows:
-
-.TP
-.I TORSOCKS_CONFFILE
-This environment variable overrides the default location of the torsocks
-configuration file. This variable is not honored if the program torsocks
-is embedded in is setuid. In addition this environment variable can
-be compiled out of torsocks with the \-\-disable\-envconf argument to
-configure at build time
-
-.TP
-.I TORSOCKS_DEBUG
-This environment variable sets the level of debug output that should be
-generated by torsocks (debug output is generated in the form of output to
-standard error). If this variable is not present by default the logging
-level is set to 0 which indicates that only error messages should be output.
-Setting it to higher values will cause torsocks to generate more messages
-describing what it is doing. If set to \-1 torsocks will output absolutely no
-error or debugging messages. This is only needed if torsocks output interferes
-with a program it is embedded in. Message output can be permanently compiled
-out of torsocks by specifying the \-\-disable\-debug option to configure at
-build time
-
-.TP
-.I TORSOCKS_DEBUG_FILE
-This option can be used to redirect the torsocks output (which would normally
-be sent to standard error) to a file. This variable is not honored if the
-program torsocks is embedded in is setuid. For programs where torsocks output
-interferes with normal operation this option is generally better than
-disabling messages (with TORSOCKS_DEBUG = \-1)
-
-.TP
-.I TORSOCKS_USERNAME
-This environment variable can be used to specify the username to be used when
-version 5 SOCKS servers request username/password authentication. This
-overrides the default username that can be specified in the configuration
-file using 'default_user', see torsocks.conf(8) for more information. This
-variable is ignored for version 4 SOCKS servers.
-
-.TP
-.I TORSOCKS_PASSWORD
-This environment variable can be used to specify the password to be used when
-version 5 SOCKS servers request username/password authentication. This
-overrides the default password that can be specified in the configuration
-file using 'default_pass', see torsocks.conf(8) for more information. This
-variable is ignored for version 4 SOCKS servers.
-
-.SS DNS ISSUES
-.BR torsocks
-will normally not be able to send DNS queries through a SOCKS server since
-SOCKS V4 works on TCP and DNS normally uses UDP. Version 1.5 and up do
-however provide a method to force DNS lookups to use TCP, which then makes
-them proxyable. This option can only enabled at compile time, please
-consult the INSTALL file for more information.
-
-.SS ERRORS
-.BR torsocks
-will generate error messages and print them to stderr when there are
-problems with the configuration file or the SOCKS negotiation with the
-server if the TORSOCKS_DEBUG environment variable is not set to \-1 or and
-\-\-disable\-debug was not specified at compile time. This output may cause
-some problems with programs that redirect standard error.
-
-.SS CAVEATS
-.BR torsocks
-will not in the above configuration be able to provide SOCKS proxying to
-setuid applications or applications that are not run from a shell. You can
-force all applications to LD_PRELOAD the library by placing the path to
-libtorsocks in /etc/ld.so.preload. Please make sure you correctly enter the
-full path to the library in this file if you do this. If you get it wrong,
-you will be UNABLE TO DO ANYTHING with the machine and will have to boot
-it with a rescue disk and remove the file (or try the saveme program, see
-the INSTALL file for more info). THIS IS A ***WARNING***, please be
-careful. Also be sure the library is in the root filesystem as all hell
-will break loose if the directory it is in is not available at boot time.
-
-.SH BUGS
-
-.BR torsocks
-can only proxy outgoing TCP connections
-
-.BR torsocks
-does NOT work correctly with asynchronous sockets (though it does work with
-non blocking sockets). This bug would be very difficult to fix and there
-appears to be no demand for it (I know of no major application that uses
-asynchronous sockets)
-
-.BR torsocks
-is NOT fully RFC compliant in its implementation of version 5 of SOCKS, it
-only supports the 'username and password' or 'no authentication'
-authentication methods. The RFC specifies GSSAPI must be supported by any
-compliant implementation. I haven't done this, anyone want to help?
-
-.BR torsocks
-can force the libc resolver to use TCP for name queries, if it does this
-it does it regardless of whether or not the DNS to be queried is local or
-not. This introduces overhead and should only be used when needed.
-
-.BR torsocks
-uses ELF dynamic loader features to intercept dynamic function calls from
-programs in which it is embedded. As a result, it cannot trace the
-actions of statically linked executables, non-ELF executables, or
-executables that make system calls directly with the system call trap or
-through the syscall() routine.
-
-.SH FILES
- at CONFDIR@/torsocks.conf - default torsocks configuration file
-
-.SH SEE ALSO
-torsocks.conf(5)
-torsocks(1)
-usewithtor(1)
-
-.SH AUTHOR
-Shaun Clowes (delius at progsoc.uts.edu.au)
-
-.SH COPYRIGHT
-Copyright 2000 Shaun Clowes
-
-Renamed for use by torsocks to avoid conflict with tsocks by Robert Hogan.
-
-torsocks and its documentation may be freely copied under the terms and
-conditions of version 2 of the GNU General Public License, as published
-by the Free Software Foundation (Cambridge, Massachusetts, United
-States of America).
-
-This documentation is based on the documentation for logwrites, another
-shared library interceptor. One line of code from it was used in
-torsocks and a lot of the documentation :) logwrites is by
-adam at yggdrasil.com (Adam J. Richter) and can be had from ftp.yggdrasil.com
-pub/dist/pkg
diff --git a/src/torsocks.conf b/src/torsocks.conf
deleted file mode 100644
index 8cc1b2c..0000000
--- a/src/torsocks.conf
+++ /dev/null
@@ -1,56 +0,0 @@
-# This is the configuration for libtorsocks (transparent socks) for use
-# with tor, which is providing a socks server on port 9050 by default.
-#
-# Lines beginning with # and blank lines are ignored
-#
-# The basic idea is to specify:
-# - Local subnets - Networks that can be accessed directly without
-# assistance from a socks server
-# - Paths - Paths are basically lists of networks and a socks server
-# which can be used to reach these networks
-# - Default server - A socks server which should be used to access
-# networks for which no path is available
-# Much more documentation than provided in these comments can be found in
-# torsocks.conf(5) and usewithtor(1) manpages.
-
-# We specify local as 127.0.0.0 - 127.191.255.255 because the
-# Tor MAPADDRESS virtual IP range is the rest of net 127.
-# Torsocks also treats as local all the subnets that Tor does.
-local = 127.0.0.0/255.128.0.0
-local = 127.128.0.0/255.192.0.0
-local = 169.254.0.0/255.255.0.0
-local = 172.16.0.0/255.240.0.0
-local = 192.168.0.0/255.255.0.0
-
-# Default server
-# For connections that aren't to the local subnets
-# the server at 127.0.0.1 should be used (again, hostnames could be used
-# too, see note above)
-server = 127.0.0.1
-
-# SOCKS server type defaults to 4
-#server_type = 5
-
-# The port defaults to 1080 but I've stated it here for clarity
-server_port = 9050
-
-# Username and password (if required on a SOCKSv5 server)
-#default_user =
-#default_pass =
-
-# Paths
-# For this example this machine needs to access 150.0.0.0/255.255.0.0 as
-# well as port 80 on the network 150.1.0.0/255.255.0.0 through
-# the socks 5 server at 10.1.7.25 (if this machines hostname was
-# "socks.hello.com" we could also specify that, unless --disable-hostnames
-# was specified to ./configure).
-
-#path {
-# reaches = 150.0.0.0/255.255.0.0
-# reaches = 150.1.0.0:80/255.255.0.0
-# server = 10.1.7.25
-# server_type = 5
-# default_user = delius
-# default_pass = hello
-#}
-#
diff --git a/src/torsocks.conf.5.in b/src/torsocks.conf.5.in
deleted file mode 100644
index 7cd22d8..0000000
--- a/src/torsocks.conf.5.in
+++ /dev/null
@@ -1,214 +0,0 @@
-.TH TORSOCKS.CONF 5 "" "Robert Hogan" \" -*-
- \" nroff -*
-
-.SH NAME
-.BR torsocks.conf
-\- configuration file for torsocks(8)
-
-.SH SUMMARY
-
-By default, torsocks will assume that it should connect to the SOCKS proxy
-running at 127.0.0.1 on port 9050. This is the default address and port for
-Tor's socks server on most installations. If you are running a normal Tor
-installation and have no special requirements, then you should not need to
-create, edit or invoke a configuration file when using torsocks.
-
-Your installation of torsocks includes a default configuration file
-that contains values sensible for use with most Tor installations. The
-installation location for your default configuration file is:
-
- @CONFDIR@/torsocks.conf
-
-In order to use a configuration file, you must set the environment variable
-TORSOCKS_CONF_FILE with the location of the file.
-
-If TORSOCKS_CONF_FILE is not set, torsocks will attempt to read the configuration
-file at @CONFDIR@/torsocks.conf. If that file cannot be read, torsocks will
-use sensible defaults for most Tor installations, i.e. it will assume that
-you want to use a SOCKS proxy running at 127.0.0.1 (localhost) on port 9050.
-
-An example of typical usage is provided under the 'example' heading at the
-end of this manual page. The script 'usewithtor' provided with your torsocks
-installation will set this environment variable for you, and load the
-configuration file provided with your installation.
-
-If you want to use a custom file in a different location, you should set the
-environment variable yourself and then use the torsocks command, rather than
-usewithtor.
-
-.SH OVERVIEW
-
-The configuration for torsocks can be anything from two lines to hundreds of
-lines based on the needs at any particular site. The basic idea is to define
-any networks the machine can access directly (i.e without the use of a
-SOCKS server) and define one or many SOCKS servers to be used to access
-other networks (including a 'default' server).
-
-Local networks are declared using the 'local' keyword in the configuration
-file. When applications attempt to connect to machines in networks marked
-as local torsocks will not attempt to use a SOCKS server to negotiate the
-connection.
-
-Obviously if a connection is not to a locally accessible network it will need
-to be proxied over a SOCKS server. However, many installations have several
-different SOCKS servers to be used to access different internal (and external)
-networks. For this reason the configuration file allows the definition of
-`paths' as well as a default SOCKS server.
-
-Paths are declared as blocks in the configuration file. That is, they begin
-with a 'path {' line in the configuration file and end with a '}' line. Inside
-this block directives should be used to declare a SOCKS server (as documented
-later in this manual page) and 'reaches' directives should be used to declare
-networks and even destination ports in those networks that this server should
-be used to reach. N.B Each path MUST define a SOCKS server and contain one or
-more 'reaches' directives.
-
-SOCKS server declaration directives that are not contained within a 'path'
-block define the default SOCKS server. If torsocks needs to connect to a machine
-via a SOCKS server (i.e it isn't a network declared as 'local') and no 'path'
-has declared it can reach that network via a 'reaches' directive this server
-is used to negotiate the connection.
-
-.SH CONFIGURATION SYNTAX
-
-The basic structure of all lines in the configuration file is:
-
-.RS
-<directive> = <parameters>
-.RE
-
-The exception to this is 'path' blocks which look like:
-
-.RS
-path {
-.RS
-<directive> = <parameters>
-.RE
-}
-.RE
-
-Empty lines are ignored and all input on a line after a '#' character is
-ignored.
-
-.SS DIRECTIVES
-The following directives are used in the torsocks configuration file:
-
-.TP
-.I server
-The IP address of the SOCKS server (e.g "server = 10.1.4.253"). Only one
-server may be specified per path block, or one outside a path
-block (to define the default server). Unless \-\-disable-hostnames was
-specified to configure at compile time the server can be specified as
-a hostname (e.g "server = socks.nec.com")
-
-.TP
-.I server_port
-The port on which the SOCKS server receives requests. Only one server_port
-may be specified per path block, or one outside a path (for the default
-server). This directive is not required if the server is on the
-standard port (1080).
-
-.TP
-.I server_type
-SOCKS version used by the server. Versions 4 and 5 are supported (but both
-for only the connect operation). The default is 4. Only one server_type
-may be specified per path block, or one outside a path (for the default
-server).
-
-You can use the inspectorsocks utility to determine the type of server, see
-the 'UTILITIES' section later in this manual page.
-
-.TP
-.I default_user
-This specifies the default username to be used for username and password
-authentication in SOCKS version 5. In order to determine the username to
-use (if the socks server requires username and password authentication)
-torsocks first looks for the environment variable TSOCKS_USERNAME, then
-looks for this configuration option, then tries to get the local username.
-This option is not valid for SOCKS version 4 servers. Only one default_user
-may be specified per path block, or one outside a path (for the default
-server)
-
-.TP
-.I default_pass
-This specified the default password to be used for username and password
-authentication in SOCKS version 5. In order to determine the password to
-use (if the socks server requires username and password authentication)
-torsocks first looks for the environment variable TSOCKS_PASSWORD, then
-looks for this configuration option. This option is not valid for SOCKS
-version 4 servers. Onle one default_pass may be specified per path block,
-or one outside a path (for the default server)
-
-.TP
-.I local
-An IP/Subnet pair specifying a network which may be accessed directly without
-proxying through a SOCKS server (e.g "local = 10.0.0.0/255.0.0.0").
-Obviously all SOCKS server IP addresses must be in networks specified as
-local, otherwise torsocks would need a SOCKS server to reach SOCKS servers.
-
-.TP
-.I reaches
-This directive is only valid inside a path block. Its parameter is formed
-as IP[:startport[\-endport]]/Subnet and it specifies a network (and a range
-of ports on that network) that can be accessed by the SOCKS server specified
-in this path block. For example, in a path block "reaches =
-150.0.0.0:80-1024/255.0.0.0" indicates to torsocks that the SOCKS server
-specified in the current path block should be used to access any IPs in the
-range 150.0.0.0 to 150.255.255.255 when the connection request is for ports
-80-1024.
-
-.TP
-.I tordns_enable
-This enables the use of the 'tordns' feature in torsocks, which overrides the
-standard C library name resolution calls to use SOCKS. The default value is
-`true'.
-
-.TP
-.I tordns_deadpool_range
-Tor hidden sites do not have real IP addresses. This specifies what range of
-IP addresses will be handed to the application as "cookies" for .onion names.
-Of course, you should pick a block of addresses which you aren't going to ever
-need to actually connect to. The default value is '127.0.69.0/255.255.255.0'.
-
-.TP
-.I tordns_cache_size
-This specifies the number of IP addresses looked up through SOCKS to cache.
-The default value is 256. Each entry consumes 260 bytes of memory, so the
-default adds 66,560 bytes of overhead to each 'torified' process. NOTE: if
-the number of IP addresses in tordns_deadpool_range is less than the value
-specified for tordns_cache_size, then the cache will be shrunk to fit the
-deadpool range. This is to prevent duplicate deadpool addresses from ever
-appearing in the cache.
-
-.SH UTILITIES
-torsocks comes with two utilities that can be useful in creating and verifying
-the torsocks configuration file.
-
-.SH EXAMPLE
-
- export TORSOCKS_CONF_FILE=$PWD/torsocks.conf
- torsocks ssh account at sshserver.com
-
-.SH SEE ALSO
-torsocks(8)
-
-.SH AUTHOR
-Robert Hogan (robert at roberthogan.net)
-Shaun Clowes (delius at progsoc.uts.edu.au)
-
-.SH COPYRIGHT
-Copyright 2009 Robert Hogan
-Copyright 2000 Shaun Clowes
-
-Renamed for use by torsocks to avoid conflict with torsocks by Robert Hogan.
-
-torsocks and its documentation may be freely copied under the terms and
-conditions of version 2 of the GNU General Public License, as published
-by the Free Software Foundation (Cambridge, Massachusetts, United
-States of America).
-
-This documentation is based on the documentation for logwrites, another
-shared library interceptor. One line of code from it was used in
-torsocks and a lot of the documentation :) logwrites is by
-adam at yggdrasil.com (Adam J. Richter) and can be had from ftp.yggdrasil.com
-pub/dist/pkg
diff --git a/src/tsocks.conf.complex.example b/src/tsocks.conf.complex.example
deleted file mode 100644
index bdeea24..0000000
--- a/src/tsocks.conf.complex.example
+++ /dev/null
@@ -1,47 +0,0 @@
-# This is the configuration for libtsocks (transparent socks)
-# Lines beginning with # and blank lines are ignored
-#
-# The basic idea is to specify:
-# - Local subnets - Networks that can be accessed directly without
-# assistance from a socks server
-# - Paths - Paths are basically lists of networks and a socks server
-# which can be used to reach these networks
-# - Default server - A socks server which should be used to access
-# networks for which no path is available
-# Much more documentation than provided in these comments can be found in
-# the man pages, tsocks(8) and tsocks.conf(8)
-
-# Local networks
-# For this example this machine can directly access 192.168.0.0/255.255.255.0
-# (192.168.0.*) and 10.0.0.0/255.0.0.0 (10.*)
-
-local = 192.168.0.0/255.255.255.0
-local = 10.0.0.0/255.0.0.0
-
-# Paths
-# For this example this machine needs to access 150.0.0.0/255.255.0.0 as
-# well as port 80 on the network 150.1.0.0/255.255.0.0 through
-# the socks 5 server at 10.1.7.25 (if this machines hostname was
-# "socks.hello.com" we could also specify that, unless --disable-hostnames
-# was specified to ./configure).
-
-path {
- reaches = 150.0.0.0/255.255.0.0
- reaches = 150.1.0.0:80/255.255.0.0
- server = 10.1.7.25
- server_type = 5
- default_user = delius
- default_pass = hello
-}
-
-# Default server
-# For connections that aren't to the local subnets or to 150.0.0.0/255.255.0.0
-# the server at 192.168.0.1 should be used (again, hostnames could be used
-# too, see note above)
-
-server = 192.168.0.1
-# Server type defaults to 4 so we need to specify it as 5 for this one
-server_type = 5
-# The port defaults to 1080 but I've stated it here for clarity
-server_port = 1080
-
diff --git a/src/tsocks.conf.simple.example b/src/tsocks.conf.simple.example
deleted file mode 100644
index bf2a695..0000000
--- a/src/tsocks.conf.simple.example
+++ /dev/null
@@ -1,16 +0,0 @@
-# This is the configuration for libtsocks (transparent socks)
-# Lines beginning with # and blank lines are ignored
-#
-# This sample configuration shows the simplest (and most common) use of
-# tsocks. This is a basic LAN, this machine can access anything on the
-# local ethernet (192.168.0.*) but anything else has to use the SOCKS version
-# 4 server on the firewall. Further details can be found in the man pages,
-# tsocks(8) and tsocks.conf(5) and a more complex example is presented in
-# tsocks.conf.complex.example
-
-# We can access 192.168.0.* directly
-local = 192.168.0.0/255.255.255.0
-
-# Otherwise we use the server
-server = 192.168.0.1
-
diff --git a/src/usewithtor.1.in b/src/usewithtor.1.in
deleted file mode 100644
index c7500cb..0000000
--- a/src/usewithtor.1.in
+++ /dev/null
@@ -1,57 +0,0 @@
-.TH USEWITHTOR 1 "" "USEWITHTOR"
-
-.SH NAME
-.BR usewithtor
-\- Shell wrapper to simplify the use of the torsocks(8) library to
-transparently allow an application to use a SOCKS proxy.
-
-.SH SYNOPSIS
-.B usewithtor
-.RB [application\ [application's\ arguments]]
-.br
-.SH DESCRIPTION
-.B usewithtor
-is a wrapper between the torsocks library and the application what you
-would like to run socksified.
-
-.SH OPTIONS
-.IP \fB[application\ \fB[application's\ arguments]]
-run the application as specified with the environment (LD_PRELOAD) set
-such that torsocks(8) will transparently proxy SOCKS connections in
-that program.
-
-.SH USEWITHTOR VERSUS TORSOCKS
-.B usewithtor
-runs
-.B torsocks(1)
-with the default configuration file,
-located at
-.B @CONFDIR@/torsocks.conf.
-Running torsocks(1) directly means
-that no configuration file will be used (unless you manually set the
-TORSOCKS_CONF_FILE or TSOCKS_CONF_FILE environment variable), instead
-.B torsocks(8)
-will
-use defaults that are sensible for most Tor installations.
-
-.SH USEWITHTOR VERSUS TORIFY
-.B usewithtor(1)
-and
-.B torify(1)
-intend to achieve the same ends for most
-practical purposes. However
-.B torify(1)
-will use a default tsocks installation if one exists.
-.B Usewithtor(1)
-will only ever use a
-.B torsocks(8)
-installation.
-
-.SH SEE ALSO
-torsocks.conf(5)
-torsocks(1)
-usewithtor(1)
-
-.SH AUTHOR
-Robert Hogan (robert at roberthogan.net).This script is very similar to torify(1),
-provided by the Tor project.
\ No newline at end of file
More information about the tor-commits
mailing list