- tor-dev - lists.torproject.org

Fwd: python topics
by Ingy dot Net 22 Feb '13

22 Feb '13

Greetings, This is Ingy döt Net, a friend of ioerror's and arma's. I've been following Tor since 2009, and was asked to help out with ooni-probe a bit. I've been researching the state of the ooni, and was on a call with the primaries yesterday. I hack from a coworking space in Seattle that has a lot of various talent. During the call I learned that we need a light-weight, cross-platform gui button for using ooni-probe as simply as possible, and it would be nice to have it on the usual common platforms. I asked a co-coworker who runs the seattle python interest group (SeaPIG) for any advice and he sent me this email. Not sure it's the best stuff available, but at least we have starting points. Cheers, Ingy ---------- Forwarded message ---------- From: Ingy dot Net <ingy(a)ingy.net> Date: Wed, Feb 20, 2013 at 6:44 PM Subject: Re: python topics To: Jonathan Mark <jhmark(a)xenops.com> Thanks Jonathan! I'll let you know how it goes. On Wed, Feb 20, 2013 at 3:58 PM, Jonathan Mark <jhmark(a)xenops.com> wrote: > Tkinter is how to do a portable GUI: > http://wiki.python.org/moin/**TkInter<http://wiki.python.org/moin/TkInter> > > For building a standalone executable file: > There seems to be this new "pyinstaller" thing which sounds nice: > http://www.pyinstaller.org/ > > The old way I knew to do this is to use py2exe and py2app: > http://www.py2exe.org/ > http://wiki.python.org/moin/**MacPython/py2app<http://wiki.python.org/moin/MacPython/py2app> > > "Freeze" does it for Linux: > http://wiki.python.org/moin/**Freeze<http://wiki.python.org/moin/Freeze> > > I don't know how to do iOS or Android (unless a Linux solution covers > Android also) > > cheers, > > J >

1 0

Tor Browser Launcher
by Micah Lee 21 Feb '13

21 Feb '13

In my spare time I've been working on a way to make the Tor Browser Bundle easier to use for GNU/Linux users. I've mostly been talking about it with other people on tor-talk and in this bug: https://trac.torproject.org/projects/tor/ticket/5236 I decided to write Tor Browser Launcher, a completely separate program that's in charge or adding a "Tor Browser" .desktop file (so you can open it from your desktop environment's menu), downloads the latest version for you, verifies it's signature (making it more secure than how much GNU/Linux users get TBB), and installs it in your home directory. I think that Tor Browser Launcher can get in Debian and Ubuntu. I just finished a first version of it. The code is here: https://github.com/micahflee/torbrowser-launcher And there are screenshots here: http://imgur.com/a/Mvpwl You can read details about how it works on my latest comment on that bug: https://trac.torproject.org/projects/tor/ticket/5236#comment:32 Before trying to get it in Debian I'd like to make it so it doesn't need to be updated each time TBB is updated. There are more details in the ticket, but this would require Tor to maintain a file on https://www.torproject.org/ that has the current version number of TBB in it and a timestamp, and possibly digital signature of this file too. Do you think this is doable? I also want to get it localized into all the languages TBB is localized into. Any thoughts or suggestions? -- Micah Lee https://twitter.com/micahflee

7 27

Re: [tor-dev] Switch from Obfsproxy to Pyobfspoxy
by Nathan Freitas 21 Feb '13

21 Feb '13

(moved to tor-dev) Sorry I really haven't commented on this until now, but I have a lot of balls in the air, and sometimes minor, but very important details, like this slip by. George Kadianakis: > My current plan is to keep maintaining the C-Obfsproxy code, if it > keeps being as stable as it is today. For example, I plan to fix two > new-found bugs related to the shared-secret support of obfs2 soon > (#8217, #8223). Excellent. So we do have some time. > That said, I don't plan to port any of the new transports (like obfs3, > and some other pluggable transports currently under development) to > C-Obfsproxy any time soon (even though obfs3 wouldn't be *extremely* > hard to port, and I might consider it if there is a serious reason). Okay, I will take that into consideration. My plan then is to focus on determining how difficult supporting Pyobfsproxy on Android will be, and otherwise, try to find funding and resources to maintain the C version and potential to port obfs3. Thanks! +n

3 2

Re: [tor-dev] Proposal: Controller events to better understand connection/circuit usage
by Damian Johnson 20 Feb '13

20 Feb '13

> AppWard and ExitWard indicate the direction of cell flow through the > circuit. Previous cell events aggregated statistics for both directions and > therefore did not capture information which I believe may be important. > These are much more informative than N and P. Do you have suggestions for > improving this further? Ahhh, gotcha. Personally I'd go for 'inbound' and 'outbound' since they better connotate directionality. AppWard and ExitWard sound weird, but they make sense now too and would be fine if CELL_STATS got a quick description saying what they mean.

2 6

[Patch] or/onion_ntor.c
by Gisle Vanem 19 Feb '13

19 Feb '13

I suggest that the whole body of this file gets included inside an "#ifdef CURVE25519_ENABLED" in-case someone (like me!) inadvertently tries to compile it w/o this define set. Patch: --- Git-latest\src\or\onion_ntor.c Tue Feb 12 18:40:04 2013 +++ or\onion_ntor.c Tue Feb 12 23:46:51 2013 @@ -9,6 +9,8 @@ #include "torlog.h" #include "util.h" +#ifdef CURVE25519_ENABLED /* Rest of file */ + /** Free storage held in an ntor handshake state. */ void ntor_handshake_state_free(ntor_handshake_state_t *state) @@ -292,4 +294,4 @@ memwipe(&s, 0, sizeof(s)); return bad ? -1 : 0; } - +#endif /* CURVE25519_ENABLED */ --gv

2 1

changes to vidalia / browser launch in TBB?
by Greg Norcie 14 Feb '13

14 Feb '13

Hi all, I'm working on a followup to my usability paper from HotPETS... (http://petsymposium.org/2012/papers/hotpets12-1-usability.pdf) and doing some fact checking for the write up. I'm trying to find out if the developers tweaked Vidalia since v2.2.35-7.1. In my tests it seems like there is much less of a lag between Vidalia launching and the TBB window opening. I was hoping to find out if this was an intentional code change on the developers part, since it elliminates one of the isssues mentioned in my paper. -- -- Greg Norcie (greg(a)norcie.com) GPG key: 0x1B873635

1 0

Proposal: Controller events to better understand connection/circuit usage
by Karsten Loesing 12 Feb '13

12 Feb '13

Hi everyone, here's a proposal that defines three new controller events for the TestingTorNetwork mode that shall help us better understand connection and circuit usage in private Tor networks with the goal to make simulations more accurate. And there's also code: https://gitweb.torproject.org/karsten/tor.git/shortlog/refs/heads/morestats2 Feedback, to both proposal and code, much appreciated! Thanks, Karsten Filename: xxx-usage-controller-events.txt Title: Controller events to better understand connection/circuit usage Author: Rob Jansen, Karsten Loesing Created: 2013-02-06 Status: Open Target: 0.2.5.x 1. Overview This proposal defines three new controller events that shall help understand connection and circuit usage. These events are designed to be emitted in private Tor networks only. This proposal also defines a tweak to an existing event for the same purpose. 2. Motivation We need to better understand connection and circuit usage in order to better simulate Tor networks. Existing controller events are a fine start, but we need more detailed information about per-connection bandwidth, processed cells by circuit, and token bucket refills. This proposal defines controller events containing the desired information. Most of these usage data are too sensitive to be captured in the public network, unless aggregated sufficiently. That is why we're focusing on private Tor networks first, that is, relays that have TestingTorNetwork set. The new controller events described in this proposal shall all be restricted to private Tor networks. In the next step we might define aggregate statistics to be gathered by public relays, but that will require a new proposal. 3. Design The proposed new event types use Tor's asynchronous event mechanism where a controller registers for events by type and processes events received from the Tor process. Tor controllers can register for any of the new event types, but events will only be emitted if the Tor process is running in TestingTorNetwork mode. 4. Security implications There should be no security implications from the new event types, because they are only emitted in private Tor networks. 5. Specification 5.1. Adding an ID field to ORCONN events The new syntax for ORCONN events is: "650" SP "ORCONN" SP (LongName / Target) SP ORStatus [ SP "ID=" ConnId ] [ SP "REASON=" Reason ] [ SP "NCIRCS=" NumCircuits ] CRLF ConnID is the connection ID which is locally unique among all connection types and which is only included in TestingTorNetwork mode. The remaining specification of that event type stays unchanged. 5.2. Bandwidth used on an OR or DIR or EXIT connection The syntax is: "650" SP "CONN_BW" SP ConnID SP ConnType SP BytesRead SP BytesWritten CRLF BytesRead = 1*DIGIT BytesWritten = 1*DIGIT ConnID is the connection ID which is locally unique among all connection types. ConnType is the connection type, which can be "OR" or "DIR" or "EXIT". BytesWritten and BytesRead are the number of bytes written and read by Tor since the last CONN_BW event on this connection. These events are generated about once per second per connection; no events are generated for connections that have not read or written. These events are only generated if TestingTorNetwork is set. 5.3. Per-circuit cell stats The syntax is: "650" SP "CELL_STATS" SP PCircID SP PConnID SP PAdded SP PRemoved SP PTime SP NCircID SP NConnID SP NAdded SP NRemoved SP NTime CRLF PCircID and NCircID are the locally unique IDs of the app-ward (PCircID) and exit-ward (NCircID) circuit. PConnID and NConnID are the locally unique IDs of the app-ward (PConnID) and exit-ward (NConnID) OR connection. PAdded and NAdded are the total number of cells added to the app-ward (PAdded) and exit-ward (NAdded) queues of this circuit. PRemoved and NRemoved are the total number of cells processed from the app-ward (PRemoved) and exit-ward (NRemoved) queues of this circuit. PTime and NTime are the total waiting times in milliseconds of all processed cells in the app-ward (PTime) and exit-ward (NTime) queues of this circuit. PAdded, NAdded, PRemoved, NRemoved, PTime, and NTime are semicolon-separated key-value lists with keys being lower-case cell types and values being cell numbers or waiting times. These events are generated about once per second per circuit; no events are generated for circuits that have not added or processed any cell. These events are only generated if TestingTorNetwork is set. 5.4. Token buckets refilled The syntax is: "650" SP "TB_EMPTY" SP ["GLOBAL" || "RELAY" || "ORCONN" SP ConnID] SP ReadBucketEmpty SP WriteBucketEmpty SP LastRefill CRLF This event is generated when refilling a previously empty token bucket. The "GLOBAL" and "RELAY" keywords are used for the global or relay token buckets, the "ORCONN" keyword together with a ConnID is used for the token buckets of an OR connection. If both global and relay buckets and/or the buckets of one or more OR connections run out of tokens at the same time, multiple separate events are generated. ReadBucketEmpty (WriteBucketEmpty) is the time in millis that the read (write) bucket was empty. LastRefill is the time in millis since the last refill. ReadBucketEmpty or WriteBucketEmpty are capped at LastRefill in order not to report empty times more than once. These events are only generated if TestingTorNetwork is set. 6. Compatibility There should not be any compatibility issues with other Tor versions. 7. Implementation Most of the implementation should be straight-forward. There's one exception: we pondered adding a unique circuit ID to CELL_STATS events, but so far, only origin circuits have a unique ID. We could move that field from origin_circuit_t to circuit_t and update all references in the code. But this may have undesired side effects which we're not yet aware of. We don't have a good answer yet if we need this ID or not. 8. Performance and scalability notes Most of the new code won't be executed in normal Tor mode. Wherever we needed new fields in existing structs, we tried hard to keep them as small as possible. Still, we should make sure that memory requirements won't grow significantly on busy relays.

5 14

[Stegotorus] Dropping proxy test result
by vmonmoonshine＠gmail.com 10 Feb '13

10 Feb '13

Hi Zack, I added --drop-rate option to the tester-proxy and committed it to f--bad-proxy-ack-tester branch. I confirm that Stegotorus fails webpage-tester test when the drop-rate >= %10. Now, I'll go and look at the problem in more depth. Generally speaking, firefox is less successful in fetching web pages than webpage_tester, i.e. curl. I don't know why but I hope that problem will go away, when the problem with ack is solved. And on this: > Speaking of, vmon, I know you had trouble getting libcurl and libevent > to play nice -- did you ever look at libevhtp? First glance, I don't think it's helpful. It's an http server, isn't it? I need a http client which send the GET Request but let libevent to read the replay (only write in the socket). Hopefully I'll have more useful information soon. Cheers, Vmon

1 0

Documenting the translation process
by Runa A. Sandvik 07 Feb '13

07 Feb '13

Hi everyone, I started documenting how the translation process works for translators, developers, and those who manage it all: https://trac.torproject.org/projects/tor/wiki/doc/translation/Introduction. Any feedback will be greatly appreciated. Thanks, -- Runa A. Sandvik

1 0

Re: [tor-dev] [tor-talk] Exit Node Scanning Status
by Damian Johnson 03 Feb '13

03 Feb '13

> Actually, I might be a good fit. Feel free to ping me off-list to discuss. Unless there's a reason that you'd like to make this private it's better to have development discussions in the open (though tor-dev@ is probably more appropriate). Imho writing a SoaT counterpart based on either stem [1] or txtorcon [2] would be a great project if you're interested in improving our bad-exit detection infrastructure. Cheers! -Damian [1] https://stem.torproject.org/ [2] https://txtorcon.readthedocs.org/

4 5