June 2011 - tor-dev - lists.torproject.org

The Torouter and the DreamPlug
by Runa A. Sandvik 11 Jun '11

11 Jun '11

Hi everyone, DreamPlug is a new plug computer from GlobalScale Technologies: http://www.globalscaletechnologies.com/c-5-dreamplugs.aspx. The spec looks good, it runs Ubuntu by default and it doesn't cost too much. I thought that the DreamPlug was going to be very user friendly and a potential candidate for the Torouter project. (Maybe) I was wrong. When the SheevaPlug came out a couple of years ago, it shipped with a web interface that enabled users to change various network options. I thought the DreamPlug would ship with some kind of interface as well (and my plan was to just plug in a Tor page). This is not the case; it ships with lighthttpd by default and displays a static and very simple placeholder page on 192.168.1.1. If we want to use the DreamPlug for the Torouter, we will have to write a web interface for easy configuration of Tor. The interface should probably also provide options to better secure the DreamPlug. Downloading and installing Tor isn't a problem, but the configuration side of things can be tricky for users who aren't used to the command line. Thoughts? Comments? Thanks, -- Runa A. Sandvik

14 44

Too many cooks spoil the broth---or: how about we clean up the wiki?
by Karsten Loesing 11 Jun '11

11 Jun '11

Hello everyone, <rant>Today I looked at our wiki to add roadmaps for some products and realized what a mess the wiki is. This wasn't obvious to me, because I stopped using the wiki long ago, well, because it was such a mess. But boy, it has become worse!</rant> I think the main problem is that there's no obvious structure in the wiki, so everyone just adds their stuff anywhere, maybe thinking that someone else will move it to the right place. The other problem is that there's no such person cleaning up. Here's my plan: I'd like to rename (possibly a lot of) wiki pages so that the naming scheme implies a kind of wiki structure. I'd also add a page saying where stuff should go, and we'll beat up everyone not adhering to the structure in a joint effort. By the way, what happens if we rename wiki pages? I guess Trac will update all internal links, but external links (e.g., from the website) will be broken? We could fix our own website, but other websites would still be broken. How bad would that be? Here's a suggested naming scheme. In this scheme, there are three top-level directories (or rather, page prefixes): - doc/ contains all documentation for Tor users, relay operators, and the community in general. This is the stuff that people would usually expect in a wiki. - org/ contains deliverables promised to our sponsors, meeting plans, product roadmaps, project progress, etc. This stuff is in the wiki to make Tor development as transparent as possible. In theory, non-developers wouldn't require write permissions to these pages. - trac/ contains Trac's own documentation that it generously dumped into our Tor wiki. In theory, nobody would require write permissions to these pages. I'll go through the existing wiki pages and say where they should go. The following pages would move to doc/ (e.g., "DNS Hijacking" would become "doc/DNS Hijacking"): DNS Hijacking HTTPSEverywhere/SSLObservatorySubmission ImportantGoogleChromeBugs OnionCat TorALaymansGuide TorFAQUnanswered TorInChroot TorToggle UsingTorWithVservers badRelays badRelays/trotskyIps talks talks/MoscowState2010 TheOnionRouter TheOnionRouter/AnonymousPublicSpeech TheOnionRouter/BIND TheOnionRouter/BandwidthLimitChangeController TheOnionRouter/BlockNonTorTrafficDebian TheOnionRouter/BlockingDiagnostics TheOnionRouter/BlockingIrc TheOnionRouter/CentralizedTorServer TheOnionRouter/ConnectOverSSH TheOnionRouter/ContestEntries TheOnionRouter/ContestEntries/DesignFeedback TheOnionRouter/CronBandwidthLimit TheOnionRouter/DebianLive TheOnionRouter/EmbeddedTips TheOnionRouter/ExitEnclave TheOnionRouter/FAQUnanswered TheOnionRouter/FireFoxTorPerf TheOnionRouter/FirefoxRemoteDNS TheOnionRouter/GoodBadISPs TheOnionRouter/Gsoc2009 TheOnionRouter/Gsoc2009/ThandyTorrents TheOnionRouter/HiddenServiceNames TheOnionRouter/HowTo_post_on_or-talk_mailinglist TheOnionRouter/LegalStuff TheOnionRouter/LiveCDBestPractices TheOnionRouter/MacOSXUpgradeToTrunk TheOnionRouter/OpenbsdChrootedTor TheOnionRouter/OpenbsdChrootedTorControlScript TheOnionRouter/OpenbsdChrootedTorScript TheOnionRouter/OperationalSecurity TheOnionRouter/Portable_Tor TheOnionRouter/PreventingDnsLeaksInTor TheOnionRouter/Preventing_Tor_DNS_Leaks TheOnionRouter/PrivoxyConfig TheOnionRouter/PrivoxyPatches TheOnionRouter/Publicfile TheOnionRouter/ReducedExitPolicy TheOnionRouter/RemailingAndTor TheOnionRouter/RunTwoPrivoxys TheOnionRouter/SshPortForwardedTor TheOnionRouter/SummerOfCode TheOnionRouter/SupportPrograms TheOnionRouter/SupportPrograms/Polipo TheOnionRouter/TSocksPatches TheOnionRouter/TermsObserved TheOnionRouter/TorAbuseTemplates TheOnionRouter/TorExitNodeHowto TheOnionRouter/TorGuideUniversities TheOnionRouter/TorInChroot TheOnionRouter/TorInChroot-new TheOnionRouter/TorInTheMedia TheOnionRouter/TorMirror TheOnionRouter/TorOnDebian/PackagesForArchitectures TheOnionRouter/TorShirt TheOnionRouter/TorWin32TorWS TheOnionRouter/TorALaymansGuide TheOnionRouter/TorDNSExitList TheOnionRouter/TorFAQ TheOnionRouter/TorIPCOP TheOnionRouter/TorifyHOWTO TheOnionRouter/TorifyHOWTO/EMail TheOnionRouter/TorifyHOWTO/FTP TheOnionRouter/TorifyHOWTO/InstantMessaging TheOnionRouter/TorifyHOWTO/IrcSilc TheOnionRouter/TorifyHOWTO/Misc TheOnionRouter/TorifyHOWTO/Misc/Putty TheOnionRouter/TorifyHOWTO/Putty TheOnionRouter/TorifyHOWTO/SystracePolicy TheOnionRouter/TorifyHOWTO/WebBrowsers TheOnionRouter/Torouter TheOnionRouter/Torouter_notes TheOnionRouter/Torwin32DNS TheOnionRouter/Transocks TheOnionRouter/TransocksifyingTor TheOnionRouter/TransparentProxy TheOnionRouter/VMWareThroughTor TheOnionRouter/VerifyingSignatures TheOnionRouter/WebProxyHowto TheOnionRouter/Wikipedia TheOnionRouter/WindowsBufferProblems CodingForTor CodingForTor/CodingInC CodingForTor/CodingInR CodingForTor/LoggingAndDocumentation CodingInC CoreTorTracUsers build build/AddingBuildSlaves build/BuildSignoff build/ListOfPackages dev/HowToReleaseTor dev/SupportPolicy dev/SupportPolicy_v2 The following pages would move to org/meetings/: 2010TorAnnualDevMeeting 2011MiniDevMeeting 2011MiniDevMeeting/notes 2011StockholmHackfest 2011TorAnnualDevMeeting The product roadmaps that are not there yet would go into org/roadmaps/. Everything related to project management would go into org/projects/: TorAgileProcess projects/HowWeDoProjectManagement projects/ProjMgt/SetUpProjectMgt Products projects/ProductsandAssignments projects projects/2009FinancialandComplianceAudit projects/BridgeDB projects/CalculateDirreqShares projects/EmailAutoResponder projects/ExperimentalBridgeBundles projects/Infrastructure projects/Metrics projects/Metrics/DesignAndDeployDescriptorDatabase projects/Metrics/ImproveMetricsPortal projects/Metrics/PublishMetricsDataAndTools projects/Metrics/SafelyCountClients projects/Thandy projects/Tor projects/TorBrowserBundle projects/TorBrowserBundle/Alpha projects/TorBrowserBundle/OSX projects/TorBrowserBundle/OSX/Security projects/TorBulkExitlist projects/TorButton projects/TorCheck projects/TorFlow projects/TorStatus projects/Tor/MultithreadedCrypto projects/Weather projects/arm projects/mirror projects/mirror/torrent projects/vidalia The deliverables promised to our sponsors would go into org/sponsors/: sponsors sponsors/SponsorA sponsors/SponsorB sponsors/SponsorD sponsors/SponsorD/December2010 sponsors/SponsorD/June2011 sponsors/SponsorD/March2011 sponsors/SponsorD/September2010 sponsors/SponsorE sponsors/SponsorE/PhaseOne sponsors/SponsorF sponsors/SponsorF/Year1 And finally, the following pages are about using Trac and would go into trac/ (it's possible that Trac wouldn't like us renaming some of its pages, but I guess we'll find out): InterTrac InterWiki RecentChanges TitleIndex TracAccessibility TracAdmin TracBackup TracBrowser TracCgi TracChangeset TracEnvironment TracFastCgi TracFineGrainedPermissions TracGuide TracImport TracIni TracInstall TracInterfaceCustomization TracLinks TracLogging TracModPython TracModWSGI TracNavigation TracNotification TracPermissions TracPlugins TracQuery TracReports TracRevisionLog TracRoadmap TracRss TracSearch TracStandalone TracSupport TracSyntaxColoring TracTickets TracTicketsCustomFields TracTimeline TracUnicode TracUpgrade TracWiki TracWorkflow WikiDeletePage WikiFormatting WikiHtml WikiMacros WikiNewPage WikiPageNames WikiProcessors WikiRestructuredText WikiRestructuredTextLinks WikiStart That's it. I realize there are lots of cooks on this list, so I expect there will be feedback. Thanks, Karsten

4 8

Re: [tor-dev] Tor and BGP integration
by Arturo 09 Jun '11

09 Jun '11

Hello, This seems to me like a really neat idea! Reading from real time BGP feeds is not a simple task and I think it might be a bit of an overhead for the average Tor user. On the other hand it could be a good idea to have some nodes run tools to generate exit policies or at least provide BGP routing information in a easy to consume format for the tor clients to use. I have been doing some experimenting on getting and analysing BGP information and these are the resources that I have found useful: - http://archive.routeviews.org/ - For getting raw MRT format BGP feeds and also the output of `bgp show ip` - http://www-01.pch.net/resources/data/routing-tables/archive/2011/ - Routing information from other "probes" - https://github.com/hellais/PyRT - A quick patch I made to make PyRT work on python > 2.3 (useful for parsing MRT format files), original: https://research.sprintlabs.com/pyrt/ IXPs: - http://www.pch.net/resources/data/routing-tables/looking-glass/ - https://www.peeringdb.com/private/index.php - Very complete database on peers and ASN information. They also provide a very nice API for interacting with their database. I have been working on some python code for adding BGP support to blockfinder. It basically just parses the results of the `bgp show ip` command outputs obtainable from route views and stores the routing paths inside a database. It needs to be cleaned up a bit, but if you are interested in using it I can hack on it some more. Let me know of the progress you make :) - Arturo `hellais` > Hello from Iceland, > > Linus invited me to Reykjavik to talk about Tor at the NORDUnet conference > and this idea is the result of a bit of feedback from some network operators > here. > > Tor needs a way to be friendly to large network operators who wish to enable > exiting to anonymous communication for their networks. These network > operators are happy to allow anyone to pass traffic to their relays as entry > nodes, middle nodes and even limited exit nodes. > > Linus and I have been discussing methods of automating this process and of > course BGP integration makes a lot of sense. Generally, a network operator > has a set of AS numbers for their network blocks and as they want people to > connect to many of their services, it helps quite a bit to allow exiting to > those services from their own Tor relays. > > We came up with two main ideas for making this happen. > > One method would be to write a program where given an AS number and a BGP > feed, we parse all of the advertised network blocks and emit exit policy > lines that accepts all traffic for the AS. This would allow for a web > service similar to BulkExitList.py for network aware exit policy generation > and relay operators would simply need to add this to their Tor configs > manually. For mostly static networks, a cronjob would be fine and Tor > doesn't need to know about AS numbers internally. > > Another method would be to write a controller that watches for BGP network > updates and Tor would add relevant exit policy lines for any configured AS. > This would allow any Tor relay to dynamically learn about network changes if > it has access to a BGP feed patched into a controller. This could be > implemented by adding some configuration options to Tor that let Tor know > which AS numbers matter to which router. It may also allow for the router to > auto learn it's own likely family network but it lacks any kind of > bi-directional confirmation, still it seems useful information to have... > > It would be fantastic if someone offered a hidden service NORDUNet BGPMon > feed. This would help enable the first method of generating network aware > exit policies; this would also help with the development of AS awareness in > Tor itself. In the future, I imagine that it makes a lot of sense for > circuit building to be BGP aware as mere netblocks will not be very useful > in an ipv6 world, they're already mostly irrelevant. > > Anyway, food for thought. Linus and I will probably hack on some of these > ideas in the near future. > > All the best, > Jake

1 0

[Patch] common/procmon.c
by Gisle Vanem 02 Jun '11

02 Jun '11

Hi list! I've been staring at this file for some time trying to find the elusive compile-error (MingW-gcc v4.50) on Win_XP). The bug was a missing comma (!) and a typo ('err_msg' at line 277 changed to 'err_msg'). I've also changed the format for 'err_code' at line 293 into a "%ld" to suppress a warning. How did this go unnoticed for ~1 month? --- Git-latest\src\common\procmon.c Thu May 26 19:30:24 2011 +++ common/procmon.c Tue May 31 22:54:14 2011 @@ -252,7 +252,7 @@ if (!GetExitCodeProcess(procmon->hproc, &exit_code)) { char *errmsg = format_win32_error(GetLastError()); log_warn(procmon->log_domain, "Error \"%s\" occurred while polling " - "handle for monitored process %d; assuming it's dead." + "handle for monitored process %d; assuming it's dead.", errmsg, procmon->pid); tor_free(errmsg); its_dead_jim = 1; @@ -287,12 +287,12 @@ if (!its_dead_jim) log_info(procmon->log_domain, "Failed to open handle to monitored " - "process %d, and error code %d (%s) is not 'invalid " + "process %d, and error code %lu (%s) is not 'invalid " "parameter' -- assuming the process is still alive.", procmon->pid, - err_code, err_msg); + err_code, errmsg); - tor_free(err_msg); + tor_free(errmsg); } } #else ------------- Sorry, no git patch. I'm a git newbie. Gisle V.

2 1

[PATCH] Signed-off-by: Gisle <gvanem@broadpark.no>
by Gisle 01 Jun '11

01 Jun '11

An elusive compile-error (MingW-gcc v4.50 on Win_XP); a missing comma (!) and a typo ('err_msg' at line 277 changed to 'errmsg'). Aso changed the format for 'err_code' at line 293 into a "%ld" to suppress a warning. How did this go unnoticed for ~1 month? Btw. This is my 1st ever 'git commit', so it better work. --- src/common/procmon.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/common/procmon.c b/src/common/procmon.c index 8fcc1af..5c10e9a 100644 --- a/src/common/procmon.c +++ b/src/common/procmon.c @@ -252,7 +252,7 @@ tor_process_monitor_poll_cb(evutil_socket_t unused1, short unused2, if (!GetExitCodeProcess(procmon->hproc, &exit_code)) { char *errmsg = format_win32_error(GetLastError()); log_warn(procmon->log_domain, "Error \"%s\" occurred while polling " - "handle for monitored process %d; assuming it's dead." + "handle for monitored process %d; assuming it's dead.", errmsg, procmon->pid); tor_free(errmsg); its_dead_jim = 1; @@ -287,12 +287,12 @@ tor_process_monitor_poll_cb(evutil_socket_t unused1, short unused2, if (!its_dead_jim) log_info(procmon->log_domain, "Failed to open handle to monitored " - "process %d, and error code %d (%s) is not 'invalid " + "process %d, and error code %lu (%s) is not 'invalid " "parameter' -- assuming the process is still alive.", procmon->pid, - err_code, err_msg); + err_code, errmsg); - tor_free(err_msg); + tor_free(errmsg); } } #else -- 1.7.0.2.msysgit.0

2 1

Control-port circuit event/status format
by Robert Ransom 01 Jun '11

01 Jun '11

Subject: Control-port circuit event/status format Will any Tor controllers that I should care about break if I modify Tor to report a ‘CANNIBALIZED’ circuit event to all controllers that send ‘SETEVENTS CIRC’ to Tor? Will any Tor controllers that I should care about break if I modify Tor to report a ‘CANNIBALIZED’ circuit state in response to a ‘GETINFO circuit-status’ control-port command? Robert Ransom

1 0