January 2014 - tor-dev - lists.torproject.org

GSoC project idea: pluggable transport that hides data in TCP SEQ numbers / UDP SRC ports
by Jacek Wielemborek 10 Jan '14

10 Jan '14

Hi, I recently had an opportunity to watch David Fifield's lightning talk on pluggable transports that he gave on 30C3. I find the topic fascinating and I'm considering an application to your project for the upcoming Google Summer of Code. My idea is a bit complicated - I'd like to create a pluggable transport that hides data in TCP sequence number gaps or UDP source port numbers. I don't yet have all details thought over, but the way I imagine it right now, the user would have to … [View More]

5 4

"Sniper attack" paper by Rob Jansen, Florian Tschorsch, Aaron Johnson, and Björn Scheuermann
by Nick Mathewson 09 Jan '14

09 Jan '14

Hi, all! I see that the NDSS programme is now online: http://www.internetsociety.org/ndss2014/programme One of the papers describes a neat set of attacks described in this paper where an adversary can try to track users by DoSing nodes by running those nodes out of memory. The memory DoS attack from this paper are fixed, thanks to advice from the paper's authors, in Tor 0.2.4.x and later, and we're working on improvements to the rest of our memory management as well. Rob Jansen tells me he's … [View More]

1 0

Another helping hand
by David Murray 08 Jan '14

08 Jan '14

Hi All, I'd like to volunteer time to the tor project. I can program in C and python with a modest to reasonable degree of competence. I'm not hugely familiar with the Tor codebase, so I thought that writing tests would be a good place to start. Is there any C or Python sub-project that would like someone to write some tests? David

2 2

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, … [View More]

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 … [View More]

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 … [View More]

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 … [View More]

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 … [View More]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 [View Less]

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 (… [View More]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 [View Less]

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 … [View More]

1 0