Re: [tor-dev] PRELIMINARY: [PATCH 3/3] Replace 'TorDNSEL.System.Timeout' with 'System.Timeout'.
Nikita Karetnikov: Using `git blame` or `git log -S` or `git log -G` will actually work better than a file by file summary. If you throw in the `-M` option, it'll work accross renames, for examples. OK. But that information will be lost if we decide to change a VCS for some reason. Well, we could avoid switching to a VCS that would loose such valuable information! :) Why not put what you wrote in your description email in there? This was a good explaination of why the change was actually needed! :) GHC was recently changed to not allow you to use newtypes in FFI imports unless the constructor of the newtype is in scope. [1] [1] http://ghc.haskell.org/trac/ghc/ticket/5610 OK. So let me summarize: 1. I shouldn't explicitly name changed functions or modules. 2. I can add a small description (like the above) if it's appropriate. Did I forget anything? Feel free to develop your own style and taste. Some readings: http://who-t.blogspot.de/2009/12/on-commit-messages.html http://robots.thoughtbot.com/post/48933156625/5-useful-tips-for-a-better-commit-message http://ablogaboutcode.com/2011/03/23/proper-git-commit-messages-and-an-elegant-git-history/ This is quite thorough: https://wiki.openstack.org/wiki/GitCommitMessages -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [GSOC2013] EvilGenius status report
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi *, In addition to attending the tor meeting in Garching (which was really awsesome, by the way) I really got some work on EvilGenius in the past two weeks. Since Arturo and I outlined the rough structure of the EvilGenius command line interface, I was gradually filling in the pieces needed for talking to the vagrant. Starting this tuesday, we built a set of unittests to test the functionality that is already in place. Since yesterday evening, after a bit of hacking, I already implemented the first and most difficult part of network plumbing and got the binary to create valid Vagrantfiles that are actually booting up the network they are supposed to. So, as Arturo said, the Genius is there, all we have to do now is make it more evil.. We also might have to work on the plumbing a bit and fit some loose pieces together, which is what I shall be doing next week. By the way, it was really nice to meet all of you in Garching. Hope to see you all soon! Have a safe trip home and enjoy your weekend, everyone! Johannes -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR8m5qAAoJEAgie5o3Q/JpBzcQALiUslixPD5kIL0r+eNvXHU1 BDDDz9JUZhNc/4ZLa1AFXtY2GrJmB4wP6IOGjuj5rAPx0YcHUszVzjaTti5hWflr rlsXbbOgj4VWDsTAcO7AUbhrEVFaH/SlKgQesZKQuLTduDEhzXBSKga6VlCV37AF R//l8iXRBapwq5DzHSW4eYvNXorKF/nKN/ax7XYjZ5+X/P9sXZz1yHqk5/t187Lt mGbnrfcvEC5xkFpLgz/ReWZ7wABUMJRMrgTapI14rau94rGnaWSsVVjbNKRyYlr3 lhvgsEc6bmIRMhaBDn+Ujgt5o75Th3vJQ2T81wXIkWgrTEsZRZTAJGtyjO0nohtI G2UQmy+/U2Xam2tDyMh7xaGhNr4UN1NJpQ17TyCNPd4DzyO5XG6QjHhjb2s4U9ID YhflAo7yEj4P6NsRR+nIh5djveAgUF55sWNpp+fq1SK8VQ2UXMw6Pm76W7uwGIsw uf7icgTbSC7msSBXJf5HgyP7h3ZvlTrblP90/ciVuLS3YPUmwKYqfCJdnrP4PRYI 8p3bV9ZPU59a0Eqc8fhcQazXvaecUjzGfTpW2owkhQYtk2m7jDJ/Rzz6HbYpiToy 7P6N8T4dq9pp4Hb2ANARUPKYmcVYovYJtJZ9GD0zo5hWbi/i7sqPkJCO07RCyqg/ 5ePzmPqQorZP+nawhVbG =THS9 -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [GSOC] Status report - Tor capabilities
Hello tor-dev, For the last week I was on holiday for the graduation ceremony. I did however manage to get some work done, so for the past 2 weeks I have: - worked on adding parameter filters for the syscall filter; this is done using both a static list of parameters, as well as a dynamic list configurable at runtime; - parameter filters currently support numeric and pointer based parameters such as C strings; pointer based parameters are referenced in the original tor code through a getter (this was implemented for the 'open' syscall). - possibly identified a bug in libseccomp which was causing the accept4 syscall to fail to be added to the filter which was temporarily fixed by accepting all socketcall filters; still need to confirm this with nickm, but for those interested i believe -117 on this [1] line should be at least -120; my local fix makes everything work fine without socketcall. As a general conclusions things are going fine, I am currently trying to figure out what should go in the parameter filter. Another quick link to my remote branch for the ease of those interested: [2]. Looking forward to some feedback, if you happen to have any! References: [1] http://sourceforge.net/p/libseccomp/libseccomp/ci/release-2.1/tree/src/arch-x86.c#l86 [2] https://github.com/cristiantoader/tor-gsoc-capabilities/tree/gsoc-cap-stage2 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Status report - Stream-RTT
Hi all! During the last weeks I have been very busy working on my GSoC project which is about reducing the RTT of preemptively built circuits. There is now a single script called rttprober[0] that depends on a patched[1] Tor client running a certain configuration[2]. The goal is to measure RTTs of Tor circuits. It takes a few parameters as input: an authenticated Stem Tor controller for communication with the Tor client, the number of circuits to probe, the number of probes to be taken for each circuit and the number of circuits that should be probed concurrently. It outputs a tar file containing lzo-compressed serialized data with detailed node information, all circuit- and stream-events involved and the circuit build time for further analysis. Since the RTT-measurements are run in parallel with very short locks it is important not to overload Tor nodes. Therefore a single node is not probed more than once at a time. A first analysis of some measurements taken supports the original assumption that a Frechét distribution fits both the circuit build times[3] and round trip times[4]. I will continue gathering and analyzing measurement data and will hopefully be able to draw some conclusions from that. Best, Robert [0] https://bitbucket.org/ra_/tor- rtt/src/1127f6936086664981fc55b4dbc82b1570714140/rttprober.py?at=master [1] https://bitbucket.org/ra_/tor- rtt/src/1127f6936086664981fc55b4dbc82b1570714140/patches?at=master [2] https://bitbucket.org/ra_/tor- rtt/src/1127f6936086664981fc55b4dbc82b1570714140/torrc?at=master [3] http://postimg.org/image/je8k5yydt/ [4] http://postimg.org/image/ktk90vxm7/ signature.asc Description: This is a digitally signed message part. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] RFC: obfsproxyssh
On Fri, Jun 28, 2013 at 02:13:18AM -0700, Yawning Angel wrote: obfsproxyssh is a pluggable transport that uses the ssh wire protocol to hide tor traffic. It uses libssh2 and interacts with a real sshd located on the bridge side. Behaviorally it is identical to a user sshing to a host, authenticating with a RSA public/private key pair and opening a direct-tcp channel to the ORPort of the bridge. Is there a public server running this code that people can test against? David Fifield ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] RFC: obfsproxyssh
On Tue, 02 Jul 2013 23:42:20 +, Ximin Luo wrote: ... What sort of PKI are you using to verify the pubkey claimed by either side, to prevent MitM? What for? The authentication happens in the next step, within the OR/bridge protocol. In this case we just have an additional layer of encryption around it. Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [GSOC 2013] Steganography Browser Extension Status Report
Hi, My work plan for last week was to update the locale information and to finish file uploading parts of extension. For now testing purpose, when a file is being selected the byte format will be popped. With this, the locale information has being updated. With this, I have started working on adding public key encryption algorithms to the add on. This task has being planned to be finished before mid term evaluation and for next two weeks, my plan is to start working on image steganography libraries. -- Hareesan ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
