- tor-dev - lists.torproject.org

help with minimal Tor build for Shadow
by Rob Jansen 22 Jul '14

22 Jul '14

Hi, Shadow uses CMake and a custom build process to build the Tor source files into a shadow-plugin (using Clang/LLVM and a custom pass). However, because my CMake build file is not smart enough to know how to turn orconfig.h.in into orconfig.h, I still have to run Tor through autotools first (and then build again with Clang). I’m hoping to eliminate at least parts of the Tor configure/make build process. Shadow for sure needs orconfig.h to exist, and I presume ./autogen.sh and ./configure is the best way to generate that. Does anyone know of a faster approach? (I’d like to avoid adding the rules to my CMakeLists.txt file, as it will be hard to keep up with Tor’s upstream changes to its Makefile.in.) However, still missing after the configure is at least or_sha1.i, and possibly other files. Presumably these are generated when running make (after configure). My custom Clang build fails without them. Is there a special make target in Tor that generates these “helper” files without building the entire Tor binary? If not, should/can there be? All the best, Rob

1 1

Typos in 224-rend-spec-ng.txt
by Tim 21 Jul '14

21 Jul '14

Hi All, I've found a few typos in the first few sections of 224-rend-spec-ng.txt at https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/224-rend-spe… I tried finding an existing bug or wiki entry on trac to log these against, but I couldn't find anything relevant with: https://trac.torproject.org/projects/tor/search?q=proposal+264 The typos are: (I read from the start to Section 2.2.3) Line 392, S 1.3, [IMD:AC]: 'knowledge od the contents' (knowledge *of* the contents) Line 618, S 2.2.1, [TIME-PERIODS]: 'a single set of hidden service directory' (*directories*) S 2.2.3. Where to publish a service descriptor: Line 702 : 'hsdir_n_replicas' should be 'n_replicas' to be consistent with lines 710-711: 'where n_replicas is determined by the consensus parameter "hsdir_n_replicas"' Line 733: "An HSDir should rejects a descriptor" (should *reject*) Hope this helps. Tim

3 2

Re: [tor-dev] [tor-relays] Hidden service policies
by grarpamp 21 Jul '14

21 Jul '14

On Sun, Jul 20, 2014 at 9:57 PM, Thomas White <thomaswhite(a)riseup.net> wrote: > Mike Hearn, > Simple. If you start filtering anything at all, regardless of what it > is ... then I will > block any connection of your relays to mine > ... > Freedom isn't free unless it is > totally free and a selective reading policy through Tor is not just a > bad idea as stated below, I find it outright insulting to me and > everyone else who cares about the free and open internet. The fact > somebody has the audacity to come to a project like Tor and propose > blacklisting mechanisms is jaw-dropping. > ... > As I recall, you are also the person who raised the idea of coin > tinting or a similar concept in the bitcoin community to identify > "suspect" coins and that backfired spectacularly on you. Yes, that is the person. Though the term is known as 'taint'. One of many discussions from that suggestion is here: https://bitcointalk.org/index.php?topic=333824.0 > so while you are reading this, let me know if you run any relays so I > can avoid them. router riker 207.12.89.16 9001 0 0 fingerprint 8657 6CF6 AA84 496F 62C0 5AFE 9F26 8962 A5F0 B2BD contact Mike Hearn <mike(a)plan99.net> accept *:8333 reject *:* Normally I would thank exits for passing BTC traffic, but now I'm unsure of this one (and a few others), especially given that's the only exit policy of the above node. To identify anon (Tor) coins for marking and tracking?

2 1

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