tor-dev

tor-dev@lists.torproject.org

3581 discussions

Thoughts on simplified packaging
by Andrew Lewman 15 Jun '11

15 Jun '11

As I talk to more and more people, they are confused by all of the different software packages we offer. From the simple, "I just want to be a relay, why is this so hard?" to "I just want to safely get to the BBC, I don't care about configuration and such. Can't you just make it a simple download and have it work by default?" I've written down my thoughts at https://svn.torproject.org/svn/projects/roadmaps/proposed-package-roadmap.t…. I'm looking for your thoughts and feedback. The goal is to simplify what we produce and make it easy for people to get the software and configuration they want. -- Andrew pgp 0x74ED336B

4 3

Python TorCtl development questions
by Sean Robinson 12 Jun '11

12 Jun '11

I have begun using the Python TorCtl package to develop a gui TOR controller. So, I am looking at the TorCtl source to understand how to use it properly. In this examination, I have begun adding comments, renaming vars to be more explicit, etc. How open are the developers to these changes? Will the devs accept patches to remove unused code. I'm looking at you, TorCtl.TorUtil.Enum. Is there interest in making TorCtl into a more mainstream form of Python package? See https://trac.torproject.org/projects/tor/ticket/2585 How far back in Python versions are we trying to maintain compatibility? As an example: TorCtl.TorUtil.Callable seems to be used to create static methods, but the staticmethod function to do this was added in Py2.2 (Dec 2001) and the @staticmethod decorator form was added in Py2.4 (Nov 2004). And thank you for TorCtl, it certainly saved me time not to have to implement a protocol engine from scratch. -- Sean Robinson WiFi Radar - http://wifi-radar.berlios.de Python WiFi - http://pythonwifi.wikispot.org pymnl - http://pymnl.wikispot.org

2 3

Will people running a relay be blocked from accessing CN destinations?
by tagnaq 11 Jun '11

11 Jun '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Ian, I made a new thread to avoid this discussion in the 'The Torouter and the DreamPlug' thread. > On Thu, Jun 09, 2011 at 11:47:10PM +0200, tagnaq wrote: >>> > > Doesn't "make random people into public (middle-only) relays" have the >>> > > (well maybe not "problem", but "issue"?) that when GFW blocks them, they >>> > > (the random people who bought an Excito/etc.) won't be able to connect >>> > > to anything in .cn any more? Although I don't _often_ connect to .cn >>> > > domains, it seems unfortunate to effectively auto-ban these people from >>> > > Chinese websites. >> > >> > I did not experience any problems connecting to .cn while using a relay >> > IP address. I think they are just blocking an IP:port combination and >> > not the entire IP address. >> > ...but things might change > Hmm. I wonder what happens if the packets are fragmented so that the > TCP port information isn't in the first fragment... possibilities: a) a fragmented IP packet doesn't get blocked b) they don't allow IP fragmentation (Don't Framgent Bit set) c) their firewall is able to find out whether the fragment is part of a blocked destination (IP:port) -----BEGIN PGP SIGNATURE----- iF4EAREKAAYFAk3znv4ACgkQyM26BSNOM7ZB5QD+J7p1OSqD7uopViiigmop84sp nlzbSV6dqK2ZvT+PrbUA/i2hLQKHkYZfVUQqTp4hu2o9bp5GbHsNylNP6l1lKByB =aKCK -----END PGP SIGNATURE-----

4 6

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

Code Review (arm) - Initial commit for the menu code
by Damian Johnson 28 May '11

28 May '11

Hi all. Kamran and I are gonna doing code reviews publicly so if you're interested and spot issues we miss then feel free to chime in. -Damian Change: https://gitweb.torproject.org/user/krkhan/arm.git/commitdiff/5fd9b5f74a86eb… > ARM_CONTROLLER = Controller(stdscr, stickyPanels, pagePanels, menu) What sort of persistent state will the menu require? If we can make it a popup function (like "showHelpPopup()") that would be preferable (less parameter juggling). But if you expect it to remember something between menu requests then this makes sense. > menu.draw() Maybe rename this to "showMenu()"? The draw method is part of panel which threw me off a bit. > self._rootEntry = (entry and isinstance(entry, ParentEntry)) and entry or DEFAULT_ROOT Interesting pattern, but it's kinda hard to read (or make sense of unless you've seen it before). Maybe something a little less compact would be clearer? if entry and isinstance(entry, ParentEntry): self._rootEntry = entry else: self._rootEntry = DEFAULT_ROOT > titles = map(attrgetter('title'), self._rootEntry.children) This took me a couple minutes with the interactive interpretor to make sense of too. Maybe list comprehension instead of the attrgetter would help? titles = [menuItem.title for menuItem in self._rootEntry.children] > titlewidth = max(map(lambda title: len(title), titles)) + 2 Neat. Honestly I'm greener than I should be with lamdas. The pattern I'd use for this is... titlewidth = max([len(entry) for entry in titles]) + 2 but up to you. The later is more familiar to me but I'm not sure which can claim the best readability. > # total number of titles that can be printed in current width Why are you giving all titles equal distance? Does this make it look better? I'd assume that would be best to have dynamic widths, leaving some entries unprinted if we run out of room (this is done all around so I can get you an example if you'd like). I'm thrilled you're taking variable screen sizes into account! > titleformat = curses.A_NORMAL > > if index == self._selection[0]: > titleformat = curses.A_STANDOUT Alternative option... titleformat = curses.A_STANDOUT if index == self._selection[0] else curses.A_NORMAL > popup.win.addch(top, left, curses.ACS_VLINE) > popup.win.addstr(top, left, entry.title.center(titlewidth), titleformat) > popup.win.addch(top, left, curses.ACS_VLINE) Noooooooo! Don't do this! If you can help it _never_ draw to the raw curses window. If this ever attempts to draw outside the curses window it will crash. The panel class has safe proxies for everything that you should need. In this case... popup.addch(top, left, curses.ACS_VLINE) popup.addstr(top, left, entry.title.center(titlewidth), titleformat) popup.addch(top, left, curses.ACS_VLINE) will do the same. There's, of course, exceptions like popup.win.box() and popup.win.refresh() (those are safe). > DEFAULT_ROOT = ParentEntry(title="Root", children=( I've been defining constants outside of classes so they can be easier to spot at the top of files. However, this is just a stylistic preference of mine - if you prefer constants to be a class attribute then that's fine. > for index in self._selection: > if isinstance(entry, ParentEntry): > entry = entry.children[index] > else: > break > > if isinstance(entry, LeafEntry): > entry.callback(entry) It looks like if self._selection is an invalid path you do nothing? Maybe we should log something or raise an exception... Your usage of named tuples and index lists will, I think, make this harder and more confusing than it needs to be. Instead I'd suggest a MenuItem class that has... getLabel() -> text for the option isLeaf() -> boolean for if we're a leaf or not getSubmenu() -> returns a list of MenuItems below it - either an empty list or None if a leaf node (whatever makes most sense to you) getParent() -> parent MenuItem next(), prev() -> returns a MenuItem instance for the next or previous option for the menu list we're in select() -> event handler Constructing the menu will be a little more interesting, but rendering it, navigation, and selection will all become trivial. It'll also avoid the situation where _selection is out of sync with _rootEntry (for that matter, we wouldn't need a rootEntry...).

2 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev