Re: Help Iranian dissidents
On Wed, Jun 24, 2009 at 07:02:32PM -0400, Bill McGonigle wrote: Step 2) Wait for Tor Project to do the technical work. There could be at least four reasons: 1) they don't believe it. They're just throwing ideas at the wall, to see who will do free work for them. They wouldn't spend a dime of their own money to do it. I don't know who they are, but the only way to cook up a bunch of throwaway Tor nodes and distribute them for creative installation is someone who has the spare cash to buy a few hundred to thousand pieces of hardware, and give them away. In the case of Sheeva, that's some 10 kUSD for a 1000 units (probably less due to mass rebate). I don't have such money, but since it was my idea, and Ubuntu already supports the Sheeva I'm willing to plug an USB drive and set up a self hosting environment to build a Tor package or a system image based on Ubuntu if someone sends me a Sheevaplug. However, it would be probably trivial to do that for a seasoned Tor developer, and it's also an issue of trust. Would you accept system images from random strangers? 2) lack of capital They think it's a good idea, but don't have the funds to allocate/acquire the manpower to get it done. If only they were better at raising money they'd get it done. Summer of Code, perhaps other outlets for these folks? 3) ideological inefficiency They think it's a tor feature, Tor Project alone should do it, even if they have the capital and believe the business case. I trust in individual self-interest too much to believe this is real. 4) Confusion They'd do it themselves but it's not obvious what they need to do. Being opaque, they work on other things first. I suspect this is possible, so I started a wiki page that could, in a future form, be useful to this class: https://wiki.torproject.org/noreply/TheOnionRouter/EmbeddedTips That is an excellent idea. It would be great if those with experience could add info/links here, especially architectural elements with broad commonality among potential targets. -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
Re: Help Iranian dissidents
On Wed, June 24, 2009 19:41, Bill McGonigle wrote: IIRC, somebody already did a tor mod for the first version. Long time ago, I torified its traffic for fun: http://sid77.livejournal.com/2007/07/16/ the problem with running a tor node directly on top of it is the limited number of resources, at least on those old versions of the router. (maybe I should try with a minimal openwrt... hmm...) -- Marco Bonetti BT3 EeePC enhancing module: http://sid77.slackware.it/bt3/ Slackintosh Linux Project Developer: http://workaround.ch/ Linux-live for powerpc: http://workaround.ch/pub/rsync/mb/linux-live/ My GnuPG key id: 0x86A91047
Re: Hetzner
thus Hannah Schroeter spake: Hi! Hi, On Thu, Jun 18, 2009 at 05:52:08AM +0200, Timo Schoeler wrote: So am I, running a middle node. However, for months now I'm thinking of reverting it to an exit node as the situation that everyone runs a middle node, but no one dares to run an exit node just lets TOR die. Hidden services will run very fine with only middleman and bridge nodes. that's true, for sure. However, we create a parallel world doing this. From a metaphysical POV (IMHO), TOR is (partly) existing to defend civil rights. But to be able to do this, it must exist not only in a 'parallel world'. Losing connection to 'this world' (today's internet) would mean to lose the 'war'. Best, Timo Kind regards, Hannah.
Re: Hetzner
On Thu, Jun 25, 2009 at 10:28:23AM +0200, Timo Schoeler wrote: Hidden services will run very fine with only middleman and bridge nodes. that's true, for sure. However, we create a parallel world doing this. That's not a bug, it's a feature. From a metaphysical POV (IMHO), TOR is (partly) existing to defend civil rights. But to be able to do this, it must exist not only in a The free, uncesored Intenet is dead. The sooner we acknowledge this, and realize that we need an anonymizing publishing layer on top of that the better. I keep harping about that since early 1990s. Surisingly little has happened since. 'parallel world'. Losing connection to 'this world' (today's internet) would mean to lose the 'war'. Things are never quite black and white. There is a network that is censored and sniffed but also accountable, and hence less prone to abuse. On top of that you can have a network that anonymous/pseudonymous, unaccountable, and slightly abusive. There's a place for both of them to exist. -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
Re: ShutdownWaitLength vs. 'restart' in init scripts
On Tue, Jun 23, 2009 at 12:47:56AM -0400, Bill McGonigle wrote: I noticed a problem with the init script I have with the tor package on Fedora 10. Is this with the tor rpm shipped by Fedora? We don't support (or use, or like, or recommend) the fedora tor rpm. The 'restart' command (just a start and stop) sends a -INT to the running process, but doesn't account for ShutdownWaitLength. Check out how the torctl that we ship in the rpms handles that: https://git.torproject.org/checkout/tor/master/contrib/torctl.in It basically kills it, and then tries to kill it even harder if it doesn't die. That's probably not the right answer. The right answer imo is how the deb package does it: https://git.torproject.org/checkout/tor/master/debian/tor.init Check out the wait_for_deaddaemon function: it basically checks each second whether the process is still around, and returns when it's gone (or 60 seconds have passed). So I guess if you raise your ShutdownWaitLength, you'll want to tweak the script. But that still seems better than the kill -INT, sleep 1, kill -9 strategy the rpm uses. Patches to the torctl script greatly appreciated. :) or, perhaps even better: fixing the server shutdown process so the old server can't take out the new server. Can you clarify what happens here? 'tor stop' finishes but Tor is still running, so then 'tor start' fails to launch a new Tor, and then the old Tor exits, and then you have no Tor running but you think you do? Thanks! --Roger
Re: Hetzner
thus Eugen Leitl spake: On Thu, Jun 25, 2009 at 10:28:23AM +0200, Timo Schoeler wrote: Hidden services will run very fine with only middleman and bridge nodes. that's true, for sure. However, we create a parallel world doing this. That's not a bug, it's a feature. I never said that it's a bug. I just said that if we drop the connection to the 'normal' internet we lost the fight. Things like the french revolution were without avail. From a metaphysical POV (IMHO), TOR is (partly) existing to defend civil rights. But to be able to do this, it must exist not only in a The free, uncesored Intenet is dead. So, we already lost it. The sooner we acknowledge this, and realize that we need an anonymizing publishing layer on top of that the better. The problem is that TOR (and any other system accomplishing this target) excludes the 'masses', if one may say so. I keep harping about that since early 1990s. Surisingly little has happened since. 'parallel world'. Losing connection to 'this world' (today's internet) would mean to lose the 'war'. Things are never quite black and white. A few things are, some are not. Have you ever seen a girl being 'a little big pregnant'? ;) There is a network that is censored and sniffed but also accountable, and hence less prone to abuse. On top of that you can have a network that anonymous/pseudonymous, unaccountable, and slightly abusive. There's a place for both of them to exist. True. Timo
Re: Hetzner
On Thu, Jun 25, 2009 at 10:50:08AM +0200, Timo Schoeler wrote: I never said that it's a bug. I just said that if we drop the connection to the 'normal' internet we lost the fight. Things like the french It is more useful as seeing it as two unrelated networks. That one is implemented as a virtual layer on top of another isn't that relevant. The point is that you can use two (or more, such as you can use IPv4 and IPv6 on dual-stack setups, and VPNs) networks simultaneously. The free, uncesored Intenet is dead. So, we already lost it. If you want to see it in such stark terms, yes. However, it's still perfectly possible to access and publish information uncensored. Our task should be to remove the friction, to make it easier for people. So far, operating anonymizing networks like Tor isn't illegal in most locations, yet. Where it is illegal (frequently, by use of unconstituional laws, which makes it high treason, and explicitly allowing armed resistance if everything else fails in some constitutions, like e.g. the German Grundgesetz), it is of course morally permissible to use guerilla tactics. A simple solution for that case would be to use a self-propagating Tor worm, which infects systems, causes a fraction of them to become middleman and others exits. Such a system would be self-propagating, and trying to shut the nodes down would resemble a game of whack-a-mole. The problem is that TOR (and any other system accomplishing this target) excludes the 'masses', if one may say so. In totalitarian countries, where means of publishing (such as xerox machines) were outlawed a small fraction was still capable obtaining censored information. Resistance in face of state threats isn't for the weak of heart. If anonymous access is made illegal I don't expect more than 1-5% of the population of using it. -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
nanog tor talk
FYI, there is a brief flare up of discussion on the North American Network Operators' Group (NANOG) mailing list about Tor. If interested, the thread in the web accessible archives kicks off here - http://mailman.nanog.org/pipermail/nanog/2009-June/011485.html -Andrew
Re: many new relays
--- On Wed, 6/24/09, 150% jump, in such a short time. Not sure I'd welcome that so soon. I don't have a copy of the old cache files from before the jump began. But if someone does, consider putting them up on a filehost or analyzing it a bit more. This really should be looked at in more detail before chalking it up to .ir or friendlies. And how does this correspond to prior slashdot/digg jumps. netblock/isp/hostname/whois/country platform nickname policy bandwidth contacts uptime etc No discussion or comments on this? What does it mean?
Re: nanog tor talk
On 06/25/2009 02:45 PM, Andrew S. Lists wrote: FYI, there is a brief flare up of discussion on the North American Network Operators' Group (NANOG) mailing list about Tor. And Steven Bellovin replied, http://mailman.nanog.org/pipermail/nanog/2009-June/011521.html and started a new thread, http://mailman.nanog.org/pipermail/nanog/2009-June/thread.html#11521 -- Andrew Lewman The Tor Project pgp 0x31B0974B Website: https://torproject.org/ Blog: https://blog.torproject.org/ Identica/Twitter: torproject
Re: ShutdownWaitLength vs. 'restart' in init scripts
On 06/25/2009 04:39 AM, Roger Dingledine wrote: Is this with the tor rpm shipped by Fedora? yes We don't support (or use, or like, or recommend) the fedora tor rpm. OK. Is this ideological, or because it's no good? I can work to fix the latter (I don't think anybody at Fedora wants a bad RPM). In my experience automatic security updates [aside: which are currently borked for the Fedora tor package, but that's another story, which I think I've gotten the right people to resolve at this point] are worth many trade-offs. People just don't do security updates the way we wish they would. The right answer imo is how the deb package does it: https://git.torproject.org/checkout/tor/master/debian/tor.init Check out the wait_for_deaddaemon function: it basically checks each second whether the process is still around, and returns when it's gone (or 60 seconds have passed). this makes sense. So I guess if you raise your ShutdownWaitLength, you'll want to tweak the script. But that still seems better than the kill -INT, sleep 1, kill -9 strategy the rpm uses. agreed, do you see any reason not to extract ShutdownWaitLength from the config file? or, perhaps even better: fixing the server shutdown process so the old server can't take out the new server. Can you clarify what happens here? 'tor stop' finishes but Tor is still running, so then 'tor start' fails to launch a new Tor, and then the old Tor exits, and then you have no Tor running but you think you do? OK, so to be more clear: Let's call the old tor process we're taking down torA and the new one we want torB. 1) torA is sent an INT to tell it to stop. It begins its shutdown process. 2) The init script isn't waiting or watching, so it starts torB. Because torA is no longer bound to its listener port, torB can start up just fine. The init script is out of the picture now. 3) torA reaches ShutdownWaitLength time. It kills itself. ---guess 4) torB gets taken out by torA's final shutdown. At this point the init script's lockfiles reflect torB running, when actually no tor is running. So it behaves inappropriately. I realize there's no point in addressing the current Fedora RPM init script here, but assuming 4) is correct, it would seem that however torA is finding torB, it shouldn't do it that way. -Bill -- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 http://www.bfccomputing.com/Cell: 603.252.2606 Twitter, etc.: bill_mcgonigle Page: 603.442.1833 Email, IM, VOIP: b...@bfccomputing.com Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf
