[or-cvs] r20441: {arm} Limiting readme line length to 80 characters. (arm/trunk)

atagar at seul.org atagar at seul.org
Sat Aug 29 02:23:53 UTC 2009


Author: atagar
Date: 2009-08-28 22:23:53 -0400 (Fri, 28 Aug 2009)
New Revision: 20441

Modified:
   arm/trunk/readme.txt
Log:
Limiting readme line length to 80 characters.



Modified: arm/trunk/readme.txt
===================================================================
--- arm/trunk/readme.txt	2009-08-29 02:21:36 UTC (rev 20440)
+++ arm/trunk/readme.txt	2009-08-29 02:23:53 UTC (rev 20441)
@@ -4,9 +4,17 @@
 Project page: www.atagar.com/arm
 
 Description:
-Command line application for monitoring Tor relays, providing real time status information such as the current configuration, bandwidth usage, message log, connections, etc. This uses a curses interface much like 'top' does for system usage. The application is intended for command-line aficionados, ssh connections, and anyone stuck with a tty terminal for checking their relay's status. Releases should be stable so if you manage to make it crash (or have a feature request) then please let me know!
+Command line application for monitoring Tor relays, providing real time status 
+information such as the current configuration, bandwidth usage, message log, 
+connections, etc. This uses a curses interface much like 'top' does for system 
+usage. The application is intended for command-line aficionados, ssh 
+connections, and anyone stuck with a tty terminal for checking their relay's 
+status. Releases should be stable so if you manage to make it crash (or have a 
+feature request) then please let me know!
 
-The project was originally proposed in 2008 by Jacob and Karsten (http://archives.seul.org/or/dev/Jan-2008/msg00005.html). An interview by Brenno Winter discussing the project is available at:
+The project was originally proposed in 2008 by Jacob and Karsten 
+(http://archives.seul.org/or/dev/Jan-2008/msg00005.html). An interview by 
+Brenno Winter discussing the project is available at:
   http://www.atagar.com/arm/HFM_INT_0001.mp3
 
 Requirements:
@@ -22,25 +30,53 @@
 FAQ:
 > Why is it called 'arm'?
 
-Simple - because it makes the command short and memorable. Terminal applications need to be easy to type (like 'top', 'ssh', etc), and anything longer is just begging command-line aficionados to alias it down. I chose the meaning of the acronym ('anonymizing relay monitor') afterward.
+Simple - because it makes the command short and memorable. Terminal 
+applications need to be easy to type (like 'top', 'ssh', etc), and anything 
+longer is just begging command-line aficionados to alias it down. I chose the 
+meaning of the acronym ('anonymizing relay monitor') afterward.
 
-> If you're listing connections then what about exit nodes? Won't this include people's traffic?
+> If you're listing connections then what about exit nodes? Won't this include 
+people's traffic?
 
-While arm isn't intended to be a sniffer it does provide real time connection data which, for exit nodes, includes the endpoints being visited through you. Unfortunately this is pretty unavoidable. The control port doesn't provide a means of distinguishing those connections and trying to figure it out by correlating against consensus data has proved pretty inaccurate.
+While arm isn't intended to be a sniffer it does provide real time connection 
+data which, for exit nodes, includes the endpoints being visited through you. 
+Unfortunately this is pretty unavoidable. The control port doesn't provide a 
+means of distinguishing those connections and trying to figure it out by 
+correlating against consensus data has proved pretty inaccurate.
 
-That said, this really isn't much of a concern. For Tor users the real threats come from things like Wireshark and MITM attacks on their unencrypted traffic. Simply seeing an unknown individual's endpoints is no great feat in itself. Just attach netstat to a cron job and voilà! You've got a sniffer that's just as mighty as arm.
+That said, this really isn't much of a concern. For Tor users the real threats 
+come from things like Wireshark and MITM attacks on their unencrypted traffic. 
+Simply seeing an unknown individual's endpoints is no great feat in itself. 
+Just attach netstat to a cron job and voilà! You've got a sniffer that's just 
+as mighty as arm.
 
 > Is it harmful to share the information provided by arm?
 
-Not really, but it's discouraged. The original plan for arm included a special emphasis that it wouldn't log any data. The reason is that if a large number of relay operators published the details of their connections then correlation attacks could break Tor user's anonymity. Just show some moderation in what you share and it should be fine.
+Not really, but it's discouraged. The original plan for arm included a special 
+emphasis that it wouldn't log any data. The reason is that if a large number 
+of relay operators published the details of their connections then correlation 
+attacks could break Tor user's anonymity. Just show some moderation in what 
+you share and it should be fine.
 
 > Is there any chance that arm will leak data?
 
-Yes - arm is a passive listener with one exception. The second page (connections) provides the hostnames of Tor relays you're connected to. This means reverse DNS lookups which, if monitored, could leak your current connections to an eavesdropper. However, lookups are only made upon request (when showing connection details or listing connections by hostname) and you can disable lookups entirely with 'r' - see the page's help for the current status.
+Yes - arm is a passive listener with one exception. The second page 
+(connections) provides the hostnames of Tor relays you're connected to. This 
+means reverse DNS lookups which, if monitored, could leak your current 
+connections to an eavesdropper. However, lookups are only made upon request 
+(when showing connection details or listing connections by hostname) and you 
+can disable lookups entirely with 'r' - see the page's help for the current 
+status.
 
-That said, this is a non-issue. ISPs and anyone sniffing your connection already has this data - the only difference is that instead of saying "I am talking to x" you're saying "I'm talking to x. who's x?"
+That said, this is a non-issue. ISPs and anyone sniffing your connection 
+already has this data - the only difference is that instead of saying "I am 
+talking to x" you're saying "I'm talking to x. who's x?"
 
-> When arm starts it gives "Unable to resolve tor pid, abandoning connection listing"... why?
+> When arm starts it gives "Unable to resolve tor pid, abandoning connection 
+listing"... why?
 
-If you're running multiple instances of tor then arm needs to figure out which pid belongs to the open control port. If it's running as a different user (such as being in a chroot jail) then it's probably failing due to permission issues. Arm still runs, just no connection listing or ps stats.
+If you're running multiple instances of tor then arm needs to figure out which 
+pid belongs to the open control port. If it's running as a different user 
+(such as being in a chroot jail) then it's probably failing due to permission 
+issues. Arm still runs, just no connection listing or ps stats.
 



More information about the tor-commits mailing list