- tor-dev - lists.torproject.org

Damian's Status Report - September 2013
by Damian Johnson 30 Sep '13

30 Sep '13

Hi all. Present status: gobbling birthday carrot cake. Before that, though, did a few things worth noting in September... ====================================================================== Stem: Connection Resolution Support ====================================================================== Stem can now provide you with the active connections belonging to a process. This is similar to arm, capable of doing lookups via seven *nix and FreeBSD resolution methods... https://stem.torproject.org/api/util/connection.html#stem.util.connection.R… Unlike arm, however, this is a far cleaner implementation including both unit and integ tests. Unfortunately this doesn't yet work with Tor's DisableDebuggerAttachment feature, but I plan to look into workarounds for that soon. 'How do I use this', you ask? It's easy! https://stem.torproject.org/tutorials/east_of_the_sun.html#connection-resol… ====================================================================== Arm: Rewrote Starter Module ====================================================================== Arm is presently undergoing an overhaul, and this month I focused on its starter module. It's now shorter, has unit tests, and is just generally damn better... before: https://gitweb.torproject.org/arm.git/blob/refs/heads/release:/src/starter.… after: https://gitweb.torproject.org/arm.git/blob/HEAD:/arm/starter.py ====================================================================== Other news this month includes... * Google Summer of Code finals were last week. All the remaining students passed, having done great work - fingers crossed they stick around! * DocTor's python replacement is now happily chugging along on yatei and provides #tor-bots notifications. * Attended a local TA3M meetup hosted by Lee Fisher. I'll be presenting a 'tor ecosystem' talk at it in October. (https://www.seattleprivacy.org/?p=356) * Notified outdates relays that will soon be dropped from the network if they don't upgrade. (#9476) * Investigated tor regression reported by stem's jenkins tests. (#9746) * Code reviewed Aaron's TorPS. (https://github.com/torps/torps.git) * Fixed a stem caching bug regarding hidden service config options caught by wayzard. (#9792) * My site (https://www.atagar.com, which hosts arm) finally has SSL support. https://lists.torproject.org/pipermail/tor-commits/2013-September/062328.ht… Cheers! -Damian

1 0

File verification GUI tool
by Sherief Alaa 29 Sep '13

29 Sep '13

Hi Everyone, (moving this email from the support-team ML to tor-dev as Runa suggested.) I am starting to work on a small GUI tool for file verification because I find guiding users through the verification process on Windows/Mac through the command line painful. Tools in use: - Python 3.3 or 2.7 (still didn't decide yet). - PyQT - python-gnupg-0.3.5 I might also add a log window and a save log button to see what went wrong during the verification process. Attached is a draft design of how the tool would look like. On Mon, Sep 23, 2013 at 7:12 PM, Lunar <lunar(a)torproject.org> wrote: >How do you think users will be able to install such a tool on their >system? There won't be any installation required It's a single executable. >More importantly, how will they be able to ensure that it's >not a tampered version? I've thought about that and few things came to mind: - Include the executable inside TBB. - Host it somewhere and also provide a SHA-256 hash on a website or in a file. But this is all an endless chain because lets say I download TBB, then download gpg to verify it but then how do I make sure that gpg it self wasn't tampered with? (assuming I don't have it installed already.) Any help or suggestions would be much appreciated. Thanks. -- Sherief Alaa pgp 0x8623B882

6 6

Re: [tor-dev] Pluggable Transport Browser Bundle FTE Integration
by David Fifield 29 Sep '13

29 Sep '13

On Sun, Sep 01, 2013 at 01:32:23PM +0300, George Kadianakis wrote: > Kevin P Dyer <kpdyer(a)gmail.com> writes: > > === How do we invoke PTs? > > I had this discussion with Roger, but I don't see any open tickets or clear > > discussion on this already. If we have N>1 PTs and at least one bridge per > > PT, how do we select which PT (and which bridge associated with that PT) to > > use? Determinism is bad because then only one PT is used. Booting up all > > PTs is bad, especially if (say) the PTs make network connections prior to > > any incoming SOCKS connections. Selecting a random PT is potentially bad, > > too, depending upon how hostile and persistent and stateful the adversary > > is. > > That's an interesting question. I'm not sure if the process of Tor > picking bridges is deterministic or not. I should test it out. David > might know. > > (A good scenario would be that Tor treats bridges like guards and > selects some at random to build circuits.) I don't know how Tor decides which PT bridges to use. I would guess that it treats them like any other Bridge lines in torrc. You should see this ticket and blog post: "Config option to declare whether you're using bridges for reachability or for security" https://trac.torproject.org/projects/tor/ticket/4624 https://blog.torproject.org/blog/different-ways-use-bridge The idea behind it is that some users want covertness (I need to hide the fact that I am using Tor), and some users want reachability (I need some way to circumvent the firewall). The way I see it, the unstated policy of the PT bundles is to optimize for reachability. By default we launch all the transports we know about, so for example if three transports are blocked and one gets through, that is a success. This doesn't work for the first kind of user, for whom a blocked transport means they have been detected. This first kind of user is likely to have to take some extraordinary steps while using Tor in any case. I don't think we have a plan for how to make a bundle that, in its default configuration, is safe to use for all such users. However we can make a bundle that does reachability with no special configuration, so that's what we're doing. The new 3.0 series bundles ask you, on startup, whether you are able to connect directly to Tor or whether you have to do your own manual configuration (like adding bridges). The option to launch only one specific safe transport could in principle be added to such a UI. David Fifield

2 1

Help make the Tor stackexchange beta succeed
by Roger Dingledine 29 Sep '13

29 Sep '13

Hello Tor developers and anonymity researchers, Our Stackexchange beta is underway: http://area51.stackexchange.com/proposals/56447/tor and we could use some more participation from actual Tor developers, anonymity researchers, and so on. The goals include a) building a good set of answers to questions around Tor research and development, and b) growing a larger army of people who know these answers and can answer more such questions. If you can help out, please send me mail off-list, including what email address I should tell them for you, and I'll hook you up. Steven, Philipp, Jens, and I can't do it by ourselves. :) (And as a carrot, if you sign up you can read my answer to "What are the options to remove Mevade botnet from Tor?") Thanks! --Roger

1 0

New GPG key for Mike Perry
by Mike Perry 28 Sep '13

28 Sep '13

Hi everyone, I've finally made a new GPG key (after a scant 7 years!). This new key will be used to sign email from me going forward, and will be used to sign software releases until such time as I get around to creating a second set of keys on a hardware token for that purpose. While I dislike the Web of Trust for a number of reasons*, my plan is to cross-certify these two sets of new keys, and also sign both with my old key. Hence I will not immediately be issuing a revocation for my old key. The new key is attached, and is available on the keyservers (with a signature from my old key) at: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x29846B3C683686CC Here's the fingerprint and current subkey information for reference: pub 8192R/29846B3C683686CC 2013-09-11 Key fingerprint = C963 C21D 6356 4E2B 10BB 335B 2984 6B3C 6836 86CC uid Mike Perry (Regular use key) <mikeperry(a)torproject.org> sub 4096R/717F1F130E3A92E4 2013-09-11 [expires: 2014-09-11] sub 4096R/A3BD8153BC40FFA0 2013-09-11 [expires: 2014-09-11] This message should also be signed by my previous key, which was used extensively to sign my email and my source code releases prior to today. * Ensuing flamewars about the Web of Trust should reply only to tor-talk. -- Mike Perry

1 0

[tahoe-dev] the GNU 30th Birthday party!
by Eugen Leitl 27 Sep '13

27 Sep '13

----- Forwarded message from Zooko O'Whielacronx <zookog(a)gmail.com> ----- Date: Fri, 27 Sep 2013 05:00:04 +0000 From: Zooko O'Whielacronx <zookog(a)gmail.com> To: tahoe-dev <tahoe-dev(a)tahoe-lafs.org> Subject: [tahoe-dev] the GNU 30th Birthday party! Folks: Tahoe-LAFS is one of the featured projects at the GNU 30th Birthday Party Hackathon! https://www.gnu.org/gnu30/celebration I'm going to be there in person in Cambridge. What I want to do during the Hackathon is make Tahoe-LAFS work better with Tor and/or I2P. I know that at least a couple of Tor developers and at least one I2P developer will be there in person, so this is a good opportunity to collaborate face-to-face or side-by-side. One thing I could spend Hackathon time on is just to contribute some patch review service to the Tor project, if it seems like they want that. Issue tickets relevant to this: Go to https://Tahoe-LAFS.org, click on "View Tickets" → https://tahoe-lafs.org/trac/tahoe-lafs/wiki/ViewTickets , click on "anonymity" → https://tahoe-lafs.org/trac/tahoe-lafs/query?status=!closed&keywords=~anony… Eyeballing those, I recognize the following as especially ripe, because the I2P folks have been working on them and flagging them as blockers for I2P: #68, #1010. https://tahoe-lafs.org/trac/tahoe-lafs/ticket/68# implement distributed introduction, remove Introducer as a single point of failure https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1010# use only 127.0.0.1 as local address See also a couple of patches that the I2P people are trying to contribute to foolscap, and which are also needed for full Tahoe-LAFS+I2P integration: http://foolscap.lothar.com/trac/query?status=!closed&keywords=~i2p You can join in! Just connect to us on IRC -- irc.freenode.net channel #tahoe-lafs -- or physically show up in Cambridge. Or, I suppose, at one of the other GNU 30th Birthday celebrations around the world: https://www.gnu.org/gnu30/ (scroll down to "Satellite Events"). ☺ Regards, Zooko _______________________________________________ tahoe-dev mailing list tahoe-dev(a)tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Pluggable transport biweekly meeting - Friday Sept 27
by vmonmoonshine＠gmail.com 27 Sep '13

27 Sep '13

Hello PT devs, We'll have our next meeting (almost) today Friday - Sept 27 at CEST: 18:00 BST (Summer GMT): 17:00 UTC: 16:00 EST: 12:00 MNT: 10:00 PST: 9:00 @ #tor-dev on irc.oftc.net As last time asn is going to take us through this after identifying the participant we go one by one and update the group about our recent progress and blockers. As people suggested last time after update we will have a brief code review session when each of us will take at piece of code of another developer and comment on it. If you missed last the meeting or you need a bit of reminder you can find it summary here: https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/meeti… See you in few hours, Vmon

1 0

tor-bundle:How to extend the firefox context menu?
by mabra＠manfbraun.de 27 Sep '13

27 Sep '13

Hello ! I am doing really very boosted webserach in the last month. I am using the tor-bundle, if I am searching in several different and sensitiv areas, like wiki-leaks etc. >From my long term experience with all other search engines, beside google, they really dont allow you to continue, if the browser crashes. But this happens in minimum 10 times a day :-( So I want to use google to search, without allowing them to track me. This is why I use the tor-bundle. Using tor for simple webpages is usually slow. What would beome best for me, is, to use the tor-bundle together with the google search engine, but then, have a context menue (right click) to open another browser for a given search result item. The other browser then, is not configured to use the tor network. Does anyone has an information, how I, as an end-user, can exceed the context menue in the tor-bundles browser? Thanks anyway and best regards, ++mabra

1 0

Using the consensus-health web page to debug the Tor network
by Karsten Loesing 26 Sep '13

26 Sep '13

Hi Damian, Roger and I discussed the consensus-health web page that the Java version of DocTor produces [0] but your Python version does not. Roger says he uses that page to debug the Tor network. In particular, he says he scans the huge relay flags table to spot differences between relay flags assigned by the directory authorities. I'm pasting the IRC log below, but we should move this discussion to email, because it seems unlikely that we're all present in #tor-dev at the same time to discuss this. I see four ways how we can make most people mostly happy: 1.) We add votes documents to Onionoo (#9778) and include relay flags contained in votes in relay details pages of Atlas/Globe, so that people can find out what the different directory authorities think about their relay. We write a new Onionoo client that fetches this information for all running relays and produces a long table of relay flags. Before we do all this we make sure that there's nothing else on the consensus-health web page that Roger secretly hoped to keep. Then we shut down the Java DocTor. 2.) We rewrite the website-generating part of DocTor in a language we're happier to maintain long-term. This could be part of your DocTor, or of a new tool. Then we shut down the Java DocTor. 3.) We keep the Java DocTor running to generate the website, but disable the part that sends notifications to the mailing list and to the IRC bot. Or rather, I'll want to move the page away from metrics.tpo to, say, consensus-health.tpo or consensus-explorer.tpo, because it has always been a hack to serve it on metrics.tpo. Then we hope the Java DocTor never breaks. 4.) We do something much smarter which I didn't think of yet. What do you think? All the best, Karsten [0] https://metrics.torproject.org/consensus-health.html 08:04:49 < karsten> armadev: about removing per-relay votes from https://metrics.torproject.org/consensus-health.html. that was intentional, because the page took so long to load and it seemed nobody cared. 08:05:14 < karsten> armadev: but it seems the next step will be to kill that web page entirely.. 08:05:34 < karsten> the reason is that atagar's consensus-health checker will take over very soon. 08:05:56 < karsten> so, what information from the consensus-health page do you still need, either the current one or even the one with per-relay votes? 08:06:10 < karsten> we should try to rescue that information then. 08:07:16 < armadev> karsten: is atagar's consensus health checker up yet? 08:07:22 < karsten> yes, it is. 08:07:26 < armadev> url? 08:07:33 < karsten> it's sending mail to tor-consensus-health@ and to #tor-bots. 08:07:36 < karsten> it has no website 08:07:48 < karsten> it's sending out warnings if something goes wrong. 08:07:56 < karsten> when* :) 08:08:54 < armadev> karsten: in this case, what i wanted from the consensus health page was the set of votes per authority for 000000000000myTOR2 08:08:56 < karsten> right now, both consensus-health things send mail to that list. the ones at :03 are from mine, the other ones from atagar's. 08:09:11 < armadev> i pieced it together manually from moria1's v3-status-votes, but i'm special so i can do that 08:09:16 < karsten> right 08:09:25 < karsten> I thought about this a while ago. we could include votes in onionoo. 08:09:34 < karsten> not sure how yatei will like that though. 08:09:50 < karsten> but it's the votes you care about, ok. anything else from the consensus-health page? 08:10:16 < karsten> wfn: ^^ we should talk about this. 08:11:05 < armadev> s/votes/votes about flags/ here 08:11:23 < karsten> right. 08:37:19 < armadev> it seems i used consensus-health as consensus-explorer 10:11:35 < armadev> karsten: can you fwd me a sample mail from the health checker mailing list? 10:12:07 < karsten> armadev: they're archived: https://lists.torproject.org/pipermail/tor-consensus-health/2013-September/… 10:13:43 < armadev> oh good 10:13:56 < armadev> that's a very short mail. 10:14:02 < armadev> it has, like, nothing from the consensus health checker 10:14:20 < karsten> that's the things that need fixing to make it quiet again. 10:14:42 < armadev> why is "it takes a long time to load" a bug in consensus-health.html ? 10:15:37 < karsten> well, the page is huge, and firefox can't handle that very well. that's not a bug, but an inconvenience. 10:16:09 < armadev> sure 10:16:25 < karsten> I could have split the page into two. 10:16:34 < karsten> but anyway, the entire page is going away soon. 10:16:39 < armadev> if you were planning to drop it entirely, you could just leave it alone? 10:17:12 < karsten> as unmaintained service? 10:17:36 < karsten> I'd rather take the pieces we like and integrate them in maintained services. 10:17:37 < armadev> i guess. or write a howto for how to take votes in and generate the html, and i'll run it on moria 10:17:53 < armadev> though i think it needs more than votes as input 10:18:11 < armadev> i've used most parts of this page over the past few months 10:18:13 < karsten> it downloads votes and consensuses. 10:18:19 < karsten> I see. 10:18:42 < armadev> i have votes and a consensus on moria 10:18:49 < armadev> if that's the input, i can just cron it to run on moria 10:18:58 < armadev> based on the votes i see and the consensus i see 10:19:09 < armadev> unless i guess it requires a massive tomcat engine too :) 10:19:15 < karsten> it doesn't. 10:19:17 < karsten> it requires java. 10:19:29 < karsten> and produces a static html that you can service with whatever. 10:19:55 < karsten> well, if you need it, it's easier to keep it running on yatei. 10:19:57 < armadev> i don't have any java. i guess i could add it. or we could stick it on people.tp.o or something 10:19:59 < armadev> right 10:20:09 < karsten> and just turn off the email notifications, because atagar's thing will send those. 10:20:11 < armadev> i use it for debugging the network 10:20:32 < karsten> ok 10:20:58 < karsten> would #9778 solve the problem with the missing relay flags table? 10:20:59 -zwiebelbot:#tor-dev- [tor#9778: Adding votes documents to Onionoo] 10:21:08 < karsten> assuming atlas or globe would show those? 10:21:32 < armadev> do i have to load each relay one page at a time? 10:22:05 < karsten> probably. 10:22:31 < karsten> so, you're looking through the table to spot problems? 10:22:41 < karsten> or, have been looking, when the table was there. 10:22:41 < armadev> yes. and to get a sense of trends. 10:22:44 < armadev> right 10:22:57 < armadev> i guess in this most recent case i just wanted one relay 10:23:11 < armadev> but after that, i realized that i wanted to know how many relays had a Running flag from those two authorities and no Running flag from any others 10:23:33 < karsten> ok 10:23:42 < armadev> (i still want to know :) 10:24:06 < karsten> let me re-enable the table and think about a better long-term solution.. :) 10:24:07 < armadev> (related to https://trac.torproject.org/projects/tor/ticket/9775 ) 10:24:08 -zwiebelbot:#tor-dev- [tor#9775: Authorities should report when they don't vote Running but some addresses are still reachable] 10:24:48 < armadev> we are dropping an unknown number of relays from the consensus because they enable ipv6 but screw up the reachability 10:25:16 < armadev> hopefully every relay operator who knows what ipv6 is also knows how to check relay-search for themselves 10:28:21 < karsten> the next consensus-health.html will contain the relay flags table again. in roughly 35 mins. 10:29:51 < armadev> thanks. sorry for the troubles. and i understand the drive to get rid of extra things. i wish we had more things that were actually extra. 10:32:10 < karsten> yeah, we have a lot of stuff. and some of it is really old and hasn't seen love for too long.

2 6

Kickoff Meeting Times for Project Otter [all next week]
by Tom Lowenthal 26 Sep '13

26 Sep '13

There seem to be relatively good times for all three Project Otter kickoff meetings next week. There's no need to RSVP, but if you can't make it and have something to contribute please try to provide that input as soon as possible in the form of a "comments" section on the relevant page on the wiki. Otter index page: <https://trac.torproject.org/projects/tor/wiki/org/sponsors/Otter> All the meetings will be held in #tor-dev on `irc.oftc.net`. Here are the times: * Attentive Otters [IM bundle]: Weds 2013-10-02 1100-1200 Pacific * Boisterous Otters [Help/outreach/l10n]: Weds 2013-10-02 0900-1000 Pacific * Cute Otters [Hidden services & publishing]: Weds 2013-10-02 1600-1700 Pacific If you have other questions or there are other problems, please reply here. -Tom

1 0