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

Re: [tor-dev] Implications of switching to a single guard node: some conclusions
by Mike Perry 25 Mar '14

25 Mar '14

Nicholas Hopper: > On Thu, Mar 13, 2014 at 5:21 PM, George Kadianakis <desnacked(a)riseup.net> wrote: > > tl;dr: analysis seems to indicate that switching to one guard node > > might not be catastrophic to the performance of Tor. To improve > > performance some increased guard bandwidth thresholds are proposed > > that seem to help without completely destroying the anonymity of the > > network. Enjoy the therapeutic qualities of the graphs and please read > > the whole post. > > This took way longer than I expected it to, but here we go. In order > to examine the assumption that "higher guard bandwidth == better > client performance", I modified Aaron Johnson's TorPS simulator to > simulate 50K clients in several different cases: > - "3guards": choose 3 guards according to the current algorithm > - "T=250": choose 1 guard, guard flag assigned as current > - "T=1000": choose 1 guard, filtering guards with measured bandwidth < > 1000 KB/s [Note: these former guards then have an increased > probability of being selected as middle and/or exit nodes] > - "T=2000": 1 guard, filter guards with measured bandwidth < T > - "T=3000": ibid > - "T=4000": ibid > For each client, the simulator created 600 circuits, and computed the > maximum bandwidth each circuit could handle (the minimum bandwidth of > the guard, middle and exit relays). This gives us an empirical > distribution on circuit performance for each client. Then we can ask > questions about the "typical" bandwidth for a client, e.g. the median > circuit performance. How many clients typically have low-bandwidth > circuits in each case? Looking at the 5000 (10%) unluckiest clients, > we see the following behavior: > > https://www-users.cs.umn.edu/~hopper/guard_threshold_median_bandwidth.png > > Essentially, while the current guard threshold does make the > unluckiest clients pretty sad on average, even a 1MB/s threshold means > that on average things are a little bit brighter than the current > situation, and a 2MB/s threshold for the guard flag makes everyone > happier in the typical case. (And increasing the threshold beyond > 2MB/s doesn't really help much) Cool. This is exactly the type of experiment I was hoping someone would do before we switched. Thanks for doing it! However, one thing strikes me though: We see clearly that 1 guard is worse than 3 guards with the current cutoff. I wonder if this is a coincidence, or if it is a property of the low cutoff, or something else**. For control, it would be nice to know what we would be giving up if we used that same T=2000 cutoff with three guards and compare that to T=2000 with just one guard. Is it easy for you to rerun just that comparison (since you seem to be suggesting that T=2000 is a good cutoff anyway)? ** The reason I ask is because I suspect there is actually an interplay between the current circuit build timeout code and the pool of 3 guards. The CBT cutoff will tend to cause you to avoid whichever of your guards may be temporarily overloaded at a given time. -- Mike Perry

2 2

Re: [tor-dev] Implications of switching to a single guard node: some conclusions
by Nicholas Hopper 25 Mar '14

25 Mar '14

On Thu, Mar 13, 2014 at 5:21 PM, George Kadianakis <desnacked(a)riseup.net> wrote: > tl;dr: analysis seems to indicate that switching to one guard node > might not be catastrophic to the performance of Tor. To improve > performance some increased guard bandwidth thresholds are proposed > that seem to help without completely destroying the anonymity of the > network. Enjoy the therapeutic qualities of the graphs and please read > the whole post. This took way longer than I expected it to, but here we go. In order to examine the assumption that "higher guard bandwidth == better client performance", I modified Aaron Johnson's TorPS simulator to simulate 50K clients in several different cases: - "3guards": choose 3 guards according to the current algorithm - "T=250": choose 1 guard, guard flag assigned as current - "T=1000": choose 1 guard, filtering guards with measured bandwidth < 1000 KB/s [Note: these former guards then have an increased probability of being selected as middle and/or exit nodes] - "T=2000": 1 guard, filter guards with measured bandwidth < T - "T=3000": ibid - "T=4000": ibid For each client, the simulator created 600 circuits, and computed the maximum bandwidth each circuit could handle (the minimum bandwidth of the guard, middle and exit relays). This gives us an empirical distribution on circuit performance for each client. Then we can ask questions about the "typical" bandwidth for a client, e.g. the median circuit performance. How many clients typically have low-bandwidth circuits in each case? Looking at the 5000 (10%) unluckiest clients, we see the following behavior: https://www-users.cs.umn.edu/~hopper/guard_threshold_median_bandwidth.png Essentially, while the current guard threshold does make the unluckiest clients pretty sad on average, even a 1MB/s threshold means that on average things are a little bit brighter than the current situation, and a 2MB/s threshold for the guard flag makes everyone happier in the typical case. (And increasing the threshold beyond 2MB/s doesn't really help much) (This data is based on the consensus documents from 13 February 2014, chosen pretty much arbitrarily from the most recent month of archived consensus documents and relay descriptors) -- ------------------------------------------------------------------------ Nicholas Hopper Associate Professor, Computer Science & Engineering, University of Minnesota Visiting Research Director, The Tor Project ------------------------------------------------------------------------

1 0

Re: [tor-dev] GSoC 2014 Txtorcon/stem integration
by meejah 25 Mar '14

25 Mar '14

E M <einnhverr(a)gmail.com> writes: > I don't really know the "moving" pace you expect me to have, so I > safely draft the final/desired proposal in time, so I would appreciate > if my pace is no up to your expectations, to let me know so I could > adapt accordingly. After the weekend is fine. The next deadline, as I understand, is April 5 at which point we (Tor people) need to have all the proposals ranked. So, your final proposal would need to be ready some time before that (say, end of March latest) as we need time to put together final rankings (with many different mentors, etc) before then. We have something like 32 proposals in the pipeline, way more than can be accepted. Although I was involved in GSoC 2013, there were no proposals for the project so this is my first time, too ;) I guess in general, this is a bit like a job interview and a bit like a contest? As in: since not all the proposals we have are going to be accepted, the more you can make yours stand out, the better I'd say. Thanks, meejah

2 1

[Orbot patch] Fix building of openssl on newer systems
by Daniel Martí 25 Mar '14

25 Mar '14

This is probably due to newer auto-tools having slightly different configuration options. On a recent setup, the following occured: make[2]: arm-eabi-/opt/android-ndk/[...]/arm-linux-androideabi-gcc: Command not found It was, for some reason, making CC be arm-eabi- plus the path to the NDK. Forcing CC when running make works around this problem. --- external/Makefile | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/external/Makefile b/external/Makefile index 875fa90..0310bb2 100644 --- a/external/Makefile +++ b/external/Makefile @@ -84,17 +84,15 @@ all: assets lib/libcrypto.a: cd openssl && \ - CC="$(CC)" \ ./Configure android -DL_ENDIAN && \ - ANDROID_DEV=$(NDK_BASE)/platforms/android-8/arch-arm/usr make build_libs + make CC="$(CC)" ANDROID_DEV=$(NDK_BASE)/platforms/android-8/arch-arm/usr build_libs lib/libssl.a: cp config.sub openssl cp config.guess openssl cd openssl && \ - CC="$(CC)"\ ./Configure android -DL_ENDIAN && \ - ANDROID_DEV=$(NDK_BASE)/platforms/android-8/arch-arm/usr make build_libs + make CC="$(CC)" ANDROID_DEV=$(NDK_BASE)/platforms/android-8/arch-arm/usr build_libs openssl-build-stamp: lib/libcrypto.a lib/libssl.a touch openssl-build-stamp -- Daniel Martí - mvdan(a)mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C

1 0

Re: [tor-dev] GSoC 2014 Txtorcon/stem integration
by Damian Johnson 25 Mar '14

25 Mar '14

Hi Einnhverr. Moving this to tor-dev@ since you intended to but got the wrong address (it's tor-dev(a)lists.torproject.org) If you're not already subscribed to it then please do so at... https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev Cheers! -Damian On Tue, Mar 25, 2014 at 4:36 AM, E M <einnhverr(a)gmail.com> wrote: > On 3/25/14, meejah <meejah(a)meejah.ca> wrote: > >> I meant a small example as part of the proposal. The idea would be to >> demonstrate some understanding of the two libraries, Python itself and >> the issues involved. You should also compare your proposal to some of >> the others from past years that I linked to -- some more detail about >> what (you think) needs to happen would be useful. This doesn't >> necessarily need to be 100% correct, but will give us some idea that >> you've thought through the issues and design. > > Hi meejah, > > I will take the time over the weekend to include some small example in > the proposal, along with more fine graned points about the work I > think should be done and other ajustments(e.g. rework the estimated > deliverables you suggested). > > I don't really know the "moving" pace you expect me to have, so I > safely draft the final/desired proposal in time, so I would appreciate > if my pace is no up to your expectations, to let me know so I could > adapt accordingly. > > >> p.s. the way most people use #tor-dev on IRC is to stay logged in >> (e.g. via a tmux or screen session) so that timezones and so forth can >> allow answers to happen later on. > > I'm in the process of setting up an VM environment with a IRC bouncer > so I could be available as much as possible on the #tor-dev channel. > My usual available hours, after setting up the bouncer is complete, > are 04:00 - 20:00 UTC(excluding the hours when I'm in class) > > I'm always open to any suggestions regarding the > proposal/process/project, please don't hesitate to bring them up to > me. > > I appreciate for taking your time out of your schedule to guide me > through this process! > > Thank You, > einnhverr On Tue, Mar 25, 2014 at 4:36 AM, E M <einnhverr(a)gmail.com> wrote: > On 3/25/14, meejah <meejah(a)meejah.ca> wrote: > >> I meant a small example as part of the proposal. The idea would be to >> demonstrate some understanding of the two libraries, Python itself and >> the issues involved. You should also compare your proposal to some of >> the others from past years that I linked to -- some more detail about >> what (you think) needs to happen would be useful. This doesn't >> necessarily need to be 100% correct, but will give us some idea that >> you've thought through the issues and design. > > Hi meejah, > > I will take the time over the weekend to include some small example in > the proposal, along with more fine graned points about the work I > think should be done and other ajustments(e.g. rework the estimated > deliverables you suggested). > > I don't really know the "moving" pace you expect me to have, so I > safely draft the final/desired proposal in time, so I would appreciate > if my pace is no up to your expectations, to let me know so I could > adapt accordingly. > > >> p.s. the way most people use #tor-dev on IRC is to stay logged in >> (e.g. via a tmux or screen session) so that timezones and so forth can >> allow answers to happen later on. > > I'm in the process of setting up an VM environment with a IRC bouncer > so I could be available as much as possible on the #tor-dev channel. > My usual available hours, after setting up the bouncer is complete, > are 04:00 - 20:00 UTC(excluding the hours when I'm in class) > > I'm always open to any suggestions regarding the > proposal/process/project, please don't hesitate to bring them up to > me. > > I appreciate for taking your time out of your schedule to guide me > through this process! > > Thank You, > einnhverr

1 0

Reminder: Tor weekly dev meetings Wednesday at 19:00 UTC
by Nick Mathewson 25 Mar '14

25 Mar '14

Hi, all. This is another developer's meeting for working on the program "tor". (This won't cover all the other programs developed under the Tor umbrella.) We're going to try doing the weekly meeting on Wednesday. The meeting time will be: Wednesday March 26, 19:00 UTC. (That's 3pm EDT and 12:00 noon PDT) As before, we'll do it on the #tor-dev IRC channel, unless the meeting turns out to be too disruptive for the rest of the channel or vice versa. Starting in April, I'll be sending these reminders out monthly rather than weekly, unless that causes a huge drop in attendance. peace, -- Nick

1 0

Re: [tor-dev] Stegotorus - google unit tests
by vmon＠riseup.net 25 Mar '14

25 Mar '14

Hey Noah, It seems that you successfully compiled Stegotorus, congratulation! ;) Although, you still have problem with compiling the unit tests in google framework, they are not essential in solving your challenge. I recommend that you start working on your challenge now. Per Google's recommendation, I've included the google unit test code inside the code, so that g_unittests_LDFLAGS probably won't help (because you are linking to the object file directly). You might want to download the google frame work and try to compile it independently without the stegotorus headache: https://googletest.googlecode.com/files/gtest-1.7.0.zip Keep the good work going! vmon Noah Rahman <selimthegrim(a)gmail.com> writes: > after fixing the local branch and having to remove -Werror by hand > from the makefile yet again...maybe I am missing something else in the > unit tests? I checked git branch -v and it now matches the tor-improve > on remote/tor-improve > > selimthegrim@Rimsky-Korsakoffee:~/stegotorus$ make -j2 > make all-am > make[1]: Entering directory `/home/selimthegrim/stegotorus' > depbase=`echo src/steg/payload_scraper.o | sed 's| > [^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/steg/payload_scraper.o -MD -MP -MF $depbase.Tpo -c > -o src/steg/payload_scraper.o src/steg/payload_scraper.cc &&\ > mv -f $depbase.Tpo $depbase.Po > /bin/bash ./src/genmodtable.sh protolist.cc src/protocol/chop.cc > src/protocol/chop_blk.cc src/protocol/null.cc > protolist.cc is unchanged > touch stamp-protolist > /bin/bash ./src/genmodtable.sh steglist.cc src/steg/b64cookies.cc > src/steg/cookies.cc src/steg/embed.cc src/steg/http.cc > src/steg/http_apache.cc src/steg/http_steg_mods/file_steg.cc > src/steg/http_steg_mods/pdfSteg.cc src/steg/http_steg_mods/swfSteg.cc > src/steg/http_steg_mods/jsSteg.cc src/steg/http_steg_mods/jpgSteg.cc > src/steg/http_steg_mods/pngSteg.cc src/steg/http_steg_mods/gifSteg.cc > src/steg/nosteg.cc src/steg/nosteg_rr.cc src/steg/payload_server.cc > src/steg/trace_payload_server.cc src/steg/payload_scraper.cc > src/steg/apache_payload_server.cc > steglist.cc is unchanged > touch stamp-steglist > depbase=`echo src/pgen_fake.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/pgen_fake.o -MD -MP -MF $depbase.Tpo -c -o > src/pgen_fake.o src/pgen_fake.cc &&\ > mv -f $depbase.Tpo $depbase.Po > /bin/bash ./src/test/genunitgrps.sh unitgrplist.cc > src/test/unittest_base64.cc src/test/unittest_compression.cc > src/test/unittest_crypt.cc src/test/unittest_pdfsteg.cc > src/test/unittest_socks.cc > touch stamp-unitgrplist > depbase=`echo src/test/tltester.o | sed 's|[^/]*$|.deps/&|;s|\.o$||' > `;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/test/tltester.o -MD -MP -MF $depbase.Tpo -c -o > src/test/tltester.o src/test/tltester.cc &&\ > mv -f $depbase.Tpo $depbase.Po > depbase=`echo src/test/webpage_tester.o | sed 's| > [^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/test/webpage_tester.o -MD -MP -MF $depbase.Tpo -c - > o src/test/webpage_tester.o src/test/webpage_tester.cc &&\ > mv -f $depbase.Tpo $depbase.Po > src/steg/payload_scraper.cc: In member function ‘int > PayloadScraper::scrape()’: > src/steg/payload_scraper.cc:283:49: warning: ignoring return value of > ‘int system(const char*)’, declared with attribute warn_unused_result > [-Wunused-result] > system(ftp_unmount_command_string.c_str()); > ^ > src/steg/payload_scraper.cc:312:49: warning: ignoring return value of > ‘int system(const char*)’, declared with attribute warn_unused_result > [-Wunused-result] > system(ftp_unmount_command_string.c_str()); > ^ > depbase=`echo protolist.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT protolist.o -MD -MP -MF $depbase.Tpo -c -o protolist.o > protolist.cc &&\ > mv -f $depbase.Tpo $depbase.Po > depbase=`echo steglist.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT steglist.o -MD -MP -MF $depbase.Tpo -c -o steglist.o > steglist.cc &&\ > mv -f $depbase.Tpo $depbase.Po > g++ -Wall -Wextra -Wno-missing-field-initializers -Wformat=2 - > std=c++0x -g -O2 -std=gnu++11 -o pgen_fake src/pgen_fake.o src/util.o > src/rng.o src/base64.o -lcrypto > depbase=`echo src/test/tinytest.o | sed 's|[^/]*$|.deps/&|;s|\.o$||' > `;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/test/tinytest.o -MD -MP -MF $depbase.Tpo -c -o > src/test/tinytest.o src/test/tinytest.cc &&\ > mv -f $depbase.Tpo $depbase.Po > depbase=`echo src/test/unittest.o | sed 's|[^/]*$|.deps/&|;s|\.o$||' > `;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/test/unittest.o -MD -MP -MF $depbase.Tpo -c -o > src/test/unittest.o src/test/unittest.cc &&\ > mv -f $depbase.Tpo $depbase.Po > depbase=`echo src/test/unittest_base64.o | sed 's| > [^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/test/unittest_base64.o -MD -MP -MF $depbase.Tpo -c > -o src/test/unittest_base64.o src/test/unittest_base64.cc &&\ > mv -f $depbase.Tpo $depbase.Po > depbase=`echo src/test/unittest_compression.o | sed 's| > [^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/test/unittest_compression.o -MD -MP -MF > $depbase.Tpo -c -o src/test/unittest_compression.o > src/test/unittest_compression.cc &&\ > mv -f $depbase.Tpo $depbase.Po > depbase=`echo src/test/unittest_crypt.o | sed 's| > [^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/test/unittest_crypt.o -MD -MP -MF $depbase.Tpo -c - > o src/test/unittest_crypt.o src/test/unittest_crypt.cc &&\ > mv -f $depbase.Tpo $depbase.Po > depbase=`echo src/test/unittest_pdfsteg.o | sed 's| > [^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/test/unittest_pdfsteg.o -MD -MP -MF $depbase.Tpo - > c -o src/test/unittest_pdfsteg.o src/test/unittest_pdfsteg.cc &&\ > mv -f $depbase.Tpo $depbase.Po > depbase=`echo src/test/unittest_socks.o | sed 's| > [^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/test/unittest_socks.o -MD -MP -MF $depbase.Tpo -c - > o src/test/unittest_socks.o src/test/unittest_socks.cc &&\ > mv -f $depbase.Tpo $depbase.Po > depbase=`echo unitgrplist.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT unitgrplist.o -MD -MP -MF $depbase.Tpo -c -o > unitgrplist.o unitgrplist.cc &&\ > mv -f $depbase.Tpo $depbase.Po > depbase=`echo src/test/gtest/gtest_main.o | sed 's| > [^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/test/gtest/gtest_main.o -MD -MP -MF $depbase.Tpo - > c -o src/test/gtest/gtest_main.o src/test/gtest/gtest_main.cc &&\ > mv -f $depbase.Tpo $depbase.Po > depbase=`echo src/test/gtest/gtest-all.o | sed 's| > [^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/test/gtest/gtest-all.o -MD -MP -MF $depbase.Tpo -c > -o src/test/gtest/gtest-all.o src/test/gtest/gtest-all.cc &&\ > mv -f $depbase.Tpo $depbase.Po > depbase=`echo src/test/steg_test/steg_mod_unittest.o | sed 's| > [^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/test/steg_test/steg_mod_unittest.o -MD -MP -MF > $depbase.Tpo -c -o src/test/steg_test/steg_mod_unittest.o > src/test/steg_test/steg_mod_unittest.cc &&\ > mv -f $depbase.Tpo $depbase.Po > depbase=`echo src/test/steg_test/payload_scraper_unittest.o | sed 's| > [^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/test/steg_test/payload_scraper_unittest.o -MD -MP - > MF $depbase.Tpo -c -o src/test/steg_test/payload_scraper_unittest.o > src/test/steg_test/payload_scraper_unittest.cc &&\ > mv -f $depbase.Tpo $depbase.Po > g++ -Wall -Wextra -Wno-missing-field-initializers -Wformat=2 - > std=c++0x -g -O2 -std=gnu++11 -o tltester src/test/tltester.o > src/util.o src/util-net.o -levent > depbase=`echo src/test/tester_proxy/tester_proxy.o | sed 's| > [^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/test/tester_proxy/tester_proxy.o -MD -MP -MF > $depbase.Tpo -c -o src/test/tester_proxy/tester_proxy.o > src/test/tester_proxy/tester_proxy.cc &&\ > mv -f $depbase.Tpo $depbase.Po > depbase=`echo src/http_parser/http_parser.o | sed 's| > [^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/http_parser/http_parser.o -MD -MP -MF $depbase.Tpo > -c -o src/http_parser/http_parser.o src/http_parser/http_parser.cc &&\ > mv -f $depbase.Tpo $depbase.Po > rm -f libstegotorus.a > ar cru libstegotorus.a src/base64.o src/compression.o > src/connections.o src/crypt.o src/mkem.o src/network.o src/protocol.o > src/rng.o src/socks.o src/steg.o src/util.o src/util-net.o > src/evbuf_util.o src/curl_util.o src/transparent_proxy.o > src/protocol/chop.o src/protocol/chop_blk.o src/protocol/null.o > src/steg/b64cookies.o src/steg/cookies.o src/steg/embed.o > src/steg/http.o src/steg/http_apache.o src/steg/http_apache.o > src/steg/http_steg_mods/file_steg.o src/steg/http_steg_mods/pdfSteg.o > src/steg/http_steg_mods/swfSteg.o src/steg/http_steg_mods/jsSteg.o > src/steg/http_steg_mods/jpgSteg.o src/steg/http_steg_mods/pngSteg.o > src/steg/http_steg_mods/gifSteg.o src/steg/nosteg.o > src/steg/nosteg_rr.o src/steg/payload_server.o > src/steg/trace_payload_server.o src/steg/payload_scraper.o > src/steg/apache_payload_server.o src/subprocess-unix.o protolist.o > steglist.o > : libstegotorus.a > /bin/bash ./src/audit-globals.sh src/base64.o src/compression.o > src/connections.o src/crypt.o src/mkem.o src/network.o src/protocol.o > src/rng.o src/socks.o src/steg.o src/util.o src/util-net.o > src/evbuf_util.o src/curl_util.o src/transparent_proxy.o > src/protocol/chop.o src/protocol/chop_blk.o src/protocol/null.o > src/steg/b64cookies.o src/steg/cookies.o src/steg/embed.o > src/steg/http.o src/steg/http_apache.o src/steg/http_apache.o > src/steg/http_steg_mods/file_steg.o src/steg/http_steg_mods/pdfSteg.o > src/steg/http_steg_mods/swfSteg.o src/steg/http_steg_mods/jsSteg.o > src/steg/http_steg_mods/jpgSteg.o src/steg/http_steg_mods/pngSteg.o > src/steg/http_steg_mods/gifSteg.o src/steg/nosteg.o > src/steg/nosteg_rr.o src/steg/payload_server.o > src/steg/trace_payload_server.o src/steg/payload_scraper.o > src/steg/apache_payload_server.o src/subprocess-unix.o protolist.o > steglist.o src/main.o > sed: -e expression #1, char 113: unknown option to `s' > touch stamp-audit-globals > g++ -Wall -Wextra -Wno-missing-field-initializers -Wformat=2 - > std=c++0x -g -O2 -std=gnu++11 -o unittests src/test/tinytest.o > src/test/unittest.o src/test/unittest_base64.o > src/test/unittest_compression.o src/test/unittest_crypt.o > src/test/unittest_pdfsteg.o src/test/unittest_socks.o unitgrplist.o > libstegotorus.a -levent -lcrypto -lz -lcurl -lboost_system - > lboost_filesystem -lconfig++ > g++ -Wall -Wextra -Wno-missing-field-initializers -Wformat=2 - > std=c++0x -g -O2 -std=gnu++11 -o tester_proxy > src/test/tester_proxy/tester_proxy.o -levent_openssl -levent -lssl - > lcrypto > g++ -Wall -Wextra -Wno-missing-field-initializers -Wformat=2 - > std=c++0x -g -O2 -std=gnu++11 -o webpage_tester > src/test/webpage_tester.o src/util.o src/util-net.o src/curl_util.o > src/http_parser/http_parser.o -levent -lcrypto -lz -lcurl - > lboost_system -lboost_filesystem -lconfig++ > g++ -Wall -Wextra -Wno-missing-field-initializers -Wformat=2 - > std=c++0x -g -O2 -std=gnu++11 -o stegotorus src/main.o libstegotorus.a > -levent -lcrypto -lz -lcurl -lboost_system -lboost_filesystem - > lconfig++ > g++ -Wall -Wextra -Wno-missing-field-initializers -Wformat=2 - > std=c++0x -g -O2 -std=gnu++11 -o g_unittests > src/test/gtest/gtest_main.o src/test/gtest/gtest-all.o > src/test/steg_test/steg_mod_unittest.o > src/test/steg_test/payload_scraper_unittest.o libstegotorus.a -levent - > lcrypto -lz -lcurl -lboost_system -lboost_filesystem -lconfig++ > /usr/bin/ld: src/test/gtest/gtest-all.o: undefined reference to symbol > 'pthread_key_delete@@GLIBC_2.2.5' > /lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO > missing from command line > collect2: error: ld returned 1 exit status > make[1]: *** [g_unittests] Error 1 > make[1]: Leaving directory `/home/selimthegrim/stegotorus' > make: *** [all] Error 2

1 0

Re: [tor-dev] Stegotorus - DELETE_METHOD
by vmon＠riseup.net 24 Mar '14

24 Mar '14

Hey Noah, I somehow lost your email and can't find it. But at first look it seemed to me that autoreconf(and configure) is not defining the DELETE_METHOD in config.h while it supposed to do so by virtue of "configure.ac:85:AX_CXX_DELETE_METHOD". Did you run autoreconf before going ahead with configure? FYI, this is how the bundler maker, makes stegotorus on a (relatively) clean debian x86_64 vm: git clone "$(STEGOTORUS_HOME)" "$(STEGOTORUS_WORK)" cd "$(STEGOTORUS_WORK)" && git checkout tor-improve #&& git checkout --detach "$(STEGOTORUS_TAG)" cd "$(STEGOTORUS_WORK)" && autoreconf cd "$(STEGOTORUS_WORK)" && ./configure PKG_CONFIG_PATH=`pwd`&& make For me after I run the autoreconf and configure, I'll have the following line in config.h: #define DELETE_METHOD = delete Could you please verify that and if not re-run the autoreconf, you might also want to share your automake and gcc version with me. You also might want to send me config.log for further investigation. Wish you all the best with your stegotorus adventure, vmon

1 0

Re: [tor-dev] Stegotorus - lisboost problem
by vmon＠riseup.net 23 Mar '14

23 Mar '14

Hey Noah, > The configure file cant seem to digest libboost (on ubuntu). i > installed 1.53-all-dev in /usr/lib/x86_64-linux-gnu/ and then took The problem is that not all distribution come with libboost.pc file (ubuntu/debian come with individual pc file for each component of boost but not one pc file for the whole boost library). I have left a libboost.pc file in the root directory of Stegotorus. Just copy it into /usr/lib/pkgconfig or where ever your other package config (.pc) files reside. We should resolve this problem more fundamentally if your application goes through. Thanks for your efforts and let me know if you managed to pass this barrier. Best of luck, vmon Noah Rahman <selimthegrim(a)gmail.com> writes: > The configure file cant seem to digest libboost (on ubuntu). i > installed 1.53-all-dev in /usr/lib/x86_64-linux-gnu/ and then took > that out and installed 1.54-all-dev in usr/lib. Even though I set the > libboost_LIBS variable properly. > > On Fri, Mar 21, 2014 at 3:13 PM, <vmon(a)torproject.org> wrote: > > > Noah Rahman <selimthegrim(a)gmail.com> writes: > > It says you'll have to enable modifications > > > Just did! I'll try to update the tickets sometime this weekend. >

1 0

GSoC 2014 : Rewrite Tor Weather
by Sreenatha Bhatlapenumarthi 22 Mar '14

22 Mar '14

Hi there! I am Sreenatha(lucyd). I am interested in working on Tor Weather this summer as a part of GSoC 2014. I helped Damian migrate weather to stem(#8264) last summer and have been following the work on it's rewrite. I made an attempt to further this by writing a couple of python scripts. 1. Relay Search using Onionoo : A python script[0] that uses onionoo's search functionality to find relays with specific fingerprint/nickname/IP address. For now, I've used a global variable to store the search results for better performance in case of a repeated query. Once the database structure for the new weather is confirmed, I'll modify it accordingly. Feedback on this is much appreciated. 2. Patch for #9889 : I've also submitted a patch[1] for #9889 that checks if a given relay qualifies for a t-shirt. I'd really appreciate if you could take a look at my work and suggest possible improvements or provide some advice regarding the project in general. Cheers, Sreenatha [0] - https://github.com/lucyd/weather-rewrite/blob/master/search_relay.py [1] - https://trac.torproject.org/projects/tor/ticket/9889#comment:3

2 3