Re: 3 Hops
Now, what about exiting Hidden Services and then exiting the internet connection? Are those in 3's and is there way to exit the internet that is safe and a way that isn't recommended? Always wondered about that. Once backing out of the Tor network, what is revealed? Is my real IP address now in the clear or simply clear for anyone to see? I shut down Vidalia, exit and everything goes away. I don't understand this part of the question. --Roger Sorry. I was wondering if when leaving the internet (closing out the browser), is there one way that is safer to do this, meaning not revealing information about oneself, as opposed to other ways. Maybe precautions to take? I assumed that if I connect to the internet using Tor then I am somewhat anonymous in that my IP address shows one that isn't mine and shows it to be in a different country altogether. But when I shut down the browser or turn Tor/Vidalia off there is a sudden and complete shut down or them. Does this mean there isn't an address left hanging out there in the internet somewhere? Sorry I am not more computer literate and concise with my language. I keep reading but it just doesn't like to stick, unlike my waist. Something must show the router address shutting off, yes? I hope this was a bit more clear. -Original Message- From: Roger Dingledine a...@mit.edu To: or-talk@freehaven.net Sent: Wed, Nov 17, 2010 2:23 am Subject: Re: 3 Hops On Tue, Nov 16, 2010 at 04:05:11AM -0500, zzzjethro...@email2me.net wrote: Hello to all. I use the Tor Browser Bundle on a USB as I can only access the internet from cafes in the country in which I live. Using a proxy is now illegal here. I have several questions. I know that Tor uses three (3) hops once it has accessed the internet. If I use Tor to connect to the internet (as I'm assuming the extracted Bundle does) is that done in a 3 hop manner? Yes: Tor client - entry guard - middle hop - exit relay - website So your traffic goes through three Tor relays. When I am using Tor (in the Tor network), then my IP is shown as something other than mine and from a different country. Okay fine, according to torcheck.org But, what if I go directly to Hidden Services (the Hidden Wiki)? Is that done in 3 hops and what about inside, where the addresses are all .onion? Are those also done in 3's http://www.torproject.org/docs/hidden-services.html.en The circuit you use to the hidden service is six hops: Tor client - entry guard - middle hop - rendezvous point - middle hop* - middle hop* - entry guard* - Tor client* And the ones with stars are chosen by the hidden service's Tor, so it can get its anonymity from you. Basically, the hidden service design glues two Tor circuits together. and am I correct to assume that inside those .onion addresses everything is encrypted, meaning I am completely anonymous while in there? Everything is encrypted between your Tor client and the Tor client that offers the hidden service. No external parties get to read it. I wouldn't go so far as to call that completely anonymous, given that the hidden service gets to read it and you don't know who that is. Now, what about exiting Hidden Services and then exiting the internet connection? Are those in 3's and is there way to exit the internet that is safe and a way that isn't recommended? Always wondered about that. Once backing out of the Tor network, what is revealed? Is my real IP address now in the clear or simply clear for anyone to see? I shut down Vidalia, exit and everything goes away. I don't understand this part of the question. --Roger *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: IPTables transparent configuration
Curt, I will try and spur some discussion :) I'm not also sure that forcing connections to the tor port will work. Take for example an http request... you are now forcing that to a tor port, which wants to talk socks right? I would have thought you would need some sort of transparent http proxy setup which was configured to use tor for its external comms? Al - Reply message - From: Curt Shaffer cshaf...@gmail.com Date: Tue, Nov 16, 2010 18:19 Subject: IPTables transparent configuration To: or-t...@seul.org I have been searching the documentation and Internet for days on this setup. Let me give some background first. In this network (172.16.10.0/24) I have a couple of clients. Their default gateway is 172.16.10.1. This system is a Linux server. The Linux server has a LAN IP of 172.16.10.1 and a WAN IP of 10.0.0.23. This server is also running TOR. The WAN IP address of this system is actually being NATTED again by a firewall to an external IP address. I want all traffic on the 172.16.10.0/24 network to use this Linux server as their default gateway. In that gateway, I want IPTables to send all of the traffic from that subnet through TOR. If use IPTables to NAT the addresses like this: eth0=WAN eth1=LAN iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT General network connectivity works. If I introduce TOR with IPTables like this: iptables -t nat -A OUTPUT -p tcp -m tcp -j REDIRECT --to-ports 9040 iptables -t filter -A OUTPUT -p tcp -m tcp --dport 9040 -j ACCEPT TOR connectivity works from the Linux server, but all of the clients on the 172.16.10.0/24 network no longer work at all. No NAT to the general Internet, no TOR, no nothing. I'm thinking this may be an IPTables problem, but I wanted to post this to this list just to see if anyone else has accomplished such a setup. If you have, please let me know what I may be doing wrong. If you need more detailed information, please ask. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: IPTables transparent configuration
Thanks for the input Al. I actually got this to work a little bit after posting this. That always seems to be the case :). For the list and anyone else who may want to do this, I'm posting my iptables config here. sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE sudo iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT sudo iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT sudo iptables -t nat -A PREROUTING -p tcp -s 172.16.10.0/24 -j DNAT --to-destination 10.0.0.23:9040 sudo iptables -t nat -A PREROUTING -p icmp -s 172.16.10.0/24 -j DNAT --to-destination 10.0.0.23:9040 sudo iptables -t nat -A PREROUTING -p udp -s 172.16.10.0/24 -j DNAT --to-destination 10.0.0.23:53 Now I'm not sure I need all of this. I'm going to revisit it later today to ensure the best rule set, but I have verified that this works 100%. Curt On Nov 17, 2010, at 4:31 AM, alpal.mailingl...@gmail.com wrote: Curt, I will try and spur some discussion :) I'm not also sure that forcing connections to the tor port will work. Take for example an http request... you are now forcing that to a tor port, which wants to talk socks right? I would have thought you would need some sort of transparent http proxy setup which was configured to use tor for its external comms? Al - Reply message - From: Curt Shaffer cshaf...@gmail.com Date: Tue, Nov 16, 2010 18:19 Subject: IPTables transparent configuration To: or-t...@seul.org I have been searching the documentation and Internet for days on this setup. Let me give some background first. In this network (172.16.10.0/24) I have a couple of clients. Their default gateway is 172.16.10.1. This system is a Linux server. The Linux server has a LAN IP of 172.16.10.1 and a WAN IP of 10.0.0.23. This server is also running TOR. The WAN IP address of this system is actually being NATTED again by a firewall to an external IP address. I want all traffic on the 172.16.10.0/24 network to use this Linux server as their default gateway. In that gateway, I want IPTables to send all of the traffic from that subnet through TOR. If use IPTables to NAT the addresses like this: eth0=WAN eth1=LAN iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT General network connectivity works. If I introduce TOR with IPTables like this: iptables -t nat -A OUTPUT -p tcp -m tcp -j REDIRECT --to-ports 9040 iptables -t filter -A OUTPUT -p tcp -m tcp --dport 9040 -j ACCEPT TOR connectivity works from the Linux server, but all of the clients on the 172.16.10.0/24 network no longer work at all. No NAT to the general Internet, no TOR, no nothing. I'm thinking this may be an IPTables problem, but I wanted to post this to this list just to see if anyone else has accomplished such a setup. If you have, please let me know what I may be doing wrong. If you need more detailed information, please ask. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ smime.p7s Description: S/MIME cryptographic signature
Re: Tor 0.2.1.26-1~~lenny+1: segfault with libcryto.so.0.9.8
On Fri, Nov 12, 2010 at 5:49 PM, Paul Menzel paulepan...@users.sourceforge.net wrote: Dear Tor folks, I noticed that Tor had crashed on my system. I am using Debian Lenny with Tor 0.2.1.26-1~~lenny+1. The only thing I could find out about this crash is the following line running `dmesg`. $ dmesg […] [Several of these Treason uncloaked messages as you can see some seconds before the crash. I obfuscated the IP addresses.] [3301769.746795] TCP: Treason uncloaked! Peer xxx.xxx.xxx.xxx:60659/42859 shrinks window 1343914705:1343916145. Repaired. [3413085.371871] TCP: Treason uncloaked! Peer yyy.yyy.yyy.yyy:19595/45969 shrinks window 2416591117:2416591857. Repaired. [3604257.970658] tor[22506]: segfault at 21d4fc5 ip 7f1e78ba4ea6 sp 41188920 error 4 in libcrypto.so.0.9.8[7f1e78b21000+172000] [3604257.970707] type=1701 audit(1289305397.030:2): auid=4294967295 uid=102 gid=104 ses=4294967295 pid=22506 comm=tor sig=11 So it could also be libcrypto is the culprit. `libssl0.9.8` is running with `0.9.8g-15+lenny8` as version. Is that a known problem? What other information can I provide to solve that? Unfortunately I have not found out how to reproduce it yet. Without more information, there's not much info to go on there to diagnose the problem. Generally, to debug a segfault, we need a stack trace. To get one of those, make sure you're running Tor with coredumps enabled, and use gdb to get a trace if Tor crashes again. There are some decent online docs on how to do this; a little searching should turn them up. (You can ignore the Treason Uncloaked! junk. That's the Linux kernel being overly dramatic about peers that don't do TCP windows right or something.) hth, -- Nick *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor 0.2.1.26-1~~lenny+1: segfault with libcryto.so.0.9.8
On Wed, Nov 17, 2010 at 11:45:32AM -0500, Nick Mathewson wrote: I noticed that Tor had crashed on my system. I am using Debian Lenny with Tor 0.2.1.26-1~~lenny+1. The only thing I could find out about this crash is the following line running `dmesg`. Without more information, there's not much info to go on there to diagnose the problem. Generally, to debug a segfault, we need a stack trace. To get one of those, make sure you're running Tor with coredumps enabled, and use gdb to get a trace if Tor crashes again. On Debian, you want to apt-get install tor-dbg, so you get the symbols for the Tor binary. You might even have a core file already sitting in your datadirectory, which I think is /var/lib/tor/ --Roger *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: IPTables transparent configuration
Hi, Curt Shaffer wrote (17 Nov 2010 12:53:27 GMT) : sudo iptables -t nat -A PREROUTING -p tcp -s 172.16.10.0/24 -j DNAT --to-destination 10.0.0.23:9040 sudo iptables -t nat -A PREROUTING -p icmp -s 172.16.10.0/24 -j DNAT --to-destination 10.0.0.23:9040 sudo iptables -t nat -A PREROUTING -p udp -s 172.16.10.0/24 -j DNAT --to-destination 10.0.0.23:53 Tor is able to transport TCP only. If you really want these LAN boxes to *only* access the Internet over Tor, you have to forbid them anything other than TCP. If I am not mistaken, the rules you are showing us allow any UDP traffic to go out (without Tor) unless its destination port is !=53. I'm not sure this is really what you want to achieve. Feel free to have a look to the firewall we use in T(A)ILS as a source of inspiration: http://git.immerda.ch/?p=amnesia.git;a=blob;f=config/chroot_local-includes/etc/firewall.conf http://git.immerda.ch/?p=amnesia.git;a=blob;f=config/chroot_local-includes/etc/firewall6.conf Bye, -- intrigeri intrig...@boum.org | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr-fingerprint.asc | Every now and then I get a little bit restless | and I dream of something wild. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: IPTables transparent configuration
Hi, alpal.mailingl...@gmail.com wrote (17 Nov 2010 09:31:21 GMT) : I'm not also sure that forcing connections to the tor port will work. Take for example an http request... you are now forcing that to a tor port, which wants to talk socks right? He seems to be trying to redirect such a connection to the Tor transparent proxy he seems to have configured to listen on port 9040, rather than to the Tor Socks proxy that is generally configured on port 9050. Bye, -- intrigeri intrig...@boum.org | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr-fingerprint.asc | Then we'll come from the shadows. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: IPTables transparent configuration
I was looking to send all traffic through Tor. The UDP rule was taken off of the Tor Transparent Configuration documentation. I have Tor DNSPorts and DNSListenAddress set. I realize this was for DNS requests, but I was kinda hoping to pipe everything through. I will look at just dropping all other traffic. Thanks for sharing your link to your example config as well! Curt On Nov 17, 2010, at 12:37 PM, intrigeri wrote: Hi, Curt Shaffer wrote (17 Nov 2010 12:53:27 GMT) : sudo iptables -t nat -A PREROUTING -p tcp -s 172.16.10.0/24 -j DNAT --to-destination 10.0.0.23:9040 sudo iptables -t nat -A PREROUTING -p icmp -s 172.16.10.0/24 -j DNAT --to-destination 10.0.0.23:9040 sudo iptables -t nat -A PREROUTING -p udp -s 172.16.10.0/24 -j DNAT --to-destination 10.0.0.23:53 Tor is able to transport TCP only. If you really want these LAN boxes to *only* access the Internet over Tor, you have to forbid them anything other than TCP. If I am not mistaken, the rules you are showing us allow any UDP traffic to go out (without Tor) unless its destination port is !=53. I'm not sure this is really what you want to achieve. Feel free to have a look to the firewall we use in T(A)ILS as a source of inspiration: http://git.immerda.ch/?p=amnesia.git;a=blob;f=config/chroot_local-includes/etc/firewall.conf http://git.immerda.ch/?p=amnesia.git;a=blob;f=config/chroot_local-includes/etc/firewall6.conf Bye, -- intrigeri intrig...@boum.org | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr-fingerprint.asc | Every now and then I get a little bit restless | and I dream of something wild. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ smime.p7s Description: S/MIME cryptographic signature
Tor 0.2.2.18-alpha is out
Tor 0.2.2.18-alpha fixes several crash bugs that have been nagging us lately, makes unpublished bridge relays able to detect their IP address, and fixes a wide variety of other bugs to get us much closer to a stable release. https://www.torproject.org/download/download Packages will be appearing over the next few days. Changes in version 0.2.2.18-alpha - 2010-11-16 o Major bugfixes: - Do even more to reject (and not just ignore) annotations on router descriptors received anywhere but from the cache. Previously we would ignore such annotations at first, but cache them to disk anyway. Bugfix on 0.2.0.8-alpha. Found by piebeer. - Do not log messages to the controller while shrinking buffer freelists. Doing so would sometimes make the controller connection try to allocate a buffer chunk, which would mess up the internals of the freelist and cause an assertion failure. Fixes bug 1125; fixed by Robert Ransom. Bugfix on 0.2.0.16-alpha. - Learn our external IP address when we're a relay or bridge, even if we set PublishServerDescriptor to 0. Bugfix on 0.2.0.3-alpha, where we introduced bridge relays that don't need to publish to be useful. Fixes bug 2050. - Maintain separate TLS contexts and certificates for incoming and outgoing connections in bridge relays. Previously we would use the same TLS contexts and certs for incoming and outgoing connections. Bugfix on 0.2.0.3-alpha; addresses bug 988. - Maintain separate identity keys for incoming and outgoing TLS contexts in bridge relays. Previously we would use the same identity keys for incoming and outgoing TLS contexts. Bugfix on 0.2.0.3-alpha; addresses the other half of bug 988. - Avoid an assertion failure when we as an authority receive a duplicate upload of a router descriptor that we already have, but which we previously considered an obsolete descriptor. Fixes another case of bug 1776. Bugfix on 0.2.2.16-alpha. - Avoid a crash bug triggered by looking at a dangling pointer while setting the network status consensus. Found by Robert Ransom. Bugfix on 0.2.2.17-alpha. Fixes bug 2097. - Fix a logic error where servers that _didn't_ act as exits would try to keep their server lists more aggressively up to date than exits, when it was supposed to be the other way around. Bugfix on 0.2.2.17-alpha. o Minor bugfixes (on Tor 0.2.1.x and earlier): - When we're trying to guess whether we know our IP address as a relay, we would log various ways that we failed to guess our address, but never log that we ended up guessing it successfully. Now add a log line to help confused and anxious relay operators. Bugfix on 0.1.2.1-alpha; fixes bug 1534. - Bring the logic that gathers routerinfos and assesses the acceptability of circuits into line. This prevents a Tor OP from getting locked in a cycle of choosing its local OR as an exit for a path (due to a .exit request) and then rejecting the circuit because its OR is not listed yet. It also prevents Tor clients from using an OR running in the same instance as an exit (due to a .exit request) if the OR does not meet the same requirements expected of an OR running elsewhere. Fixes bug 1859; bugfix on 0.1.0.1-rc. - Correctly describe errors that occur when generating a TLS object. Previously we would attribute them to a failure while generating a TLS context. Patch by Robert Ransom. Bugfix on 0.1.0.4-rc; fixes bug 1994. - Enforce multiplicity rules when parsing annotations. Bugfix on 0.2.0.8-alpha. Found by piebeer. - Fix warnings that newer versions of autoconf produced during ./autogen.sh. These warnings appear to be harmless in our case, but they were extremely verbose. Fixes bug 2020. o Minor bugfixes (on Tor 0.2.2.x): - Enable protection of small arrays whenever we build with gcc hardening features, not only when also building with warnings enabled. Fixes bug 2031; bugfix on 0.2.2.14-alpha. Reported by keb. o Minor features: - Make hidden services work better in private Tor networks by not requiring any uptime to join the hidden service descriptor DHT. Implements ticket 2088. - Rate-limit the your application is giving Tor only an IP address warning. Addresses bug 2000; bugfix on 0.0.8pre2. - When AllowSingleHopExits is set, print a warning to explain to the relay operator why most clients are avoiding her relay. - Update to the November 1 2010 Maxmind GeoLite Country database. o Code simplifications and refactoring: - When we fixed bug 1038 we had to put in a restriction not to send RELAY_EARLY cells on rend circuits. This was necessary as long as relays using Tor 0.2.1.3-alpha through 0.2.1.18-alpha were active. Now remove this obsolete
P2P over Tor [was: Anomos - anonBT]
It's my understanding that BitTorrent is less of a bandwidth hog as it is a connections/circuits hog. These are expensive to create and you can't balance your BitTorrenting by hosting a high-bandwidth node because to have 0 net effect on the network, you'd have to host a circuit's worth of nodes for every circuit you're using for BitTorrent connections. Bandwidth is surely finite but I'd bet safe to calculate. I would think it easy to reach zero net, starting at minimally six times your use. Circuits are a separate issue. AFAIK, they are just consumers of state on the nodes... CPU, RAM, TCP, etc. I can see where adding a node [any node] in at 6x [or any x] would help distribute that load as well. Other than between the tracker, BT spawns a bunch of bandwith filled pipes, up to some number of peers limit in the app. What is, if any, the relationship between IPv4 TCP flows and Tor circuit usage? That could help calculate the replacement value for non-bandwidth node resources. Am I wrong, Tor Old Ones? I sure haven't got that far in reading to guess yet, so yeah, if someone has a hunch, that would be interesting. Maybe 6 nodes that add up to 6x bandwidth or something. Not sure about anyone else, but I do think that with the way things are going on the internet, more people will be looking to anonymous systems in general to supplant it for their 'filesharing' and other interests. That accumulation might be unstoppable. So hopefully those sorts of uses are being thought after and researched/planned/coded for. Thought about the non-bandwidth parts of the load some more... There doesn't seem to be a need to quantify it with a numerical estimate of what amount of resource giveback would yield a zero sum impact for those parts. Say you're using 'filesharing' in the form of BitTorrent. Your single PC, when operating as a non-exit relay [1], can surely handle many times the trivial sum of all the various non-bandwidth resources described above that you would use along the way. Think of simulating a TorNet by running all the needed directories, nodes and operations bound to IP aliases on one PC. Conservatively say [3] you will have up to 100 P2P circuits at 6 hops each... Any PC should be able to handle that entire load with lots of headroom. So long as users are covering their bandwidth with giveback [1], I think it's safe to assume the rest of their overhead is also covered by the addition of that node to the network. I no longer think the standard reply/FAQ regarding such uses of Tor, excepting [2], should be an unqualified: Tor can't handle it, so don't. The answer should be that... so long as such giveback [1] is: - understood by users to be a necessary 'techical' condition to support their use of Tor for bulk transfer. - indeed provided back to the network as a 'moral' condition by those same users. ... they should then feel free to use Tor for whatever they want. BitTorrent, P2P, FTP, streaming media, chat, etc. And OnionCat is the shim that will allow the apps to communicate seamlessly. Though not as simple a response, and requiring donation by the user, it seems to be the more reasoned one. Further thoughts welcomed. [1] It's already established that in order for your use of Tor bandwidth to be zero sum (in the Hidden Service -- Hidden Service case) you need to give back at least 6x your use. So you will already be running said relay (for the purpose of bandwidth giveback). [2] Isn't there a proposal out there to better handle magnitudes more users [and avoid shutdown points] by getting rid of the directories and self-hosting the TorNet into a DHT or something? [3] As the average bandwidth that most users [dsl, cable] will be able to give back is small, transfers will be slow anyways. Which may limit adoption [P2P peer counts]. Regardless, the limiting factor is really only bandwidth because (dice up the giveback/6 you can legitimately use... amongst P2P peer circuits however you want, ie): dsl/cable = 1 x 256Kb/6 = 10 x 25.6Kb/6 = 100 x 2.56Kb/6 *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Scalability and fairness [was: P2P over Tor [was: Anomos - anonBT]]
On Wed, Nov 17, 2010 at 3:02 PM, grarpamp grarp...@gmail.com wrote: ... So long as users are covering their bandwidth with giveback [1], I think it's safe to assume the rest of their overhead is also covered by the addition of that node to the network. there's always a catch. ;) ... [1] It's already established that in order for your use of Tor bandwidth to be zero sum (in the Hidden Service -- Hidden Service case) you need to give back at least 6x your use. So you will already be running said relay (for the purpose of bandwidth giveback). [2] Isn't there a proposal out there to better handle magnitudes more users [and avoid shutdown points] by getting rid of the directories and self-hosting the TorNet into a DHT or something? Tor would become something else, perhaps UDP Tor. there has been more written on that subject than i can do justice here. i'm fond of DTLS signalling for encapsulated IPsec telescopes with SFQ and DLP transport for multi-homed SCTP endpoints, but that is just one of many possibilities. a grand unified datagram Tor spec has yet to be written... *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor 0.2.2.18-alpha is out
On Wed, 17 Nov 2010 17:05 -0500, Roger Dingledine a...@mit.edu wrote: Tor 0.2.2.18-alpha fixes several crash bugs that have been nagging us lately, makes unpublished bridge relays able to detect their IP address, and fixes a wide variety of other bugs to get us much closer to a stable release. https://www.torproject.org/download/download Thanks. The Tor-only packages for OSX PPC seem to have disappeared since the website was revamped (nice look btw). Is there a more recent version than 0.2.2.15-alpha available to test? GD -- http://www.fastmail.fm - Accessible with your email software or over the web *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor 0.2.2.18-alpha is out
On Nov 17, 2010, at 7:38 PM, Geoff Down wrote: Is there a more recent version than 0.2.2.15-alpha available to test? GD I'm interested in this as well, as issues with (read: nasty emails from) one of the net admins at my local ISP have reduced me to running only my Orlando-based PPC exit. Normally I'm anal-retentive about keeping up with the latest updates, so being passed over by the past few releases has made me... twitchy. ~Justin Aplin
Re: Tor 0.2.2.18-alpha is out
On Wed, Nov 17, 2010 at 07:50:05PM -0500, Roger Dingledine wrote: If by Tor-only packages you mean the old expert packages, we decided to drop support for them: For background, see https://trac.torproject.org/projects/tor/ticket/1274 Sounds like we should do a better job of declaring a policy on what platforms we're trying to make work, and a better job of getting feedback from users when we ponder changes in this policy. Last I heard, Nick was working on a proposed policy draft so we can at least get a handle on where things stand currently. The challenge is that we have neither enough developers nor enough (trustworthy) build machines to support everything out there. --Roger *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Scalability and fairness [was: P2P over Tor [was: Anomos - anonBT]]
So long as users are covering their bandwidth with giveback [1], I ... - indeed provided back to the network as a 'moral' condition by those same users. ... case) you need to give back at least 6x your use. So you will already there's always a catch. ;) Heh, yeah, no one ever suggested this would happen, as the leecher mindset abounds :) It just seemed useful to actually ask for, examine and collate the parameters under which it *could* happen successfully. And the areas where Tor, or any other anonymous system, is permanently incapable as a limitation of architecture. Or where the system actually could be enhanced to better support what some users are already going to use it for regardless of disencouragement. It should be noted that one reason people ask about using anon systems for such traffic is because they feel risk when doing so in the clear. Either as consumer, distributor or participant. Being anonymous may actually be the key they need that allows them to run the seed/server/distributor side without fear. In other words... I'd bet it's called 'filesharing' because most people actually *do* want to give back and share, albeit safely. Is anonymity the missing link to the global filesharing utopia invisioned be all the various sharing systems? Who knows. We'll find out. [2] Isn't there a proposal out there to better handle magnitudes more users [and avoid shutdown points] by getting rid of the directories and self-hosting the TorNet into a DHT or something? Tor would become something else, perhaps UDP Tor. there has been more written on that subject than i can do justice Wish the mbox or maildir archives were available/mirrored for easy search, reading, reference and reply using native mail clients :) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor 0.2.2.18-alpha is out
On Nov 17, 2010, at 7:55 PM, Roger Dingledine wrote: On Wed, Nov 17, 2010 at 07:50:05PM -0500, Roger Dingledine wrote: If by Tor-only packages you mean the old expert packages, we decided to drop support for them: For background, see https://trac.torproject.org/projects/tor/ticket/1274 Sounds like we should do a better job of declaring a policy on what platforms we're trying to make work, and a better job of getting feedback from users when we ponder changes in this policy. Last I heard, Nick was working on a proposed policy draft so we can at least get a handle on where things stand currently. The challenge is that we have neither enough developers nor enough (trustworthy) build machines to support everything out there. I missed that line in the OP. Since my particular machine runs a single user and is logged in 24/7, I simply run the Vidalia package as a relay and set it to start on login. Since this package is the one I imagine the majority of Tor users on OSX will be running, it would be nice to see it updated to 2.2.18a/0.2.10. Not to mention that the switch to Intel processors was a relatively recent one, as far as computer turnover goes, and there are still plenty of users out there running PPC machines. I agree that dropping the expert packages might be a good idea, but I don't see a reason that the Vidalia bundles should fall behind. ~Justin Aplin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor 0.2.2.18-alpha is out
On Wed, 17 Nov 2010 20:11:44 -0500 Justin Aplin jmap...@ufl.edu wrote: I agree that dropping the expert packages might be a good idea, but I don't see a reason that the Vidalia bundles should fall behind. The reason for the delay in packages is the powerpc build machine died a melting death when the internal fan died over a weekend. A donor gave us a powerpc mac mini for a build machine running 10.5. It's in process of being turned into the powerpc build machine. Alternatively, building from source is very easy once the dependencies are installed. I'm not sure how well 10.5 binaries work on 10.3 and 10.4 (even with osx compiles set for 10.3 and 10.4 compatibility). I guess we'll find out. -- Andrew pgp 0x31B0974B *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Scalability and fairness [was: P2P over Tor [was: Anomos - anonBT]]
On Wed, 17 Nov 2010 20:03:58 -0500 grarpamp grarp...@gmail.com wrote: Wish the mbox or maildir archives were available/mirrored for easy search, reading, reference and reply using native mail clients :) ...I wish people would stop cross-posting between -dev and -talk...;) -- Andrew pgp 0x31B0974B *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Scalability and fairness [was: P2P over Tor [was: Anomos - anonBT]]
On Wed, Nov 17, 2010 at 5:20 PM, Andrew Lewman and...@torproject.org wrote: ...I wish people would stop cross-posting between -dev and -talk...;) mea culpa; i shall curb my reply-all enthusiasm! grarpamp: i'll follow this up with links for various UDP Tor papers and discussions. i've got a bunch of bookmarks somewhere... *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Scalability and fairness [was: P2P over Tor [was: Anomos - anonBT]]
Wish the mbox or maildir archives were available/mirrored for easy search, reading, reference and reply using native mail clients :) ...I wish people would stop cross-posting between -dev and -talk...;) Hey, I might just be inclined to trade detailed examination and separation of message content, as well as what comes up in 'group reply' to prior messages, for that ;-) I do miss a handful now and then. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Scalability and fairness [was: P2P over Tor [was: Anomos - anonBT]]
grarpamp: i'll follow this up with links for various UDP Tor papers and discussions. i've got a bunch of bookmarks somewhere... You don't have to or anything like that, or maybe for the wiki. I still need to check out the project site and AnonBib more and will probably scrape the web archives into a maildir someday too. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
How to install Tor on iPod touch 4th gen. w/ iOS 4.1?
Hi, I would like to install Tor on my iPod touch 4th gen. with iOS 4.1. The iPod touch has been jailbreaked with limera1n. After googled on the web for a while, I found this instruction [0]. but the install package download link [1] seems is broken now. So is there anyone has a alternative download link, or, is there any better way to make Tor running on my iPod touch? Thanks in advance. Best Regards. [0] http://sid77.slackware.it/iphone/howto/ [1] http://sid77.slackware.it/static/sid77.slackware.it_1-2_iphoneos-arm.deb *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
