- tor-dev - lists.torproject.org

Re: [tor-dev] [RFC] Proposal draft: The move to a single guard node
by Nicholas Hopper 07 Apr '14

07 Apr '14

I think I'll have more to say later, but... On Wed, Mar 26, 2014 at 11:36 AM, George Kadianakis <desnacked(a)riseup.net> wrote: > 1.3. Age of guard as a factor on guard probabilities > > By increasing the guard rotation period we also increase the lack > of clients for young guards since clients will rotate guards even > more infrequently now (see 'Phase three' of [1]). > > We can try to mitigate this phenomenon by giving higher priority to > young guards to be picked as guards: > > To do so, everytime an authority needs to vote for a guard, it > reads a set of consensus documents spanning the past NNN months, and > calculates the age of the guard; that is, in how many consensuses > its public key has been included in the past. > > The authorities include the age of each guard by appending > '[SP "Age=" INT]' in the guard's "w" line. > > When a client picks a guard, it applies the age of each guard as a > weight on its guard probability. XXX unspecified how I'm pretty sure this section has it backwards from what was the intent of the discussion of "guard age" at the dev meeting. The weight factor should be applied when choosing a "new guard" as a middle or exit node, because it is being underutilized as a guard. This makes it straightforward to apply: if relay R has had the guard flag for fraction k of the last rotation period, then its weight for some other position should be k*(weight with the guard flag) + (1-k)*(weight without the guard flag) -- ------------------------------------------------------------------------ Nicholas Hopper Associate Professor, Computer Science & Engineering, University of Minnesota Visiting Research Director, The Tor Project ------------------------------------------------------------------------

3 2

Re: [tor-dev] Stegotorus Challenge - Inheriting from FileStegMod
by vmon＠riseup.net 07 Apr '14

07 Apr '14

Hey Noah, Thanks a lot for the patch. You are doing a great job. I commited your changes here: https://github.com/zackw/stegotorus/commit/a92f977259dd3aaabe9f5812f79bbe73… Please pull the branch f--file-stegize-swf-js-pdf and continue work there. Few comments: 1. Our main point is two get rid of redundant http_handle_client_SWF_receive, http_server_SWF_transmit (you undid deleting them). When you finish moving all modules the following "switch" in http_steg_t::http_client_receive (and in http_steg_t::transmit) will be discarded/disappear: switch(type) { case HTTP_CONTENT_SWF: rval = http_handle_client_SWF_receive(this, conn, dest, source); break; case HTTP_CONTENT_JAVASCRIPT: case HTTP_CONTENT_HTML: rval = http_handle_client_JS_receive(this, conn, dest, source); break; case HTTP_CONTENT_PDF: rval = http_handle_client_PDF_receive(this, conn, dest, source); break; default: log_debug(conn, "receiving a payload of type %i", type); rval = config->file_steg_mods[type]->http_client_receive(conn, dest, source); break; } and we will only need this line (the default case): log_debug(conn, "receiving a payload of type %i", type); rval = config->file_steg_mods[type]->http_client_receive(conn, dest, source); But for now, for any type that you move to FileStegMod structure, you just need to drop the case from this switch, because in new structure it will be taken care of in the default case, (so you don't get those src/steg/http.cc:697:67: error: 'http_handle_client_SWF_receive' was not declared in this scope errors you mentioned). 2. In http.cc, add a line to http_steg_config_t::init_file_steg_mods() to create the SWFSteg: void http_steg_config_t::init_file_steg_mods() { // we can't call this in constructor cause //it should be called after the payload server is initialized //initiating the steg modules //TODO: for now the first modules are set to void till their codes be //transformed into a FileStegMod child file_steg_mods[HTTP_CONTENT_JPEG] = new JPGSteg(payload_server, noise2signal); file_steg_mods[HTTP_CONTENT_PNG] = new PNGSteg(payload_server, noise2signal); file_steg_mods[HTTP_CONTENT_GIF] = new GIFSteg(payload_server, noise2signal); } 3. compare how PayloadScraper::PayloadScraper defines old modules and new modules, and modify for SWFSteg accordingly: _available_file_stegs[HTTP_CONTENT_SWF] = NULL; _available_stegs[2].type = HTTP_CONTENT_SWF; _available_stegs[2].extension = ".swf"; _available_stegs[2].capacity_function = PayloadServer::capacitySWF; vs. _available_file_stegs[HTTP_CONTENT_JPEG] = new JPGSteg(NULL); //We are only using the capacity function so we don't need a payload server _available_stegs[5].type = HTTP_CONTENT_JPEG; _available_stegs[5].extension = ".jpg"; _available_stegs[5].capacity_function = JPGSteg::static_capacity; //Temp measure, later we don't need to do such acrobat Also please look at my comment on the proposal. Bon courage, vmon Noah Rahman <selimthegrim(a)gmail.com> writes: > result of running git format-patch origin/tor-improve --stdout > swfsteg.patch > > On 4/6/14, Noah Rahman <selimthegrim(a)gmail.com> wrote: >> Success! Sending you the patch shortly... >> >> On 4/6/14, Noah Rahman <selimthegrim(a)gmail.com> wrote: >>> attaching new steg files for purely informational purposes, these are >>> the only ones I have modified - my guess is capacitySWF in payload >>> server should remain a stub? It seems like we would want to take the >>> capacity functions out of payload server... >>> >>> >>> >>> On 4/6/14, Noah Rahman <selimthegrim(a)gmail.com> wrote: >>>> Here's my current holdup, I don't think I changed these functions but >>>> will shelve what I have, restore, and do a diff. >>>> >>>> selimthegrim@Rimsky-Korsakoffee:~/stegotorus$ make >>>> make all-am >>>> make[1]: Entering directory `/home/selimthegrim/stegotorus' >>>> depbase=`echo src/steg/http.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 -g2 -O0 >>>> -std=gnu++11 -MT src/steg/http.o -MD -MP -MF $depbase.Tpo -c -o >>>> src/steg/http.o src/steg/http.cc &&\ >>>> mv -f $depbase.Tpo $depbase.Po >>>> src/steg/http.cc: In member function 'virtual int >>>> http_steg_t::transmit(evbuffer*)': >>>> src/steg/http.cc:562:75: error: 'http_server_SWF_transmit' was not >>>> declared in this scope >>>> rval = http_server_SWF_transmit(config->payload_server, source, >>>> conn); >>>> >>>> ^ >>>> src/steg/http.cc: In member function 'virtual int >>>> http_steg_t::http_client_receive(evbuffer*, evbuffer*)': >>>> src/steg/http.cc:697:67: error: 'http_handle_client_SWF_receive' was >>>> not declared in this scope >>>> rval = http_handle_client_SWF_receive(this, conn, dest, source); >>>> ^ >>>> make[1]: *** [src/steg/http.o] Error 1 >>>> make[1]: Leaving directory `/home/selimthegrim/stegotorus' >>>> make: *** [all] Error 2 >>>> >>>> >>>> On 4/6/14, Noah Rahman <selimthegrim(a)gmail.com> wrote: >>>>> Ok will use c_HTTP and restore the free block. I did read that text >>>>> file >>>>> and have made appropriate changes >>>>> On Apr 6, 2014 10:49 PM, <vmon(a)riseup.net> wrote: >>>>> >>>>>> Hey Noah, >>>>>> >>>>>> > size_t tmp_len = cover_len * 32; //assert here to prevent overflow >>>>>> This is probably prevented somewhere else, but it is always good to >>>>>> harden the code. >>>>>> >>>>>> > /*if (inf_len < 0 || >>>>>> > out_sz < inf_len - SWF_SAVE_HEADER_LEN - SWF_SAVE_FOOTER_LEN) >>>>>> > { >>>>>> > fprintf(stderr, "inf_len = %d\n", inf_len); >>>>>> > free(tmp_buf); >>>>>> > return -1; >>>>>> > }*/ >>>>>> Why did you get rid of this part? >>>>>> >>>>>> >//how to check max SWF size? c_HTTP_MSG_BUF_SIZE? >>>>>> Sure, there is a confusion between HTTP_MSG_BUF_SIZE and >>>>>> c_HTTP_MSG_BUF_SIZE but we should unite them and use one (the latter >>>>>> is >>>>>> better). >>>>>> >>>>>> > tmp_len= inf_len - SWF_SAVE_HEADER_LEN - SWF_SAVE_FOOTER_LEN; >>>>>> > //reassigned to existing variable >>>>>> > return (ssize_t)tmp_len; //added for new return type >>>>>> sure, you can do >>>>>> >>>>>> return (ssize_t)(inf_len - SWF_SAVE_HEADER_LEN - SWF_SAVE_FOOTER_LEN); >>>>>> >>>>>> But it isn't a big deal. >>>>>> >>>>>> Also please take a look at: >>>>>> >>>>>> >>>>>> doc/writing_new_file_steg_mod_for_http_steg.txt >>>>>> >>>>>> Best of luck, >>>>>> vmon >>>>>> >>>>>> Noah Rahman <selimthegrim(a)gmail.com> writes: >>>>>> >>>>>> > Have finished everything I think I need, trying now to compile a >>>>>> > patch >>>>>> > for SWF. Will start on JS once that is socked away. A few questions >>>>>> > though... (on tmp_len line, and commented out free block) >>>>>> > >>>>>> > ssize_t >>>>>> > SWFSteg::decode(const uint8_t *cover_payload, size_t cover_len, >>>>>> > uint8_t* >>>>>> data) >>>>>> > { >>>>>> > int inf_len; >>>>>> > size_t tmp_len = cover_len * 32; //assert here to prevent overflow >>>>>> > for large covers? >>>>>> > char* tmp_buf = (char *)xmalloc(tmp_len); >>>>>> > >>>>>> > for (;;) { >>>>>> > inf_len = decompress(cover_payload + 8, cover_len - 8, >>>>>> > (uint8_t *)tmp_buf, tmp_len); >>>>>> > if (inf_len != -2) >>>>>> > break; >>>>>> > tmp_len *= 2; >>>>>> > tmp_buf = (char *)xrealloc(tmp_buf, tmp_len); >>>>>> > } >>>>>> > >>>>>> > /*if (inf_len < 0 || >>>>>> > out_sz < inf_len - SWF_SAVE_HEADER_LEN - SWF_SAVE_FOOTER_LEN) >>>>>> > { >>>>>> > fprintf(stderr, "inf_len = %d\n", inf_len); >>>>>> > free(tmp_buf); >>>>>> > return -1; >>>>>> > }*/ //how to check max SWF size? c_HTTP_MSG_BUF_SIZE? >>>>>> > >>>>>> > memcpy(data, tmp_buf + SWF_SAVE_HEADER_LEN, >>>>>> > inf_len - SWF_SAVE_HEADER_LEN - SWF_SAVE_FOOTER_LEN); >>>>>> > tmp_len= inf_len - SWF_SAVE_HEADER_LEN - SWF_SAVE_FOOTER_LEN; >>>>>> > //reassigned to existing variable >>>>>> > return (ssize_t)tmp_len; //added for new return type >>>>>> > } >>>>>> > >>>>>> > On 4/5/14, vmon <vmon(a)riseup.net> wrote: >>>>>> >> >>>>>> >> >>>>>> >> Just make a patch of you changes and email me the patch: >>>>>> >> >>>>>> >> http://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git/ >>>>>> >> Envoyé depuis un mobile Samsung >>>>>> >> >>>>>> >> -------- Message d'origine -------- >>>>>> >> De : Noah Rahman <selimthegrim(a)gmail.com> >>>>>> >> Date :2014/04/05 19:11 (GMT-05:00) >>>>>> >> À : vmon(a)riseup.net >>>>>> >> Objet : Re: Stegotorus Challenge - Inheriting from FileStegMod >>>>>> >> >>>>>> >> Ok. I'll shoot for SWF and Js by turn and add that to a revised >>>>>> >> proposal for >>>>>> >> the challenge period. I have not heard back from Zack yet. I am in >>>>>> >> UTC+5 now >>>>>> >> so that leaves me all of my Sunday at least? >>>>>> >> >>>>>> >> On Apr 5, 2014 11:02 PM, <vmon(a)riseup.net> wrote: >>>>>> >> Hey Noah, >>>>>> >> >>>>>> >> Just keep in mind that I need to make a recommendation on your >>>>>> >> application by the end of the weekend. >>>>>> >> >>>>>> >> I also like very much if you can add "merging SRI branch of >>>>>> >> Stegotorus" >>>>>> >> to our Stegotorus as well, to the list of the deliverables of the >>>>>> >> proposal. >>>>>> >> >>>>>> >> Thanks, >>>>>> >> vmon >>>>>> >> >>>>>> >> Noah Rahman <selimthegrim(a)gmail.com> writes: >>>>>> >>> Yes, the capacities were a bit of a head scratcher. I'll try swf >>>>>> >>> first >>>>>> >>> and then js. My github ID is baronwolfenstein. >>>>>> >>> >>>>>> >>> Hey Noah, >>>>>> >>> >>>>>> >>> For committing: >>>>>> >>> I think Zack needs to give you write access. Please send your >>>>>> >>> github >>>>>> >>> id >>>>>> >>> to Zack (zackw(a)cmu.edu) and cc me. Once that is done, please >>>>>> >>> branch >>>>>> >>> out >>>>>> >>> of tor-improve and commit. If it takes Zack long to give you >>>>>> >>> permission, >>>>>> >>> you can just fork Zackw/stegotorus of course. Just please only >>>>>> >>> commit >>>>>> >>> compilable code (no syntax error etc), this way it is easier to >>>>>> >>> review >>>>>> >>> the commits. >>>>>> >>> >>>>>> >>> SWF would be easier than JS but if you like the JS it is cool with >>>>>> >>> me. For the swf, basically swf_wrap should go to encode, >>>>>> >>> swf_unwrap >>>>>> >>> to >>>>>> >>> decode and you need basically discard the http_server_SWF_transmit >>>>>> >>> and >>>>>> >>> http_handle_client_SWF_receive functions (these are >>>>>> >>> redundant). Just >>>>>> >>> be >>>>>> >>> careful that what is supposed to be send to each function, is it >>>>>> >>> the >>>>>> >>> payload without header? with header? etc. So just tweak the >>>>>> >>> swf_unwrap/swf_wrap to be compatible with what encode/decode. >>>>>> >>> >>>>>> >>> Capacity functions: >>>>>> >>> Then PayloadServer::capacitySWF should be implemented as >>>>>> >>> swfSteg::capacity. >>>>>> >>> However, You'll find 4 capacity functions and it is probably quite >>>>>> >>> confusing. >>>>>> >>> >>>>>> >>> capacity >>>>>> >>> headless_capacity >>>>>> >>> static_capacity >>>>>> >>> static_headless_capacity >>>>>> >>> >>>>>> >>> static vs virtual: >>>>>> >>> When all the modules are moved to the new model, we'll get rid of >>>>>> >>> static_capacity, static_headless_capacity but till then, we need >>>>>> >>> them >>>>>> >>> to >>>>>> >>> keep this old/new hybrid stegs model. Hence: >>>>>> >>> >>>>>> >>> capacity just calls static_capacity >>>>>> >>> headless_capacity just calls static_headless_capacity >>>>>> >>> >>>>>> >>> headless vs headfull: >>>>>> >>> headless_capcity: computes the capacity when the payload is given >>>>>> >>> without >>>>>> >>> http header (pure file). >>>>>> >>> >>>>>> >>> capacity: compute the capacity when the payload is given as an >>>>>> >>> HTTP >>>>>> >>> response (So it starts with >>>>>> >>> >>>>>> >>> HTTP/1.1 200 OK Server: Apache >>>>>> >>> Accept-Ranges: bytes >>>>>> >>> Content-Type: text/html; charset=utf-8 >>>>>> >>> Content-Length: 920 >>>>>> >>> Connection: keep-alive >>>>>> >>> >>>>>> >>> and then the file starts, so you just need basically to skip the >>>>>> >>> header >>>>>> >>> and call headless_capacity (we probably should implement the >>>>>> >>> capacity >>>>>> >>> in >>>>>> >>> the parent and only make headless_capacity pure virtual). >>>>>> >>> >>>>>> >>> If you take look at: >>>>>> >>> >>>>>> >>> jpgSteg::capacity >>>>>> >>> jpgSteg::headless_capacity >>>>>> >>> jpgSteg::static_capacity >>>>>> >>> jpgSteg::static_headless_capacity >>>>>> >>> >>>>>> >>> all I what say will sound less gibberish to you. >>>>>> >>> >>>>>> >>> Good luck et bon courage, >>>>>> >>> vmon >>>>>> >>> >>>>>> >>> Noah Rahman <selimthegrim(a)gmail.com> writes: >>>>>> >>> >>>>>> >>>> Laying over in Tokyo enroute to bkk, had a look at all the >>>>>> >>>> modules >>>>>> >>> and >>>>>> >>>> will start on the JS one on the plane. I have 24 hours in bkk so >>>>>> >>>> should be able to convert the Js and at least one of the other >>>>>> >>>> ones >>>>>> >>> if >>>>>> >>>> not both to inherit from the FileStegMod by the time I leave >>>>>> >>>> there. >>>>>> >>>> Should I submit the pr to your Tor-improve branch or zackw's? >>>>>> >>>> >>>>>> >> >>>>>> >>>>> >>>> >>> >>

1 0

Re: [tor-dev] Stegotorus Challenge - Inheriting from FileStegMod
by vmon＠riseup.net 06 Apr '14

06 Apr '14

Hey Noah, > size_t tmp_len = cover_len * 32; //assert here to prevent overflow This is probably prevented somewhere else, but it is always good to harden the code. > /*if (inf_len < 0 || > out_sz < inf_len - SWF_SAVE_HEADER_LEN - SWF_SAVE_FOOTER_LEN) { > fprintf(stderr, "inf_len = %d\n", inf_len); > free(tmp_buf); > return -1; > }*/ Why did you get rid of this part? >//how to check max SWF size? c_HTTP_MSG_BUF_SIZE? Sure, there is a confusion between HTTP_MSG_BUF_SIZE and c_HTTP_MSG_BUF_SIZE but we should unite them and use one (the latter is better). > tmp_len= inf_len - SWF_SAVE_HEADER_LEN - SWF_SAVE_FOOTER_LEN; > //reassigned to existing variable > return (ssize_t)tmp_len; //added for new return type sure, you can do return (ssize_t)(inf_len - SWF_SAVE_HEADER_LEN - SWF_SAVE_FOOTER_LEN); But it isn't a big deal. Also please take a look at: doc/writing_new_file_steg_mod_for_http_steg.txt Best of luck, vmon Noah Rahman <selimthegrim(a)gmail.com> writes: > Have finished everything I think I need, trying now to compile a patch > for SWF. Will start on JS once that is socked away. A few questions > though... (on tmp_len line, and commented out free block) > > ssize_t > SWFSteg::decode(const uint8_t *cover_payload, size_t cover_len, uint8_t* data) > { > int inf_len; > size_t tmp_len = cover_len * 32; //assert here to prevent overflow > for large covers? > char* tmp_buf = (char *)xmalloc(tmp_len); > > for (;;) { > inf_len = decompress(cover_payload + 8, cover_len - 8, > (uint8_t *)tmp_buf, tmp_len); > if (inf_len != -2) > break; > tmp_len *= 2; > tmp_buf = (char *)xrealloc(tmp_buf, tmp_len); > } > > /*if (inf_len < 0 || > out_sz < inf_len - SWF_SAVE_HEADER_LEN - SWF_SAVE_FOOTER_LEN) { > fprintf(stderr, "inf_len = %d\n", inf_len); > free(tmp_buf); > return -1; > }*/ //how to check max SWF size? c_HTTP_MSG_BUF_SIZE? > > memcpy(data, tmp_buf + SWF_SAVE_HEADER_LEN, > inf_len - SWF_SAVE_HEADER_LEN - SWF_SAVE_FOOTER_LEN); > tmp_len= inf_len - SWF_SAVE_HEADER_LEN - SWF_SAVE_FOOTER_LEN; > //reassigned to existing variable > return (ssize_t)tmp_len; //added for new return type > } > > On 4/5/14, vmon <vmon(a)riseup.net> wrote: >> >> >> Just make a patch of you changes and email me the patch: >> >> http://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git/ >> Envoyé depuis un mobile Samsung >> >> -------- Message d'origine -------- >> De : Noah Rahman <selimthegrim(a)gmail.com> >> Date :2014/04/05 19:11 (GMT-05:00) >> À : vmon(a)riseup.net >> Objet : Re: Stegotorus Challenge - Inheriting from FileStegMod >> >> Ok. I'll shoot for SWF and Js by turn and add that to a revised >> proposal for >> the challenge period. I have not heard back from Zack yet. I am in >> UTC+5 now >> so that leaves me all of my Sunday at least? >> >> On Apr 5, 2014 11:02 PM, <vmon(a)riseup.net> wrote: >> Hey Noah, >> >> Just keep in mind that I need to make a recommendation on your >> application by the end of the weekend. >> >> I also like very much if you can add "merging SRI branch of >> Stegotorus" >> to our Stegotorus as well, to the list of the deliverables of the >> proposal. >> >> Thanks, >> vmon >> >> Noah Rahman <selimthegrim(a)gmail.com> writes: >>> Yes, the capacities were a bit of a head scratcher. I'll try swf >>> first >>> and then js. My github ID is baronwolfenstein. >>> >>> Hey Noah, >>> >>> For committing: >>> I think Zack needs to give you write access. Please send your >>> github >>> id >>> to Zack (zackw(a)cmu.edu) and cc me. Once that is done, please branch >>> out >>> of tor-improve and commit. If it takes Zack long to give you >>> permission, >>> you can just fork Zackw/stegotorus of course. Just please only >>> commit >>> compilable code (no syntax error etc), this way it is easier to >>> review >>> the commits. >>> >>> SWF would be easier than JS but if you like the JS it is cool with >>> me. For the swf, basically swf_wrap should go to encode, swf_unwrap >>> to >>> decode and you need basically discard the http_server_SWF_transmit >>> and >>> http_handle_client_SWF_receive functions (these are >>> redundant). Just >>> be >>> careful that what is supposed to be send to each function, is it >>> the >>> payload without header? with header? etc. So just tweak the >>> swf_unwrap/swf_wrap to be compatible with what encode/decode. >>> >>> Capacity functions: >>> Then PayloadServer::capacitySWF should be implemented as >>> swfSteg::capacity. >>> However, You'll find 4 capacity functions and it is probably quite >>> confusing. >>> >>> capacity >>> headless_capacity >>> static_capacity >>> static_headless_capacity >>> >>> static vs virtual: >>> When all the modules are moved to the new model, we'll get rid of >>> static_capacity, static_headless_capacity but till then, we need >>> them >>> to >>> keep this old/new hybrid stegs model. Hence: >>> >>> capacity just calls static_capacity >>> headless_capacity just calls static_headless_capacity >>> >>> headless vs headfull: >>> headless_capcity: computes the capacity when the payload is given >>> without >>> http header (pure file). >>> >>> capacity: compute the capacity when the payload is given as an HTTP >>> response (So it starts with >>> >>> HTTP/1.1 200 OK Server: Apache >>> Accept-Ranges: bytes >>> Content-Type: text/html; charset=utf-8 >>> Content-Length: 920 >>> Connection: keep-alive >>> >>> and then the file starts, so you just need basically to skip the >>> header >>> and call headless_capacity (we probably should implement the >>> capacity >>> in >>> the parent and only make headless_capacity pure virtual). >>> >>> If you take look at: >>> >>> jpgSteg::capacity >>> jpgSteg::headless_capacity >>> jpgSteg::static_capacity >>> jpgSteg::static_headless_capacity >>> >>> all I what say will sound less gibberish to you. >>> >>> Good luck et bon courage, >>> vmon >>> >>> Noah Rahman <selimthegrim(a)gmail.com> writes: >>> >>>> Laying over in Tokyo enroute to bkk, had a look at all the modules >>> and >>>> will start on the JS one on the plane. I have 24 hours in bkk so >>>> should be able to convert the Js and at least one of the other >>>> ones >>> if >>>> not both to inherit from the FileStegMod by the time I leave >>>> there. >>>> Should I submit the pr to your Tor-improve branch or zackw's? >>>> >>

1 0

GSoC Proposal: Relay Web Status Dashboard
by Bang Hui Lim 05 Apr '14

05 Apr '14

Hi Damian, Thank you for your feedback and suggestions!! I have revised my proposal and uploaded it to melange. Cheers Bang

3 7

[RELEASE] Torsocks 2.0.0-rc7
by David Goulet 05 Apr '14

05 Apr '14

Hi everyone! This is the release candidate 7 for torsocks 2.x. Nothing major, fixes and some code refactoring went in. From this point on, the upstream torsocks git[1] is now updated with that new code in the master branch but no stable release yet. With that, my github repository will become a mirror for a while but I will close the issue tracker after I move all the issues to the tpo trac. I will update the list next week on the current status of torsocks and what's next about this project. Here is the change log for this version. 2014-04-04 torsocks 2.0.0-rc7 * Fix: fix NULL dereference on error * Fix: memory leak in connect error path * Delete old source directory * Fix: nullify constant that might be undefined * Refactor the connect() code flow for clarity * Tests: add connect() test * Tests: add socket() test * Fix: socketpair() denied for INET[6] socket * Fix: socket() type check SOCK_STREAM * Fix: add autogen.sh to installation procedures * Fix: change TSOCKS_LOOPBACK bitness * Fix: support kfreebsd for mmap() Again, as usual, and forever! *please* code review, test and most importantly report any issues. Contribution ftw! :) Thanks to everyone! Git: https://github.com/dgoulet/torsocks.git (mirror: https://gitweb.torproject.org/user/dgoulet/torsocks.git) Github tarball: https://github.com/dgoulet/torsocks/archive/v2.0.0-rc7.tar.gz TPO Tarball: https://people.torproject.org/~dgoulet/torsocks/torsocks-2.0.0-rc7.tar.bz2 (sig: https://people.torproject.org/~dgoulet/torsocks/torsocks-2.0.0-rc7.tar.bz2.…) Cheers! David [1] https://gitweb.torproject.org/torsocks.git

2 1

jtorctl
by Michael Rogers 04 Apr '14

04 Apr '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I have a patch to improve thread safety in jtorctl. How should I submit it? Cheers, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJTPT1vAAoJEBEET9GfxSfM0CMH+wais6E2jteMA0EnrAsV9+K1 jx08ypBNtE7qTYehe3m4s6vFwEGmw6lu2qYqi8XwPlD6PY/x1OtnDWjrTUsMfyWe OMZF2kqtMcpk47Y+SAL2c8P/BGYk88Wb2UMTZEGo3AjBZS2wQyHD+FMaSoDP02R9 MvCfwON+sn4a+AJxrnX/NsrI5FivJWR8obWX2sYpfCQaNIub/G/SGh9DtMbJFEjD tLc+MHyrrmmEmM1LN8kQp6QdBP7xIn/Cv+St3vzG920UuvQD5ZmHCYqiD3ddp74f vqfuKZs8GvnDFnND9mfy16l9lUu8dME1GWnoAO0l4jRmhBKwUCZMnjaLZvBVZiE= =6inv -----END PGP SIGNATURE-----

4 7

Re: [tor-dev] Stegotorus Challenge - Inheriting from FileStegMod
by vmon＠riseup.net 04 Apr '14

04 Apr '14

Hey Noah, For committing: I think Zack needs to give you write access. Please send your github id to Zack (zackw(a)cmu.edu) and cc me. Once that is done, please branch out of tor-improve and commit. If it takes Zack long to give you permission, you can just fork Zackw/stegotorus of course. Just please only commit compilable code (no syntax error etc), this way it is easier to review the commits. SWF would be easier than JS but if you like the JS it is cool with me. For the swf, basically swf_wrap should go to encode, swf_unwrap to decode and you need basically discard the http_server_SWF_transmit and http_handle_client_SWF_receive functions (these are redundant). Just be careful that what is supposed to be send to each function, is it the payload without header? with header? etc. So just tweak the swf_unwrap/swf_wrap to be compatible with what encode/decode. Capacity functions: Then PayloadServer::capacitySWF should be implemented as swfSteg::capacity. However, You'll find 4 capacity functions and it is probably quite confusing. capacity headless_capacity static_capacity static_headless_capacity static vs virtual: When all the modules are moved to the new model, we'll get rid of static_capacity, static_headless_capacity but till then, we need them to keep this old/new hybrid stegs model. Hence: capacity just calls static_capacity headless_capacity just calls static_headless_capacity headless vs headfull: headless_capcity: computes the capacity when the payload is given without http header (pure file). capacity: compute the capacity when the payload is given as an HTTP response (So it starts with HTTP/1.1 200 OK Server: Apache Accept-Ranges: bytes Content-Type: text/html; charset=utf-8 Content-Length: 920 Connection: keep-alive and then the file starts, so you just need basically to skip the header and call headless_capacity (we probably should implement the capacity in the parent and only make headless_capacity pure virtual). If you take look at: jpgSteg::capacity jpgSteg::headless_capacity jpgSteg::static_capacity jpgSteg::static_headless_capacity all I what say will sound less gibberish to you. Good luck et bon courage, vmon Noah Rahman <selimthegrim(a)gmail.com> writes: > Laying over in Tokyo enroute to bkk, had a look at all the modules and > will start on the JS one on the plane. I have 24 hours in bkk so > should be able to convert the Js and at least one of the other ones if > not both to inherit from the FileStegMod by the time I leave there. > Should I submit the pr to your Tor-improve branch or zackw's? >

1 0

Re: [tor-dev] Moving ownership to TheTorProject
by Zack Weinberg 04 Apr '14

04 Apr '14

On 02/20/2014 10:48 AM, vmonmoonshine(a)gmail.com wrote: > Hey Zack, > > I want to put up Stegotorus up for GSoC this summer. I was wondering if > you mind transfering the ownership of your Stegotorus repo: > > https://github.com/zackw/stegotorus > > To "TheTorProject" on github: > > https://github.com/TheTorProject > > ? (https://github.com/zackw/stegotorus/settings then Transfer) > > If you don't feel comfortable, we can fork it as well. [ Background for tor-dev: I am no longer involved in Stegotorus development. vmon and at least one other person are continuing to work on it; this is currently happening in non-default branches of the copy on my github account. There is also a copy of the repo on gitweb.torproject.org but it has not been updated in quite some time. ] I discussed this with Roger on IRC yesterday and we came to the conclusion that instead of transferring my Stegotorus repo to the "TheTorProject" organizational account, gitweb.torproject.org/stegotorus.git should be promoted to the master copy. I think right now I am the only person with write access to that copy, and I am not sure what the right procedure is for granting you access. I'm also not good enough at Git to know how to copy all branches of remote A into remote B (short of tedious manual actions and/or shell loops). I think this would also entail using Tor's Trac for issues instead of Github's issue tracker. zw

5 5

Prototype of a next-generation Tor control interface
by ra 04 Apr '14

04 Apr '14

Hi, all! Originally, I wrote the proposal for this year's GSoC, but nobody seems willing to mentor it and the idea most probably needs more time to shape. Hence, I post it on this list to get some feedback and let the idea evolve. (: Best, Robert Problem statement Tor's control protocol[0] facilitated the communication from other programs with a locally running Tor process, regardless of their programming language. It is used by various projects like GUI controllers, such as Vidalia or arm, research projects, or services for monitoring the Tor network, such as bandwidth scanners. The Tor control protocol is a message-based protocol which requires lots of message/string parsing when using it. Hence, to ease the use of that interface, libraries such as JTorCtl, TorCtl, Txtorcon, and Stem were developed. Today, some of those libraries can be considered outdated, such as JTorCtl and TorCtl - even though TorCtl is still in use. Stem and Txtorcon are state-of-the-art and heavily being used, provide thread safety, caching and a better interface, rendering string parsing unnecessary. However, both are Python libraries, restricting the use of the Tor control protocol to Python scripts only. While Python is a fine and very popular scripting language, actual restriction to use a specific programming language, prevents wider use of the Tor control interface. Proposal Therefore, I would like to propose a prototype of a next-generation Tor control interface, aiming to combine the strengths of both the present control protocol and the state-of-the-art libraries. It should provide (network) connectivity from other programs to a locally running Tor process, regardless of the programming language, while preserving thread safety, caching and a better interface. Before implementing in Tor itself, coding a prototype is substantially less work. The prototype should consist of a daemon running on the same machine as the Tor instance. The daemon implements a backend interface to the Tor instance through the Tor control protocol (via Stem) and a frontend interface providing JSON encoded data over HTTP (REST). Therefore, semi-structured data (JSON) can be accessed by any (HTTP-capable) programming/scripting language. HTTP compression and/or encryption can be implemented, too. Not having looked into Python REST frameworks yet in detail, Flask looks promising for this task. Until the new interface is implemented in Tor itself, it will require continual upkeep and maintenance. Therefore, as a long term goal, the new interface should be implemented in Tor itself, if the prototype proofs to be successful. [0] https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=control- spec.txt

1 1

Feedback on recent Globe improvements
by Karsten Loesing 03 Apr '14

03 Apr '14

Hi Christian, moving our private discussion to the public mailing list. You were asking about making graphs from Onionoo's new clients documents. Here's an example: "1_week":{"first":"2014-03-23 12:00:00","last":"2014-03-30 12:00:00","interval":86400,"factor":0.002802803,"count":8,"values":[251,933,471,955,999,999,735,713],"countries":{"cn":0.1882,"dz":0.0728,"es":0.0146,"fr":0.1006,"gb":0.0174,"hk":0.0233,"ir":0.1119,"jp":0.1882,"kz":0.0117,"my":0.1532,"us":0.1123},"versions":{"v4":1.0000}}, For this bridge, you'd draw the first data point at x = 2014-03-23 12:00:00 UTC with y = 251 * 0.002802803 = 0,703503553 concurrent users. You were also asking about feedback on new uptime graphs: http://rndm.de/globe/canary/index-11349.html Looks pretty good! The uptime graphs for the relays I checked were not as exciting as the bandwidth graphs, but it's actually good if uptime is always at 100%. And finally, you asked about showing numeric averages next to graphs, like on: https://status.github.com/graphs/past_week I like the idea. I think we shouldn't split up graphs to have only 1 line per graph, because that makes it hard to compare incoming and outgoing traffic or the various weights to each other. But it could help to have numeric averages in the same color as graph lines next to the graphs. Thanks! All the best, Karsten

4 15