- tor-dev - lists.torproject.org

[GSoC 2014] Revamp GetTor status report #2
by Israel Leiva 21 Jun '14

21 Jun '14

Hi all! This is my second status report for the Revamp GetTor GSoC project. I'll summarize my progress since the first report. For more details feel free to ask, or if you have any comments, please tell me. Achievments: * Implemented a script that interacts with Dropbox. * Integrated the dropbox script with GetTor's core module. Now it's possible to automatically upload bundles from a local directory to dropbox and write its download urls to a specific file, which is used by the Core module to obtain links for a certain operating system and locale (e.g. linux-en). The current dropbox.links was generated by dropbox.py, and if you run core_demo.py (with 'linux' and 'es') it will get you those links. * Added logging within the Core module, with one general file (all logs) and separated log files for each level. Others: * Started a discussion [2] about sending links without SSL. I didn't get many answers. My mentors and I agreed to stay with HTTPS links only. Goal(s) until next report: * Do some cleaning, better error detection and better documentation for the current code. * Finish some minor stuff pending on the current code. * Hava a basic SMTP or XMPP module working with the Core module. You can check my progress on [0] and [1]. That's all for now. Have a nice weekend! [0] https://github.com/ileiva/gettor/tree/master/spe <https://github.com/ileiva/gettor/tree/master/spec>c [1] https://github.com/ileiva/gettor/tree/master/sr <https://github.com/ileiva/gettor/tree/master/src>c [2] https://lists.torproject.org/pipermail/tor-dev/2014-June/006977.html -- israel

1 0

GSoC Report - Zack Mullaly - HTTPS Everywhere secure ruleset update mechanism
by Red 20 Jun '14

20 Jun '14

Hello again everyone, I am here once again to report my progress in building a secure ruleset updating mechanism for the HTTPS Everywhere browser extension. This past week's work has involved a lot of updates to the specification for the mechanism[1], and changing a lot of what I had done before to keep up with all of the changes. With regards to the documentation, a great deal of the changes being discussed about the order that tests of authenticity of the update information as well as its relevant have been finalized. There is now a "Pseudocode of the update procedure" section that outlines this order that tests are performed and also gives an idea of what data the mechanism requires, where it's obtained from, and how it changes that data. I have also added extensively to the "update.json and update.json.sig" section to outline everything anyone should need to know from generating update.json to getting a properly-encoded signature of the digest of update.json that can be verified by the extension. The document is now also included as part of the repository so that pull requests and better commenting can be made. I have also been making a lot of improvements to the utility script used for building the content of update.json[2]. The script has been completely revamped to work in accordance with the modified spec. I have also included a few sanity checks to verify that the content provided for update.json make sense, and made it very easy to write more such checks. I spent most of today getting the actual ruleset updater module[3][4] code up to date. The code now reflects the changes to the new standard and has been simplified dramatically. As usual, I have my meeting notes available as a Gist[5]. The notes from the meeting I had today with Yan are already present. My plans for the coming week are to set up a testing environment and begin making sure everything works as expected. I will also begin the discussion about how the extension should handle error reporting- what to do when authenticity tests fail, or the extension can't fetch the update information. Please feel free to take advantage of the update spec being part of the repository now to discuss the details and/or propose changes in the form of a pull request. Either this or the https-everywhere mailing list are also great places to get in touch with myself and everyone who has been involved in my work. Cheers, Zack [1] : https://github.com/redwire/https-everywhere/blob/makeJSONManifest/doc/updat… [2] : https://github.com/redwire/https-everywhere/blob/makeJSONManifest/utils/rul… [3] : https://github.com/redwire/https-everywhere/blob/rulesetUpdating/src/chrome… [4] : https://github.com/redwire/https-everywhere/commit/1a0d5edb8572180854ad620f… [5] : https://gist.github.com/redwire/b62f03905a826e79947a#week-6

1 0

GSoC : Rewrite Tor Weather (Status Update 2)
by Sreenatha Bhatlapenumarthi 20 Jun '14

20 Jun '14

Hi all, As a part of the weather-rewrite project, I've been working on the onionoo-wrapper module[0] since my last update. I managed to write a couple of utility methods to the wrapper like *is_stable*, *is_exit_relay*. Removed the caching feature(using pymemcache) temporarily to ease the testing process on meejah's advice. This will be picked up later from Lukas Erlacher's Onion-Py. Wrote some preliminary unit tests for the wrapper using python's mock module. Also initiated the main backend work with a new implementation of the welcome script using the Onionoo wrapper[1]. It currently fetches details document from Onionoo, checks for new relays, ensures their operators haven't been sent an email yet and then updates the database accordingly before sending them a welcome email. This is my first script regarding the rewrite that interacts with the django components of the previous weather. I'll be finishing up the remaining scripts as well soon enough before the next update and then move on to testing and documentation. As always, if you can take a look at the work and/or provide some feedback that'd be great. [0] - https://trac.torproject.org/projects/tor/ticket/12085 [1] - https://trac.torproject.org/projects/tor/ticket/11081 [2] - https://trac.torproject.org/projects/tor/ticket/11084 Cheers, Sreenatha

1 0

Orbot & Orfox - GSoC bi-weekly report 2
by Amogh Pradeep 20 Jun '14

20 Jun '14

Hey everyone, This is my second bi-weekly report and I am working on Orbot & Orfox. Status Report 2 June 20th, 2014. What I have done: 1) Expanded notification work: Added my finishing touches to the new expanded notification that has been planned to be added to Orbot, got exit IP address working (please do test this if possible, https://github.com/amoghbl1/orbot-1 branch- new_notification_expanded). Found a new layout for the expanded notification to make it look like the original notification that the system shows. 2) Build Fennec: My project timeline now moves on to working on Orfox, as we have decided to make Orfox tor's blend of the firefox for android browser, I am currently working on building firefox so that we may edit their code and make our browser. Hopefully, I can start hacking on the code as of next week, once I get it built. On another note, I will be attending the Summer dev meet in Paris and I'm excited to meet the community :) Best, Amogh Pradeep

1 0

lcov test coverage reports
by David Murray 20 Jun '14

20 Jun '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, Would there be interest in using lcov [0] for test coverage analysis? Obviously, as lcov is an external pacakge, the existing scripts that only use built in gcov commands must remain. However, if I were to create a script that generates a pretty, HTML coverage report using lcov & genhtml, would this be something others would use? And how would you like to see this implemented? As a custom make target (e.g., make htmlcoverage + autotools black magic to silently disable/hide the target if we can't find lcov), or as a standalone script (i.e., ./scripts/test/run_lcov.sh). For what it's worth, I've manually run lcov on tor after enabling coverage through ./configure, and the output seems sane, so I think from a technical standpoint this would work. [0]: http://ltp.sourceforge.net/coverage/lcov.php Cheers, daube -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTnYryAAoJEBfCjrGktO5q+FgP/26ZgVZOAKSOBvWr6z2HYEku 1Yo+xFqTXk/Fw6yilv6Z4Jwc0Ar2B/VjHfLpOL1Vm+hFZ+VYsObSt9JGG2baItbG IrcedfjCuyjfaP1PloZoDM24FEbXqjseQO2EZ8bXbtErsW52Z4uAR3nYYcyXCCYp 1gi6lEwN/Yn0xm+fGgoz6/Z5FXvETdzbWLfhZoT4jFsnQsp/fByld55JLyft/8gA OrH3QQYGgXZkwIsnTkbLO3xWpXbqC5kU/ngCOL9WXXU99cgnW+bec7DA+cHhTqh/ 7oZD54noQ9XYtOA7AhAEOiTWnJUca2vV1KFPVBKSlqfkOhF3BRANHo2cIpsvgeBK 9+tcTyuwcFGAJVmW9l/AN3Y89CepCxnk6B1SSLFxuUVupAz2ilBM7KVtgj2ilJnC 2GjfuQB0RG/FW0CSEaa+DDtHfzCMfZNwGb6Fs1L41P8NnlGVFOz11NLlMG3t5ZpT 0OrncYaeVz74H+63Ig1ZwOjlfgUr9BHMLeYdwn9FmqIggyFRt1Z5PnNCaMuExs/v WQbLMP0oZ9XK1f51vfFVFYk/n1nh1c4J40/3I5B525GANAZ3fxTDLp0oSp/gNr5X lXPaF32KexhOiup5n1d6x8oJPzeNmex5CfcT29bZMPavF8p8v0OdZrUtU40bG7nO PUlA3EFfva1YW0aTRKY5 =+v+h -----END PGP SIGNATURE-----

2 3

GSoc Status Report Muticore Daemon
by Белоус Михаил 20 Jun '14

20 Jun '14

Hello everyone, This is second Google summer of Code status report, I implemented threadpool for tasks and create simple benchmark for threadpool. It pass test for workqueue, but I will write new test for new threadpool architecture. After my return I will learn more about work of daemon and rewrite bottle necks using my thread and write new benchmarks for this places. Sincerely your, Mikhail

1 0

Pluggable transports meeting today (16:00UTC Friday 20th of June 2014)
by George Kadianakis 20 Jun '14

20 Jun '14

Hello friends, just wanted to remind you that the regular biweekly pluggable transports meeting is going to occur today at 16:00 UTC. Place is the #tor-dev IRC channel in the OFTC network. Thanks!

1 0

getting clock skew on demand rather than by event?
by Patrick Schleizer 19 Jun '14

19 Jun '14

Hi, whonixcheck is a diagnostic utility that can be run on demand. Not a Tor controller, that is supposed to be run continuously. It checks things such as if Tor's pid is running, bootstrap status, DisableNetwork 1, tor --verify-config and more. There is one thing in the logs, that would be worth notify a user about it: [warn] Our clock is 4 hours, 47 minutes behind the time published in the consensus network status document [or clock too fast] Now, parsing the log sounds like an unclean solution. Tor control protocol can tell about CLOCK_SKEW, but it's "only" an event. And "event" sounds to me, only a controller that is continuously running would be capable to learn about it. Is it possible to use stem for something like:, "Tor, tell me right now about your latest info on current clock skew"? Similar to tor_bootstrap_check.py? Cheers, Patrick [1] https://github.com/Whonix/anon-shared-helper-scripts/blob/master/usr/lib/an…

2 1

[GSoC] Consensus diffs - Second report
by Daniel Martí 19 Jun '14

19 Jun '14

Hello everyone, This is the second status report of my Google Summer of Code project, which is to implement consensus diffs for Tor. We hold weekly meetings every Wednesday at 14h UTC with the project mentors Nick and Sebastian. When I sent my first report I was a bit behind schedule as per my own timeline, mainly due to finals. These past two weeks I've been catching up on that timeline. I am now finishing the first part of it, which is to implement the diff generation code. If you read the last report, you might remember that the biggest issue at the time was performance. The code I had worked, but it was very pricy due to the quadratic time it took to compute a consensus diff, translating in running times from 10 to 20 seconds. In that e-mail I explained an idea I had in mind to overcome that. It got implemented and tested, and it works as expected. Now a diff generation between two consensus files takes roughly 0.04 seconds, which is almost the same amount of time that 'diff -e' takes. No precision seems to have been lost, but we'll have to do some edge case tests to verify that. The code was also missing documentation and some tor_asserts to make it more robust and understandable. That is what I'm finishing up at the moment, and then the tests will be the only task left. On to the second timeline item, which is the diff application code - The code sample I wrote for my application was a very simple version of it, supporting only 'delete' ed commands and just writing to stdout line-by-line. Taking that code as a starting point, plus being able to re-use some chunks from the diff generation code, I was able to have a working version in a few hours. So, like the diff generation bit, now that it seems to work properly it's time to document it properly and do some tests. I have until July 5th to finish these two tasks as per my own timeline, so I should be well able to have them done by then. The upcoming timeline item will be the joining of these chunks of code with Tor, at which point I expect some issues to arise. So I would like to get started with that bit the sooner the better, to have more time to get everything working and tested before we run out of time. As usual, any comments or ideas are very welcome. -- Daniel Martí - mvdan(a)mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C

1 0

Tor Geolocating exit nodes.
by JP Wulf 19 Jun '14

19 Jun '14

So Griffin Boyce is canvasing for some input to improve Tor, specifially for Journalists. https://twitter.com/abditum/status/479052228138119168 1. It is known that various actors are trying to compromise Tor comms by establishing own exit nodes. With enough nodes, they can break Tor (see slides). 2. Idea: Is it possible to allow the end user to determine the geo-location (with various degrees of fine tuning from hemisphere, through continental, to top country domain to regional? (I have NFI about the inner workings of TOR protocol and new work on it) For example. Say a journalist in Russia is using Tor, s/he declares in their tor client, that they only want to use exit nodes in South America and Australia. Thus minimising the chance the nodes are owned. This geolocation could perhaps be used to validate the integrity of the nodes (how I dont know, maybe by establishing TOR honeypots that can only be compromised through traffic through a compromised (owned) exit node). Risk: This is a rats nest, because if implemented incorrectly it may allow hostile actors to direct exit nodes to those that are owned. Thanks for reading my fiction. Maybe its useful in the light of what Griffin is asking about. -- JP Wulf Problem Solution Engineering http://nomeonastiq.com/

4 3