- tor-dev - lists.torproject.org

GSOC Pluggable Transport Combiner (FOG) Status Update 4
by quinn jarrell 19 Jul '14

19 Jul '14

Hi everyone, These past two weeks I've worked on - Renamed the project to fog - The fog client can now launch multiple chains. It checks all the requested combined pt chains and gets the unique set of them. So it only launches one instance of each pt to reduce redundancy. Also each chain is launched when its pts are ready instead of waiting for all the pts to be ready. - Fixed #12613 <https://trac.torproject.org/projects/tor/ticket/12613> - Fixed parsing ClientTransportPlugin lines with multiple pt methods launched by one pt

1 0

[GSoC 2014] Revamp GetTor status report #4
by Israel Leiva 19 Jul '14

19 Jul '14

Hi all! This is my fourth status update for the Revamp GetTor GSoC project. I'll summarize what I've done. If you have any doubts/comments please tell me. Progress: [*] Fixed pending issue on the dropbox module: Add fingerprint of key that signed the bundles. This had me stuck for a while, mainly because a misconception I had about signatures. [*] Minor modifications in the Core module. [*] SMTP module almost complete: it can successfully process an email, figure out what is asking (links for certain OS, help) and in what language. It sends back a reply in that language. There are some error checks pending. Unfortunately, I couldn't test the above on a real mail server, but the process to do so is pretty straightforwar, so it shouldn't mean trouble. For now it shows replies on screen. [*] Created basic .po files for the messages sent via the SMTP module. Sample versions available in english and spanish. Goals until next bi-weekly report: [+] Add proper error checking on SMTP module, as well as to try to avoid code reuse between the Core and SMTP modules. [+] Work on possibly-definitive replies (.po files). [+] Have a functional XMPP module. As always, you can check what's been done on https://github.com/ileiva/gettor/tree/master/src Have a nice weekend! Best, -- israel

1 0

Orbot & Orfox - GSoC bi-weekly report 4
by Amogh Pradeep 18 Jul '14

18 Jul '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Status Report 4 July 18th, 2014. Things I am working on: 1)Setting up repos and building: After having built fennec, we have now started to try to get it built on the jenkins server. Hopefully we will be successful and will be able to push out a version of the browser soon. 2)DNS leak plugging: According to dnsleaktest.com , there seems to be a dnsleak in the current fennec browser that we've made, working on trying to plug this. Suggestions welcome! More things to come: - - Will continue to look for leaks and more testing. - - Work on plugging the dns leak. - - Stripping out not required parts of the fennec browser. Some parts like sync won't be required and hence will be removed. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTyPoOAAoJELm/SSKdtjUk1P0IAImh1pMn21W31p0mW+ENbOTu 9QKapoIEyaHYKuM7/Wf4sdPrsgD+7bEHdH7cEvJ1SePBv3xdjXWTofz//6Kwns5r e4f0Szi8FxobtCZgwh9BfUrNYi7rnVc2tn+0mr6XT9meJ3HR4Ob2Sybi58zTmNxV 1G+ZVNas/3Hd5Xd3/aKmRwKmJUvw7ZACRHDxSqXx55i1uqQIMs+hcGjFXagcwp2o hvJngebJgRv92uurVscZP2M71PHVtOPNOxAZvgqUP4Mm7TXP0P4JJbXrBdhBvmbW OxuQB0kvfEVZ+1FpCOQw1qy7qNZV9QUC8bvFy15h/JaaS0mZ48t5AXlEtTEhPEY= =KcQ2 -----END PGP SIGNATURE-----

3 2

Syboa: gui desktop tor monitor
by Sean Robinson 17 Jul '14

17 Jul '14

This email is to announce the first public release of Syboa[1], a tor controller for monitoring a local daemon instance. My primary motivation for Syboa was to replace TorK, so it looks[2] more like TorK than Vidalia. Syboa is not ready for non-developer users[3]. But after seeing the "UX Idea - A controller inside TBB"[4] thread last week, I decided to not wait any longer. It handles 95% of my needs and about 60% of my wishes; it may not work for anyone else. Unfortunately, this is more of a "throw it over the garden wall" source release as I do not have time to work on Syboa for the remainder of the year. I do monitor the tor-dev mailing list or anyone can contact me directly with questions. [1] https://gitorious.org/syboa/syboa [2] https://gitorious.org/syboa/syboa/source/7082a822b97c723a19c5cbca4256db3500… [3] https://gitorious.org/syboa/syboa/source/7082a822b97c723a19c5cbca4256db3500… [4] https://lists.torproject.org/pipermail/tor-dev/2014-July/007117.html -- Sean

2 1

Looking for front-end web developers for network status websites Atlas and Globe
by Karsten Loesing 17 Jul '14

17 Jul '14

Hello front-end web developers, Philipp and I are looking for somebody to fork and extend one of the two main Tor network status websites: https://atlas.torproject.org/ or https://globe.torproject.org/ Here's some background: both the Atlas and the Globe website use the Onionoo service (https://onionoo.torproject.org/) as their data back-end and make that data accessible to mere humans. The Onionoo service is maintained by Karsten. Atlas was written by Arturo as proof-of-concept for the Onionoo service and later maintained (but not extended) by Philipp. Globe was forked from Atlas by Christian who improved and maintained it for half a year, but who unfortunately disappeared a couple of weeks ago. That leaves us with no actively maintained network status website, which is bad. Want to help out? Here's how: Globe has been criticized for having too much whitespace, which makes it less useful on smaller screens. But we hear that the web technology behind Globe is superior to the one behind Atlas (we're no front-end web experts, so we can't say for sure). A fine next step could be to fork Globe and tidy up its design to work better on smaller screens. And there are plenty of steps after that if you look through the tickets in the Globe and Atlas component of our bug tracker. Be sure to present your fork on this list early to get feedback. You can just run it on your own server for now. The long-term goal would be to have one or more people working on a new network status website to replace Atlas and Globe. We'd like to wait with that step until such a new website is maintained for a couple of weeks or even months though. And even then, we may keep Atlas and Globe running for a couple more months. But eventually, we'd like to shut them down in favor of an actively maintained website. Let us know if you're interested, and we're happy to provide more details and discuss ideas with you. All the best, Philipp and Karsten

1 0

Pluggable transports meeting not very likely this Friday
by George Kadianakis 16 Jul '14

16 Jul '14

Hello! It seems that many PT people (including me) won't be able to attend the scheduled PT meeting this Friday. For this reason, we are calling this meeting off. Feel free to lurk in IRC in any case. Maybe someone will want to talk PT with you even if there is no scheduled meeting :) Thanks and sorry for the disturbance!

1 0

Clarification on Alice connecting to Introduction Point
by Richard Dennis 15 Jul '14

15 Jul '14

Hi, i am currently building a tor client that will be able to connect to a hidden service, i just have a few questions about the RELAY_COMMAND_INTRODUCE1 cell once a circuit is established to one of Bob's introduction point and an incorrect RELAY_COMMAND_INTRODUCE1 is sent, what, if anything would be expected back For the PK_ ID, what information is needed for this, I have received a V2 descriptor, and see it says to use the service-key, is this the service key for the introduction point i have selected which was found by decrypting the descriptor, or permanent-key found in the non decrypted v2 descriptor and where would i find bobs public key Many Thanks Richard

1 0

I propose a kickstarter for Roger, Nick, or Paul to receive a free Tor tattoo of his choice
by Virgil Griffith 15 Jul '14

15 Jul '14

e.g. https://imgur.com/sZUKADG I will donate. -V

1 0

Revised Relay Descriptor Fields proposal
by Virgil Griffith 14 Jul '14

14 Jul '14

Filename: ExtraRelayDescriptorFields.txt Title: Adding new X- fields to relay descriptor Author: Virgil Griffith, Nick Mathewson Created: 2014-06-03 Status: Open 1. Motivation We wish to allow developers to build new applications atop relays. Towards this end, we wish to add the ability for users to specify arbitrary new key-value entries under the "X-" namespace. 2. Proposal Allow optional key-value lines in the relay's torrc file. These lines will be mirrored in the relay's descriptor which is then published in the directory consensus. For example: X-bitcoin 19mP9FKrXqL46Si58pHdhGKow88SUPy1V8 X-gravatar https://s.gravatar.com/avatar/d27fce46c9ac41a41bb52455ae75701d X-favoritequote Be excellent to each other. Party on dudes! X-foo bar The value field must be printable ASCII (characters 32-126). The value must not under any condition contain a newline. The key may contain lowercase ASCII letters (a-z), digits, underscore, or dash. In regex, [-_0-9a-z]. There may need to be a maximum sum length of the X- entries. This is left to the developers. I propose a maximum sum length of 5 kilobytes. To mitigate the chance of a malformed torrc file, I additionally propose there be a schema for the relay descriptor, and if the relay descriptor fails to match the schema it errors to the user to change her torrc file. -V

6 6

What little-t-tor bridge features/issues we should address?
by George Kadianakis 14 Jul '14

14 Jul '14

Hello Roger and Nick, as far as I know, bridge support was hastily implemented in little-t-tor, and it does not support all the features we would like it to support. During the dev meeting roadmapping, we added a task about improving the bridge implementation in Tor. Some of the items in the task are: - Bridges should save bridge information to the state file (proposal 192) - Fix UpdateBridgesFromAuthority. - Obfsbridges should be able to hide their ORPort (#7349) Some of those items are more long-term than others. What other tasks would you like to see in there? We are looking for tasks mainly related to bridges themselves, and not PTs. Thanks!

4 3