- tor-dev - lists.torproject.org

Re: [tor-dev] [tor-reports] boklm's report for December 2013
by Karsten Loesing 07 Jan '14

07 Jan '14

[Replying on tor-dev@, because I think tor-reports@ is not meant for discussions.] On 1/7/14 12:43 AM, Nicolas Vigier wrote: > - continued to review current status of automation in tor project, and > needs: > https://people.torproject.org/~boklm/automation/tor-automation-review.html > > [...] > > - wrote some proposals for things to do in automation in coming months: > https://people.torproject.org/~boklm/automation/tor-automation-proposals.ht… Hi Nicolas, these two documents look like something you have put a lot of work into and that you're still working on. Putting them on people.tpo has a few (major, IMHO) disadvantages: nobody will learn about these documents unless they know the exact URL, nobody will be notified when they change (and therefore see that you're working hard on them), there's no history, and when you delete them (by mistake) they're gone forever. How about moving these two documents to the wiki? Possible URLs could be https://trac.torproject.org/projects/tor/wiki/doc/automation/review and https://trac.torproject.org/projects/tor/wiki/doc/automation/proposals. You could mention at the beginning that people should talk to you before editing these pages. All the best, Karsten

2 1

fuzzer for tor as a masters project
by Pietro Bempos 07 Jan '14

07 Jan '14

Hello, I was browsing the tor site in order to find an idea for my masters project in security and I came across the following: ---------------------------------------------------------------------- In your project ideas page https://www.torproject.org/getinvolved/volunteer.html.en#torCleanup You have the following : Write a fuzzer for Tor to discover security vulnerabilities. Determine if there are good fuzzing frameworks out there for what we want. Win fame by getting credit when we put out a new release because of you! ------------------------------------------------------------------------------------ I have no experience in fuzzers but I think it would be a very nice topic to learn and on the same time contribute. I see that it is possible to create a private tor network for testing https://www.torproject.org/docs/faq#PrivateTorNetwork And maybe use the command line options to have as one point of input https://www.torproject.org/docs/tor-manual.html.en Bassically I send this email for 2 reasons: 1) To see if there are ways that you guys can help me with this on the future and 2) To give me any starting tips mostly related to what type of data that would be good for testing, any other input places from where data can be fed and generally any kind of usefull info related to this. Thanks a lot and have a nice day Pietro.

2 1

Small FTE question
by George Kadianakis 04 Jan '14

04 Jan '14

Hello Kevin, I saw your recent changes to the FTE codebase. The code looks nice! I then tried to test it, but I got a bit confused by the CLI. I wanted to try the good ol' ncat test, where I put FTE in the middle, an ncat listener on the server side, and an ncat client on the client side, and throw bytes around. How would I do that with the FTE CLI? I looked at https://fteproxy.org/docs/0.2/fteproxy.html but I'm not sure how to use the server_port and client_port switches properly. Can I configure the client-side to push data to a specific destination, or is it always a SOCKS listener? Also, is there a way to make fteproxy increase its logging verbosity? Thank you!

2 3

CellStatistics circuit distribution scale could perhaps use adjustment
by starlight＠binnacle.cx 04 Jan '14

04 Jan '14

Have been running a guard for a couple of months with 'CellStatistics' and noticed that the distribution looks out of whack: cell-stats-end 2013-12-20 18:13:10 (86400 s) cell-processed-cells 1409,9,6,6,6,5,4,3,2,1 cell-queued-cells 0.44,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00 cell-time-in-queue 98,1,1,1,0,13,2,1,1,0 cell-circuits-per-decile 15199 Seems like most of the circuits with significant traffic end up in the first bucket and the remaining nine buckets are of little significance. I'm fairly certain that a relative handful of circuits account for 99.9% of the cell traffic with cell-counts in the tens-to-hundreds of thousands. Most of that bot traffic I suppose. Perhaps a log-scaled "loudness" breakdown would make sense? Nothing pressing here, just an observation and a thought.

2 1

TBB 3.5 build failure
by Steve Snyder 02 Jan '14

02 Jan '14

Attempting to build tbb-3.5.1-build1, and failing. See below for failure. I am building on a fully-updated Ubuntu v12.04LTS/x86_64 system. I am using the USE_LXC method because KVM won't work in this VMware VM. On my first attempt I did a "make all". That didn't work, so I tried "./mkbundle-linux.sh" (all I really care about is a Linux/x86_64 build) and got the same error at what seems the same point in the build process. This problem isn't listed in the "Known Issues and Quirks" section of the doc. Can anyone advise me on how to fix this problem? Thanks. ----------------------- 2013-12-28 20:08:35,138 INFO : Searching for GRUB installation directory ... found: /boot/grub 2013-12-28 20:08:35,164 INFO : Calling hook: install_kernel 2013-12-28 20:08:59,860 INFO : Done. 2013-12-28 20:09:01,503 INFO : Running depmod. 2013-12-28 20:09:01,595 INFO : update-initramfs: Generating /boot/initrd.img-2.6.32-54-server 2013-12-28 20:09:06,598 INFO : Running postinst hook script /usr/sbin/update-grub. 2013-12-28 20:09:06,735 INFO : Searching for GRUB installation directory ... found: /boot/grub 2013-12-28 20:09:06,835 INFO : Searching for default file ... found: /boot/grub/default 2013-12-28 20:09:06,842 INFO : Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst 2013-12-28 20:09:07,159 INFO : Searching for splash image ... none found, skipping ... 2013-12-28 20:09:07,261 INFO : Found kernel: /boot/vmlinuz-2.6.32-54-server 2013-12-28 20:09:07,536 INFO : Replacing config file /var/run/grub/menu.lst with new version 2013-12-28 20:09:07,605 INFO : Updating /boot/grub/menu.lst ... done 2013-12-28 20:09:07,611 INFO : 2013-12-28 20:09:07,723 INFO : Calling hook: post_install 2013-12-28 20:09:07,753 INFO : Calling hook: unmount_partitions 2013-12-28 20:09:07,754 INFO : Unmounting target filesystem 2013-12-28 20:09:11,171 INFO : Calling hook: convert 2013-12-28 20:09:11,172 INFO : Converting /tmp/tmptolHOn to qcow2, format base-lucid-amd64/tmptolHOn.qcow2 2013-12-28 20:09:27,192 INFO : Calling hook: fix_ownership 2013-12-28 20:09:27,207 INFO : Calling hook: deploy 2013-12-28 20:09:27,208 INFO : Calling hook: fix_ownership Extracting partition for lxc [sudo] password for steve: lxc-start: No such file or directory - failed to get real path for '/home/steve/buildtbb/gitian-builder/target--' lxc-start: failed to pin the container's rootfs lxc-start: failed to spawn 'gitian' lxc-start: No such file or directory - failed to remove cgroup '/sys/fs/cgroup/cpuset//lxc/gitian' amd64 lucid VM creation failed

2 1

Re: [tor-dev] bridgdb automation
by isis agora lovecruft 02 Jan '14

02 Jan '14

Nicolas Vigier transcribed 1.4K bytes: > Hi, Hey Nicolas, Thanks for all the work you're doing, and my apologies that I hadn't responded to your tor-dev@ call yet. Just in case you haven't seen it, Lunar made a wiki page which has quite a bit of info on it, and I filled in some more on BridgeDB. [0] aabgsn maintained BridgeDB for a year or so, but no longer works on it (though they are more than welcome to do so, if they wish to). sysrqb has been helping me maintain BridgeDB quite a bit (feel free to CC them on BridgeDB topics). > I am currently looking at the status and list of things to be done > regarding automation on tor project. I have been looking at bridgedb : > https://people.torproject.org/~boklm/automation/tor-automation-review.html#… From that page: > Continuous Build > BridgeDB is not currently built and tested by Jenkins. > > However, Isis Lovecruft has a personnal development fork on github that is > built and tested by travis-ci.org: > https://travis-ci.org/isislovecruft/bridgedb/ > > Packaging > BridgeDB does not have packages. It is currently deployed using a Python virtualenv. > To my knowledge, BridgeDB is not currently deployed in a virtualenv (sysrqb was the last to redeploy it). I recently refactored the main loop and scripts so that it *can* run in a virtualenv, and it *should* be run in one, because: 1. We won't need to nag weasel/Sebastian to update/install BridgeDB dependencies. 2. Dependencies will not be installed via sudo. I've been considering creating packages for BridgeDB on PyPI. Pros: * Even if we manually download the bundle, verify the hash, and then install it, this seems potentially easier and less error-prone than checking out a git tag, verifying it, and then building. * Packaging it now reserves the 'bridgedb' Python namespace for our use. Cons: * I don't want to make people think that this thing is a polished distribution system for people who wish to run their own BridgeAuths. If proper packaging is helpful for Jenkins, however, I can easily do so. > Testing > Some unit tests are implemented in lib/bridgedb/Tests.py and can be run with > the command python setup.py test. Actually, the tests in lib/bridgedb/Tests.py are old tests. Running them with `python setup.py test` or `make test` will run them via the Python stdlib unittest module (which doesn't play nicely with Twisted's asynchronicity). See #9865, #9872. [1] [2] There are new tests in lib/bridgedb/test/test_*.py [3] and they can be run with `[sudo] make [re]install && bridgedb test`. I began setting up a system which will run the old lib/bridgedb/Tests.py unittests with Twisted's trial runner (#9873). [4] The old unittests will get run twice, once with removed/deprecated classes and functions which have been taken out of BridgeDB's codebase, and again with new/refactored code; this way, the old unittests function as a (partial) regression test suite. The way I designed it, the removed/deprecated code (various classes/functions before refactoring) will go into lib/bridgedb/test/deprecated.py, and they are `twisted.python.monkey.MonkeyPatch`ed into place for a run of the old unitests in lib/bridgedb/Tests.py. Then, the old unittests are run a second time with the newly refactored code, so that the difference between the two can be clearly seen, and bugs introduced by new code can (hopefully) be caught immediately. > > Proposals > Add BridgeDB build and test to Jenkins Created ticket #10417: BridgeDB should be built and tested on Jenkins https://trac.torproject.org/projects/tor/ticket/10417 > The main thing to be done that I have seen is running the unit tests > with Jenkins when there are new commits. You can let me know if I missed > something important, or if you have other ideas / needs. Needs: 1. We need a lot more unittests, but this is perhaps not a task for volunteers (or, rather, people who aren't very familiar with BridgeDB's code). 2. BridgeDB needs *a lot* more documentation. It had almost none when I started working on it 6 months ago; it has a few bits now. [8] Questions: 1. Does it help if I use tox? [5] [6] 2. If not, I believe you'll need a shell script which Jenkins can use to install BridgeDB in a virtualenv. [7] Or do you need some sort of Maven thing, or both? 3. Is there somewhere I should put that documentation on torproject.org (other than people.tpo/~isis)? [0]: https://trac.torproject.org/projects/tor/wiki/AutomationInventory [1]: https://trac.torproject.org/projects/tor/ticket/9865 [2]: https://trac.torproject.org/projects/tor/ticket/9872 [3]: https://gitweb.torproject.org/user/isis/bridgedb.git/tree/refs/heads/develo… [4]: https://trac.torproject.org/projects/tor/ticket/9873 [5]: http://tox.readthedocs.org/en/latest/ [6]: http://alexgaynor.net/2010/dec/17/getting-most-out-tox/ [7]: http://www.alexconrad.org/2011/10/jenkins-and-python.html [8]: https://para.noid.cat/bridgedb/ Thanks, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ GPG: 4096R/A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt

3 5

Damian's Status Report - December 2013
by Damian Johnson 01 Jan '14

01 Jan '14

Hi all, hope you've enjoyed the holidays (and for a few of you CCC)! This December I finally swapped back to focusing on arm in earnest. Good news is that the codebase is rapidly improving [1], the focus for this month being... * Finished overhauling the starter module. * Expanded test coverage as more of arm gets rewritten. * Integrated pyflakes and pep8 with our tests. * Moved user facing strings to the internal configuration. I did this to improve our code, but it could also allow us to add internationalization support to arm in the future if folks want it. [2] Bad news is unfortunately that none of these improvements are user facing, and even by the rosiest estimates arm's next release is still many months off. This December I also finished with my efforts to revise our internal lists. None of the more substantial changes got much support, but this still resulted in some worthwhile improvements... * A wiki with our lists, maintainers, and a brief summary of each... https://trac.torproject.org/projects/tor/wiki/doc/emailLists * We now have a public, documented policy for adding folks to our internal lists. * The tor-assistants list is now a proper subset of tor-internal. * Identified some unused lists we can drop. [3] Cheers! -Damian [1] https://gitweb.torproject.org/arm.git/shortlog/5eebd00?hp=ff27d2a [2] https://gitweb.torproject.org/arm.git/blob/HEAD:/arm/config/strings.cfg [3] https://trac.torproject.org/10463

1 0

exit-node block bypassing
by Ximin Luo 01 Jan '14

01 Jan '14

Hey all, Flashproxy[1] helps to bypass entry-node blocks. But we could apply the general idea to exit-nodes as well - have the exit-node connect to the destination via an ephemeral proxy. The actual technology probably needs to be different since we can't assume the destination has a flashproxy (websocket/webrtc) PT server running, but we could probably find a technical solution to that. However, I talked this over with a few people and there might be legal and security issues. A few points: - running an exit node carries a great risk, it would be bad/unethical to let ephemeral proxy runners take this risk - (for security reasons we don't fully understand) there is a process for trusting exit nodes and/or detecting misbehaviour (I see badexit emails from time to time). this would be made much harder if exits were ephemeral. - someone could create a massive number of ephemeral exit nodes and capture a lot of exit traffic, giving them extra data to de-anonymise people. I was wondering if any of these have been discussed in depth before already, or if the general topic of exit-node block bypassing is something to be explored. X [1] http://crypto.stanford.edu/flashproxy -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git

3 3

Otter Buoyant Meeting Today - Delay
by Kelley Misata 31 Dec '13

31 Dec '13

Team - Today's meeting of the Otter Buoyant project needs to be postponed until next Tuesday, 1/7. My laptop is having problems and I will be offline this afternoon to repair it. (hopefully) See you all on IRC next Tuesday 1/7 - 3:30 pm (EST) - IRC #tor-dev. Happy New Years! Kelley -- *Kelley Misata* *Outreach and Communications* *The Tor Project* *www.torproject.org <http://www.torproject.org>*

1 0

Fwd: [guardian-dev] Building OpenSSL and Xtables for Orbot
by Nathan Freitas 28 Dec '13

28 Dec '13

-------- Original Message -------- Subject: [guardian-dev] Building OpenSSL and Xtables for Orbot Date: Sat, 28 Dec 2013 09:28:57 -0500 From: Nathan of Guardian <nathan(a)guardianproject.info> To: Guardian Dev <guardian-dev(a)lists.mayfirst.org> For a long time, building an up-to-date OpenSSL and iptables binary was a challenge for apps like Orbot which need it. Figuring out all the various flags and patches necessary was quite tricky, and the version bundles in the AOSP code were quite out of date. I am happy to say that both through my own persistence, recent patches by a few others, and improvements in the Android NDK toolchain, we can down build the latest OpenSSL and XTables/Iptables code from the original, direct git source. This means we have all the latest ciphers for Tor to use in order to better obscure traffic, and we have a bundled xtables binary in Orbot that can handle all of the transproxying rules we need, no matter what the built-in rooted firmware provides. You can find the updates build instructions in the Orbot external Makefile here: https://gitweb.torproject.org/n8fr8/orbot.git/blob/HEAD:/external/Makefile We will have beta of the new release, based on Tor 0.2.4.20 shortly. +n _______________________________________________ Guardian-dev mailing list Post: Guardian-dev(a)lists.mayfirst.org List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To Unsubscribe Send email to: Guardian-dev-unsubscribe(a)lists.mayfirst.org Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/nathan%40guardianpr… You are subscribed as: nathan(a)guardianproject.info

1 0