- tor-dev - lists.torproject.org

Problems. Flash plugin works by default! I can see youtube video with Tor Browser Bundle
by User of Tor 18 Jul '13

18 Jul '13

Hi, I've installed Tor Browser Bundle for Windows (tor-browser-2.3.25-2_ru) I didn't change any settings. When I visit any html-page on which there is a flash video i can see it, flash works! Why? It must not work! In settings(plugins) "Flash plugin" is disabled and it is inactive. In Tor Button settings Plugins are turned off. What happens? Is it a BUG? Regards.

5 4

TBB without Vidalia
by Zack Weinberg 15 Jul '13

15 Jul '13

How technically difficult would it be to remove Vidalia from an already-packaged TBB? (Ideally something that could be put into a shell script.) Basically what I want is a more-current-than-ESR10 browser that uses a system-installed & -configured Tor instance. I wouldn't miss the Torbutton UI, either (it should just use Tor all the time).

3 2

Status Report - Steganography browser addon a GSOC 2013 project
by Hareesan 14 Jul '13

14 Jul '13

Hi all, In last two weeks, I worked on detecting video and sound contents from web pages and get them as byte format to be used with algorithms later. To test it, use the test button in context menu over video element and it will alert the byte code of the content selected. ( Might take some time due to the video element file size). My next plan for coming weeks is to finish content uploading to extension from local memory. And more than context menus, all the content handling parts like toolbar button, menu buttons, upload options will be done by the end of coming two weeks. -- Hareesan

1 0

[GSOC] Status report - Tor capabilities
by Cristian-Matei Toader 13 Jul '13

13 Jul '13

Hello tor-dev, Here goes the status report for the past 2 weeks - I have been preparing the code for the first step of the project to be merged in the Tor master branch, which represented a number of changes required by nickm; the full process can be seen here [1], the branch was squashed and should be merged one of these days. - Step 2: - current progress - has changed a bit, and now requires to create a sandbox as 'tight' as possible around the Tor syscalls; - this is achieved my filtering not only syscalls but also syscall parameters, current efforts on my part can be found here [2] in branch "gsoc-cap-stage2"; - the current problem with this stage is filtering string parameters for syscalls which can be done using immutable strings using protected memory regions; - unfortunately some syscalls are out of reach being part of libraries and therefore their parameters cannot be controlled (the pointer used in the seccomp filter cannot be reference in the syscall) which will need to be solved (any suggestions are appreciated). - I have implemented ioerror's suggestion about policy files but is not pushed to git mainly because after talking to nickm we concluded that the implementation effort is not justified especially now when filter configurations are constantly changing which would require also changing how policy files are parsed, having mostly the same end result; furthermore some of the string filter parameters may be generated on runtime, which may be inconsistent with the solution, but I will keep this in mind towards the finishing stage of the development process, especially since it offers an elegant way of configuring and testing different filters. As a small side-note I will mostly be traveling the majority of next week, so I may not be as reachable as before. Looking forward to some feedback, if you happen to have any! References: [1] https://trac.torproject.org/projects/tor/ticket/9168 [2] https://github.com/cristiantoader/tor-gsoc-capabilities

2 1

Status report - Stream-RTT
by ra 12 Jul '13

12 Jul '13

Hi all! I started a little late on this years GSoC project[0] which is about reducing the RTT of preemptively built circuits. Since begin of July I have been working on scripts for Tor path generation and Stream-RTT probing. For the path generation script "path_finder.py" I decided not to reimplement Tor's path generation logic but to ask a Tor client to choose a path without actually building it. I have written two small patches for Tor which implement the following new control commands: -) "DUMPGUARDS" removes all entry guards. (This might also be handy to work around the path selection strangeness when guards are disabled[1]). -) "FINDPATH" tells the Tor client to generate a path but do not build a circuit from it. To verify the correctness of the approach I am currently generating a few million paths and will look into the distribution of nodes. The Stream-RTT-probing script "rttprober.py" is also in a working state. Though it needs some more testing, it is already able to spawn multiple threads where each builds a circuit and runs a number of probes on that circuit, measuring the RTTs of the stream and the circuit build time. I will hopefully be able to get useful Stream-RTT-data soon to tackle the first interesting questions. All scripts and patches are available online[2]. Best, Robert [0] https://www.google-melange.com/gsoc/project/google/gsoc2013/ra_/19001 [1] https://trac.torproject.org/projects/tor/ticket/9188 [2] https://bitbucket.org/ra_/tor-rtt

1 0

GSoC Status Report - EvilGenius
by Johannes Fürmann 12 Jul '13

12 Jul '13

Hi *, As the weekend approaches, it is time for my second status report on the censorship simulation project "EvilGenius". In the last two weeks I learned a lot about virtualization and the OONI project EvilGenius is being planned and written for. After fixing smoothing out some rough edges in the Vagrantfiles, I created the first 'censorship provider', i.e. a blueprint for a box that actually does censorship, in this case by untruthfully answer DNS Queries to example.com with its own IP address. As soon as this was done, Arturo and I talked about wrapping a nice CLI around it and came up with a plan, which i will explain briefly. basically, there are two core components to EvilGenius: - Censorship providers and - Measuremet Instruments. Both of those components are boxes that run in different configurations described by a .yml file. Our first goal is to generate vagrantfiles from those files and boot them up. During the weekend, I'm trying to tackle the Censorship provider class and see how it goes from there. You all have nice and relaxing weekends Johannes

1 0

'time_t' warnings on MSVC
by Gisle Vanem 12 Jul '13

12 Jul '13

I've been building tor myself for 2 years now. In order to reduce the number of warnings, I've added '-D_USE_32BIT_TIME_T' to my CFLAG. This has worked fine until I updated and built OpenSSL 4 days ago. It's 'ASN1_time_adj()' function and related 'OPENSSL_gmtime()' just doesn't work when given a 32-bit 'time_t'. (Not sure how/if they worked with a 32-bit time before). Maybe this could be detected by common/tortls.c before calling into OpenSSL? Well, tor builds and works okay w/o this define. But I wish the noise-level from "cl.exe -W3" could be reduced. They're probably harmless now. But what about after the year 2036? The warnings related to 'time_'t are: channeltls.c(1403) : warning C4244: 'function' : conversion from 'time_t' to 'long', possible loss of data channeltls.c(1404) : warning C4244: '=' : conversion from 'time_t' to 'long', possible loss of data directory.c(1711) : warning C4244: '=' : conversion from 'time_t' to 'long', possible loss of data directory.c(2924) : warning C4244: '=' : conversion from 'time_t' to 'long', possible loss of data dirserv.c(1795) : warning C4244: 'return' : conversion from 'const time_t' to 'long', possible loss of data dirserv.c(3092) : warning C4244: '=' : conversion from 'time_t' to 'long', possible loss of data geoip.c(1240) : warning C4244: 'initializing' : conversion from 'time_t' to 'long', possible loss of data hibernate.c(356) : warning C4244: 'return' : conversion from 'time_t' to 'long', possible loss of data networkstatus.c(754) : warning C4244: 'initializing' : conversion from 'time_t' to 'long', possible loss of data networkstatus.c(1299) : warning C4244: 'initializing' : conversion from 'time_t' to 'long', possible loss of data networkstatus.c(1329) : warning C4244: '=' : conversion from 'time_t' to 'long', possible loss of data networkstatus.c(1337) : warning C4244: '=' : conversion from 'time_t' to 'long', possible loss of data networkstatus.c(1846) : warning C4244: 'initializing' : conversion from 'time_t' to 'long', possible loss of data rephist.c(189) : warning C4244: '+=' : conversion from 'time_t' to 'unsigned long', possible loss of data rephist.c(192) : warning C4244: '+=' : conversion from 'time_t' to 'unsigned long', possible loss of data rephist.c(213) : warning C4244: '+=' : conversion from 'time_t' to 'unsigned long', possible loss of data rephist.c(227) : warning C4244: '+=' : conversion from 'time_t' to 'unsigned long', possible loss of data rephist.c(333) : warning C4244: '=' : conversion from 'time_t' to 'long', possible loss of data rephist.c(387) : warning C4244: 'initializing' : conversion from 'time_t' to 'long', possible loss of data rephist.c(497) : warning C4244: '+=' : conversion from 'time_t' to 'long', possible loss of data rephist.c(515) : warning C4244: '+=' : conversion from 'time_t' to 'long', possible loss of data rephist.c(517) : warning C4244: '+=' : conversion from 'time_t' to 'long', possible loss of data rephist.c(531) : warning C4244: 'initializing' : conversion from 'time_t' to 'long', possible loss of data rephist.c(535) : warning C4244: '+=' : conversion from 'time_t' to 'long', possible loss of data rephist.c(559) : warning C4244: 'return' : conversion from 'time_t' to 'long', possible loss of data rephist.c(1053) : warning C4244: 'initializing' : conversion from 'time_t' to 'long', possible loss of data routerlist.c(5038) : warning C4244: 'function' : conversion from 'time_t' to 'long', possible loss of data entrynodes.c(160) : warning C4244: '=' : conversion from 'time_t' to 'long', possible loss of data --gv

1 0

Stray ';'
by Gisle Vanem 11 Jul '13

11 Jul '13

There's an extra ';' in src/or/config.h that MSVC doesn't like so much. Patch: --- Git-latest\src\or\config.h 2013-05-28 07:32:46 +0000 +++ src\or\config.h 2013-05-28 07:39:42 +0000 @@ -109,7 +109,7 @@ char *transport_name; /* The name of the pluggable transport that should be used to connect to the bridge. */ char digest[DIGEST_LEN]; /* The bridge's identity key digest. */ - smartlist_t *socks_args;; /* SOCKS arguments for the pluggable + smartlist_t *socks_args; /* SOCKS arguments for the pluggable transport proxy. */ } bridge_line_t; ---gv

2 1

On status of Stegotorus on github vs SRI
by vmonmoonshine＠gmail.com 10 Jul '13

10 Jul '13

Hi Jeoren, Thanks for your comments or tor-dev IRC channel. I thought I may as well take my time and reply to them here so I can also include Zack, Vinod and others into the discussion. >I think the large chunks of commits without specific >goals/descriptions what the commit fixes will be timecostly to > integrate, I started working on Stegotorus as a GSoC student last summer and I have been more or less continuously working on it since then. I always kept the tor-dev list informed on my progress. So a quick search on [Stegotorus] should gives anybody a good idea on stuff I was working on. But I can summarize all my works in four categories: - Debug. - Writing more unit and behavior tests, including tester-proxy, webpage-tester and bad-dropper-proxy. - Integrating Stegotorus with a web server (e.g Apache Httpd) so the covers can be served by the web server. - Debugging the ack/transmit protocol and the packet transmission - reliability in general. In general, along the way, I tried to reconstruct the code into being more C++ and more object oriented (I'm continuously doing so). Obviously Stegotorus was designed to be as modular as possible. That is the main motivation behind "pluggable transport": the DPI got more intelligent? Plug the compromised module out, plug something else in with minimum effort. All of Stegotorus different modules are begging for OOP and inheritance. However, forcing the code into C had just made the steg folder unmanageable and un-expandable. The different steg modules (pdf, swf and js) have something like 70%-90% code in common but instead of being inherited from a common parent the code has been copied multiple times. It seems like an artificially generated example by OOP evangelists to convert people into OOP by showing how terrifying functional programming can be. >especially as the hidden upstream has diverged quite a >bit in some places (which one can nicely attribute to the wrong of >that 'model', but unfortunately not an easy way around that); Until recently that Roger sent an email to Vinod, I did not know that the upstream in SRI is making any progress (I'm not sure if even Roger (or anybody else on the Tor side for that matter) was fully aware of the amount of progress on the other side) . Last winter, Zack told me that I'll be the maintainer of the code (at least from Zack's prospective) in the sense I'd decide what patch to keep and what to discard. > nevertheless, I think the best plan to get those in there would be to > see when that code is out, and have a list of important > ... fixes/commits available and then at one point go over everything > and try to get them merged into that code base, will be big > job though to get that done, and would 'require' > that upstream takes them, which mostly depends on > available time I would say.... As Roger and other have mentioned multiple time, it is hard to fully reconcile the SRI model of development with the open source model. In that sense, we'll probably always have an open source version of Stegotorus and a SRI version of it (At least till SRI development is active). Nevertheless, my goal is to reconstruct the best piece of software possible out of all available code and I'll do my best to integrate all improvement into the open source version. > I think for that matter, trying to really have upstream have a > github version and accept patches would be a good way to avoid such > scenarios; hence also why we'll be pushing the acs code there into > the safdef repo, just the easiest way to make that happen if one > wants it; but first to finish that code and stop restructuring it > and adding new features etc.... then it will be pushed there, > otherwise not much use for people looking at it anyway. I do agree that the best thing is to wait for updated code to be published before going ahead to avoid re-invention of the wheel and waste of time. But I have a contract to add some features to Stegotorus with deadlines and I think Roger has asked Vinod for the code release on March 25 and it is not clear how longer it is going to take. Nonetheless, I'm going to ask Vinod if he can have a quick look at those features and decide which one are more likely to be affected by the recent development. For example when you told me about the ACK, I moved to the other parts. Thanks for your advice and updating me about the other side. Please keep me updated of any detail that you think will help with Stegotorus development. Cheers, Vmon

1 0

atlas.torproject.org question
by me＠rndm.de 08 Jul '13

08 Jul '13

Hi there, I rebuild atlas.torproject.org using Ember.js instead of Backbone. It looks like this right now: search page: http://i.imgur.com/GEM86mk.png details page: http://i.imgur.com/1UwpwlA.png I'd like to share the code and thought about putting it on github but I don't know if it's ok for you with all the Tor assets (tor logo). Would love to hear what you think about it. thank you

7 25