Re: [tor-dev] Obfsproxy client for Android
On 02/10/2012 08:11 AM, Roger Dingledine wrote: > On Fri, Feb 10, 2012 at 07:56:04AM -0500, Nathan Freitas wrote: >> > Thoughts on attempting to port and ship Obfsproxy client functionality >> > to Android? >> > Where should we begin? Any details on exactly what was done for the new >> > TBB? > Step one, build obfsproxy for Android. I expect your biggest problem > will be libevent2 since you won't have any packages for it. See Happy to say that libevent2 and obfsproxy have been successfully cross-compiled for Android w/o major patching, and all seems to be working well with a manually hacked version of Orbot. I have to get some sleep now, but should have a new Orbot proper build in 24 hours (with the help of Gsathya and Kensen from GP). I've posted some test binaries with an Android shell-based how to here: https://github.com/downloads/guardianproject/Orbot/obfsproxy-20120212a.tar.gz (.asc) *** This currently requires root, and Orbot should be deactivated. 1) adb push the files about to /data/local 2) adb shell; su 3) mv the files above from /data/local to /data/data/org.torproject.android/app_bin 4) chown the new files to the uid of the orbot app (e.g. "chmod app_2.app_2 tor"). find the uid by 'ls'-ing in the /data/data/org.torproject.android/app_bin folder 5) chmod 700 obfsproxy; chmod 700 tor; 6) export HOME=/data/data/org.torproject.android/app_bin 7) /data/data/org.torproject.android/app_bin/tor DataDirectory /data/data/org.torproject.android/cache -f /data/data/org.torproject.android/app_bin/torrc 8) Open Firefox Mobile with ProxyMob add-on, and you should be ready to roll. *** Feb 11 03:29:23.275 [notice] Tor v0.2.3.11-alpha (git-9ce9836f853d8a31) running on Linux armv7l. Feb 11 03:29:23.276 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning ... Feb 11 03:29:31.000 [notice] Bootstrapped 80%: Connecting to the Tor network. Feb 11 03:29:31.000 [notice] Bootstrapped 90%: Establishing a Tor circuit. Feb 11 03:29:32.000 [notice] new bridge descriptor 'maximatorbridge' (fresh): $55329E0FB775496D4479AC1E0D2CDE3B98D774C3~maximatorbridge at 212.112.242.160 Feb 11 03:29:32.000 [notice] new bridge descriptor 'ghobfsbridge1' (fresh): $10D5B1C21544B64EBC2A4275FE32A8D4A40405B5~ghobfsbridge1 at 213.108.105.129 Feb 11 03:29:32.000 [notice] new bridge descriptor 'torbridge42' (fresh): $9459581B2DA5458D19790C28918CB544B3854C8A~torbridge42 at 85.214.131.213 Feb 11 03:29:32.000 [notice] new bridge descriptor 'Unnamed' (fresh): $7C7DC083FFCFE383268B873D2CB046684B615648~Unnamed at 85.17.20.242 Feb 11 03:29:32.000 [notice] new bridge descriptor 'Unnamed' (fresh): $478208B87337CAC2E9391AD7B91D125193D5A641~Unnamed at 91.208.34.7 Feb 11 03:29:32.000 [notice] new bridge descriptor 'Unnamed' (fresh): $5F88FDA345422B32E1A20F2761182C23CD49EA79~Unnamed at 131.215.158.1 Feb 11 03:29:32.000 [notice] new bridge descriptor 'ndnop0' (fresh): $9D7259A696F7DAB073043B28114112A46D36CFFD~ndnop0 at 109.105.109.163 Feb 11 03:29:32.000 [notice] new bridge descriptor 'Unnamed' (fresh): $00BC5E7111BD00E9AF463BE9BFE6255FE51CFCD9~Unnamed at 109.163.233.195 Feb 11 03:29:33.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Feb 11 03:29:33.000 [notice] Bootstrapped 100%: Done. *** +n8fr8 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] First test "report"
Hi there,
I'm done with the first batch of work on the test side. You have the
(rebased just now) work here:
https://github.com/emanchado/tor/commits/master. The rest of this e-mail
summarises what I've done and explains my plan for further work.
The content of the commits
--
I have reviewed the whole test_util.c and made three kinds of changes:
1. Added more tests. Some of them failed, and after checking with other
people on IRC the conclusion seems to be that they should pass (ie. they
reproduce actual bugs in the code). To keep the test suite from failing,
they are inside "#if 0" blocks. So someone should look for "#if 0" inside
test_util.c and fix the code that makes those fail. Or maybe I should file
bugs for those?
2. In comparison assertions, the general convention seems to be to place
the expected value first ("test_eq(0, functioncall(...))" rather than
"test_eq(functioncall(...), 0)"). I have modified the assertions not
following that convention, so they all look the same.
3. General clean up, small code reorganisations, fix typos and such. Eg, I
have turned all the "tt_int_op(a, ==, b)" into "test_eq(a, b)".
I was thinking of blogging about what I saw (esp. related to point 1). I
think there are valuable lessons to be learned, which will help other
people writing tests (both for Tor and outside of Tor). I'm not sure if
there's enough content for a blog post, but if I do it after all, should I
post the link here?
Plan for the future
---
As I haven't explored coverage yet, I'll start with that for the code in
src/common/ and see what I can do. My gut feeling (without having looked
at other parts of the code yet!) is that tackling unit tests for code in
src/or/ will be hard for me, and it seems better to explain what kind of
things I have done in src/common/ so others, more familiar with that code,
can fix/improve the unit tests for src/or/*. In other words, it seems much
more effective for me to support someone who knows the code in src/or/*,
rather than the other way around.
After I'm done with what I think is easy enough for me to do with the unit
tests, I'll have a look at Stem (Damian's suggestion) and chutney (Nick's
suggestion), and decide what I do next.
--
Esteban
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] First test "report"
On Sat, Feb 11, 2012 at 7:12 AM, Esteban Manchado Velázquez
wrote:
> Hi there,
>
> I'm done with the first batch of work on the test side. You have the
> (rebased just now) work here:
> https://github.com/emanchado/tor/commits/master.
A suggestion: In the future, it's best to do commits on one or more
"topic branches", where each branch is for a separate kind of work.
That way, it's way easier for upstream to merge some of the commits,
hold off on others, and decline others.
As it stands, if you do all your commits in a "master" branch, and I
want to take some but not all of them, I have to cherry-pick the
individual commits. Worse still, your branch and the upstream branch
will then have diverged: if you try to pull the official repository
onto your master again, you won't have the actual history of the Tor
master branch , but some other thing that only exists on your master
branch. This can make stuff yucky fast.
For now, let's leave the current branches as they are. Once we've got
the contents of your current master branch reviewed/merged/not-merged,
you can reset your master to match tor's, and then do future work in
topic branches.
All that said: I like the granularity of your commits! Each one is
logically independent and easy to review.
> The rest of this e-mail
> summarises what I've done and explains my plan for further work.
>
> The content of the commits
> --
> I have reviewed the whole test_util.c and made three kinds of changes:
>
> 1. Added more tests. Some of them failed, and after checking with other
> people on IRC the conclusion seems to be that they should pass (ie. they
> reproduce actual bugs in the code). To keep the test suite from failing,
> they are inside "#if 0" blocks. So someone should look for "#if 0" inside
> test_util.c and fix the code that makes those fail. Or maybe I should file
> bugs for those?
Filing bugs is the right move; it looks like you've already started to do this.
>
> 2. In comparison assertions, the general convention seems to be to place the
> expected value first ("test_eq(0, functioncall(...))" rather than
> "test_eq(functioncall(...), 0)"). I have modified the assertions not
> following that convention, so they all look the same.
Hm. I don't think we actually had a convention on this one.
> 3. General clean up, small code reorganisations, fix typos and such. Eg, I
> have turned all the "tt_int_op(a, ==, b)" into "test_eq(a, b)".
Actually, test_eq was the old way; tt_int_op is the newer way since we
switched to tinytest.
Some other comments:
In general, the hardest thing for me to review here is not whether
the tests are right, but whether they removed any old tests in
revising them. I'll need to have another look through the patch
series to be sure.
On commit 5740e0fc1f00fa91be107ee6c4315d114c5ffdc4, the snprintf()
calls there should be tor_snprintf().
On commit f40c04a2137724f7b285e8d69ee62e47df1f9049, "iff" is not a
typo. It is a standard abbreviation for "if and only if." We use it
to say things like "Return true iff X", since otherwise we would need
to say "Return true if X; return false otherwise." (If we just said
"Return true if X," the function would technically be allowed to
_always_ return true.)
> I was thinking of blogging about what I saw (esp. related to point 1). I
> think there are valuable lessons to be learned, which will help other people
> writing tests (both for Tor and outside of Tor). I'm not sure if there's
> enough content for a blog post, but if I do it after all, should I post the
> link here?
Please do!
peace,
--
Nick
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Obfsproxy client for Android
On 02/11/2012 03:55 AM, Nathan Freitas wrote: > sleep now, but should have a new Orbot proper build in 24 hours (with > the help of Gsathya and Kensen from GP). Quick update - good progress on Orbot. obfsproxy binary is fully integrated into the Orbot Android app, and all the updates to torrc configuration, etc are in and working. We have a build with bridges enabled and 10 obfs bridges configured by default. The user can modify this list through the existing Orbot settings screen. I am going to sleep on this now a bit, do some more testing tomorrow, post a public build, then ideally about 18 hours from now, put a build up for release for Iranian users. I've pushed what we have so far here: https://gitweb.torproject.org/n8fr8/orbot.git/shortlog/refs/heads/obfs G'night, n8fr8 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
