tor-dev July 2014

tor-dev@lists.torproject.org

79 participants
83 discussions

Crippled intro points
by Andrea Shepard 21 Jul '14

21 Jul '14

A recent thread has advocated crippling relays to selectively refuse to act as intro points for hidden services. Unfortunately, with the current HS design it would be implementable. I state my opposition to adding any such censorship feature now, and look forward to an improved HS protocol that will make it impossible. Also, note that it would be possible to patch Tor to do this without any official protocol changes, but this would have the effect of leaving the targeted HSes no way to discover intro points that will accept them other than trial and error. This strikes me as something that would comprise an attack on the network and be good grounds for a !reject. -- Andrea Shepard <andrea(a)torproject.org> PGP fingerprint (ECC): BDF5 F867 8A52 4E4A BECF DE79 A4FF BC34 F01D D536 PGP fingerprint (RSA): 3611 95A4 0740 ED1B 7EA5 DF7E 4191 13D9 D0CF BDA5

1 0

ANN: txtorcon 0.10.1
by meejah 20 Jul '14

20 Jul '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, A new minor release of txtorcon exists, fixing a couple bugs introduced along with the endpoints feature in 0.10.0: * issue #78: Add tox tests and fix for Twisted 12.0.0 (and prior), as this is what Debian squeeze ships * issue #77: properly expand relative and tilde paths for hiddenServiceDir via endpoints * fix bug incorrectly issuing RuntimeError in brief window of time on event-listeners You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/0.10.1 https://github.com/meejah/txtorcon/releases/tag/v0.10.1 sha256sum reports: 33f04523329b14accb2054b81c5da887c28b402c797ba895dc1ee58824e107f1 txtorcon-0.10.1-py2-none-any.whl 7a6e8fab71fd05c223d866b60b998cf308661ef1fc87d94e06c3b51f4ada4a6a txtorcon-0.10.1.tar.gz thanks, meejah -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEbBAEBAgAGBQJTzD25AAoJEMJgKAMSgGmnB8IH+MnRyCCKMgPJ2GjV01K+PVaU UgvUXhaqLdQUbViKeYy7KNst9d8Dm3ejHr21kedE8oeY/ztHlLdvtJtgWWvTOrTI qqh4wWfBVHeibSgsEzwNVdeJ3MtERPWuCrIkIWnathbVjfnkRW+cLPOtJUWtSi/d pdN4ZC+K1jBvSeHPCDhf8sXSqdzsOxXOWn/9SUaa70c7kMrbxjMxO1Jw/miqftMq /wo0vyXn4EeEdURa9hYFpUqgUbUFl6C1KiELNeHWtwGbGWku17bNgQn5HH7uY4/6 RODYBaAT327062m81ig7zQ6MmxKcngIG4Ic3qvJYeLerO/EnnNvzSs3Q+EGQeg== =nsEx -----END PGP SIGNATURE-----

1 0

[GSoC] Consensus diffs - Fourth report
by Daniel Martí 20 Jul '14

20 Jul '14

Hello everyone, Apologies for the delay, I'm a couple of days late. This is the fourth status report of my Google Summer of Code project, which is to implement consensus diffs for Tor. My mentors - Sebastian and Nick - and myself usually hold meetings on IRC on wednesday at 16h UTC. On the first week I finished implementing the consensus diff headers as described in the updated proposal #140 [1], including full SHA256 hashes of each of the two consensuses involved: the base one and the resulting one. I also finished the tests for that bit. Moreover, I thought it would make sense to make sure that the diff generation process never takes too long. In theory it should always be linear in time given any two realistic consensus files, since it would navigate the router entries and take advantage of them being sorted alphabetically. But if no matching router entries are found between the two consensuses, the algorithm would run in quadratic time. Running in quadratic time over two sets of 25K lines takes about 20 seconds on my laptop, which is pretty bad. So I made the algorithm error if 10K lines are found on both sides without any matching router entry id. Which makes perfect sense for any pair of consensuses - even if you take consensuses months or years apart, it would never occur that they shared so few router ids. And if they did, generating a diff between them would make no sense. Unfortunately, I wasn't able to do much else during that week since I was at RMLL running a Free Your Android workshop for the whole week. And just when I got home on Saturday, my laptop broke down, which kept me busy for a few days as well. Nevertheless I am still on schedule. What I must do now is start merging my code into a Tor feature branch, so that I can write the bits of code that will glue everything together. To do that, I've begun rewriting my git history so that it is simpler to understand and read. If you have a look at my new repo on github [2], you'll notice that the number of commits went down from 122 to 95, and quite a few were rewritten as well. Open to suggestions about how to further improve it. By the time the next report is due - August the 1st - I should have completed the integration of my code into Tor. Then comes writing some more tests and testing Tor with the new feature in place. [1] https://gitweb.torproject.org/torspec.git/blob_plain/refs/heads/master:/pro… [2] https://github.com/mvdan/tor/branches -- Daniel Martí - mvdan(a)mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C

1 0

hidden service involvement in external program
by Tomas Bortoli 20 Jul '14

20 Jul '14

Hi all, I want to develop a program that connects to a hidden server through tor. This is my problem: how can i establish a connection to the server from the client? I read the hidden service protocol, but i need a usable implementation of it. So i was looking in stem but seems it doesn't provide this functionality, i'm wrong? Anyone have an idea of how can i achieve a solution?? any library already implemented? Thanks!

3 2

Hidden services mailing list
by Michael Rogers 20 Jul '14

20 Jul '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, Several projects use Tor hidden services for peer-to-peer communication, including TorChat, TORFone, Ricochet, Ploggy, OnionShare, Invisible.im, Ciboulette and Briar. I suspect many of us are running into similar issues because the hidden service protocol and implementation were designed for hidden services that behave like servers rather than clients, i.e. that have long uptime and stable network connections. I've created a mailing list to discuss these issues. If you're interested in participating, you can join the list here: https://fulpool.org/cgi-bin/mailman/listinfo/hidden-services Cheers, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJTy9lOAAoJEBEET9GfxSfMZMIH/jHmO6/RlLUDSaEcxtgSsO1W rlxW9oPCmwoFg258+1FRAVmfpqmUxmr0RTMiG4yb2Go23mM7HmnNVJz0mRXJsMxA 1Bu9cEUlROYDL1SEMoc8Apt6ymZUTOxknYIrXRsNJlfEPCmte9Vf8i8xjZJna6cr QpL+/1C/NmD8synteIJvHTCu1pa4MMHlLfjawSJzavaP2dMK/IVz12XDrdBx8zQU GNUt/FanZ5Cc8AUQHsd/+eC2ey24yg3iMH/yhgaU1zdG05T2wcyXjOVe70cHo6Lk Z3aaXaXg9tyISXuTCQXNjdrurwv9MlTjwvOZt6sGbOOvxHKh0S0N9X8txfEusJ8= =uOE9 -----END PGP SIGNATURE-----

1 0

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

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev July 2014