19:09:38 #startmeeting? 19:09:38 Meeting started Wed Jul 30 19:09:38 2014 UTC. The chair is rl1987. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:09:38 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:09:52 i am nearby too 19:10:08 anyway, I'm curious to hear what happened during PETS conference. 19:10:08 hi! I am trying to get back into the swing of IRC and being online and not hiding. 19:10:38 my projects are: review 0.2.6 patches, plan the next year of work, finish testing trunnel. 19:11:44 it may be too late to ask about it, though. 19:11:50 hm 19:12:05 Mostly, there were cool talks! I'm particularly interested in the stuff about padding and traffic analysis. 19:12:24 the papers should all be online 19:12:28 what do you think is the best/most relevant paper? 19:13:17 hm. hard to answer. IMO everybody who might be interested in reading some of the papers should decide based on the abstracts. :) 19:13:28 aren't the all papers online? 19:13:33 they should be 19:13:39 https://petsymposium.org/2014/program.php 19:14:08 ah, I misunderstood what you meant by "should" 19:15:28 ooh, is there a meeting this week? 19:15:55 we're supposed to be having meetings every week, I believe. 19:16:19 athena: could be! What have you ben up to? 19:17:10 did you get some valuable input from researchers at PETS? 19:17:32 * asn not really here 19:17:50 let's see: reviewed #12585; ioerror offered some revisions, need to review again. not convinced "but they might diverge in the future" is really a good justification for duplicated code when the function can easily be split later if necessary. 19:17:56 fwiw, i have done progress in #9321 and #12595. this week I will do more of #9321 and also look at sysrqb's proposal draft. 19:18:07 athena: agreed that duplicated code is a very poor idea. 19:18:23 did most of #6456, and unit tested that icky function in the process, speaking of duplicated code 19:18:25 "They might diverge in the future" is an argument in favor of _all_ duplicated code 19:18:50 athena, asn: If you tell me your top two tickets to review, I will try 19:19:18 been looking at #12160, but think we need debug level logs or a place to run a test relay to repro for it 19:19:52 #12595 could use some architectural feedback. if you are busy, i can still progress some more without feedback though. 19:20:01 also a review of sysrqb's draft by another person would be great. 19:20:25 soon I will have some comments and code for review in #9321 too. 19:26:06 ok. anybody else have something to talk about today, or something other people should be working on? 19:29:46 i am thinking it would be nice to have a more thorough answer to "what do you get and not get from using a vpn with tor" 19:30:02 people could answering it with their own slant, and we even have a growing set of wiki pages about it. 19:30:15 that could be interesting 19:30:16 do you know if wfn ready to work on #12518 ? 19:30:17 Oh. 19:30:52 also I'm working on the "how to write tor tests" document thing 19:30:55 rl1987: I don't know. wfn ? 19:32:23 athena: re #12160, the relay operator offered to let you run relays there. 19:32:38 infinity0: Hey a long time ago you mentioned a bug with the fog server where if there are multiple users, the connections could get out of order. is that right? 19:32:48 yes 19:32:56 you mentioned that yesterday too, it is indeed a possibility 19:33:05 I've been really tired before the vacation, had to postpone looking into that problem; I have some ideas though. 19:33:18 i expect it only would happen for the existing code when the server is under heavy load, if at all 19:33:23 armadev: okay, thanks for letting me know 19:33:25 but we should definitely deal with it 19:33:50 ok so looking through the server code is that because of the that it stores connections or something more? 19:34:02 *stack 19:34:33 nickm: do you think there is a need for tor internals document like http://gcc.gnu.org/onlinedocs/gccint/ ? 19:34:38 cause i see that when an external connection is made, its pushed onto a stack and every internal connection pops it off 19:35:50 RushingWookie, there's background on the stack thing at https://gitweb.torproject.org/pluggable-transports/fog.git/commit/7b0a828794eceaef426574dc62d25eaf7757b8c1 19:35:55 and https://trac.torproject.org/projects/tor/ticket/7167#comment:38 19:36:04 thanks 19:37:09 rl1987: I would love a document like that. We're kinda-sorta applying for funding to write one. 19:37:15 i think 19:37:50 oh, cool. do you think it would be a good learning experience to read code and document it? 19:38:35 quite possibly! 19:39:06 rl1987: i started something like that a long time ago 19:39:18 i doubt I can find them now, but it's definitely a good learning experience 19:39:22 but also a *lot* of work 19:39:43 and there needs to be a easy way to maintain them automagically 19:40:27 well I'm dissatisfied that my learning-to-be-tor-dev thing is going kinda slow. 19:40:51 it takes time :) 19:41:01 is the bug about this “Using a stack rather than a queue means that we are virtually certain to invert the order of two near-simultaneous external connections.”? 19:41:27 trying to do a top-down document of how everything works is probably cleverer than a bottom-up one. 19:41:33 yeah, tor can be big and complex. don't get disheartened! 19:41:46 asn: (despite not being here) did you want to work on #12538 after it's designed? 19:41:47 sysrqb_: I would appreciate if you tried to dig out what you have written about internals 19:41:50 RushingWookie, it's not a bug, exactly. Using a queue rather than a stack is even worse for correctness. 19:41:53 asn: i'm happy to keep working on it 19:42:24 sysrqb_: let me read the proposal first to see what kind of work is involved. i would be happy to help anyway. 19:42:53 rl1987: it was over two years ago when I first got involved. I'm happy to help you with it now, though 19:43:06 asn: ack 19:43:21 yeah i see that from the rest of the ticket, it prevents zombie connections 19:43:23 hmm, tor changed quite a bit in last two years. 19:43:45 oh and one more thing. I think 0.2.5 is blocking on #12184. I really hope somebody can figure out what's going wrong there. 19:44:40 i'll take a look 19:46:14 RushingWookie: it seems that to really match up metadata for from-Internet and to-ExtORPort connections properly, we would need something like ExtORPort chaining, where every server PT would need to also be an ExtOR server just like Tor is. 19:46:39 okay. Now it is time for me to say goodbye for the afternoon and pick up my kid from school! 19:46:42 thanks, everybody! 19:46:50 endmeeting? 19:46:53 sure 19:46:54 That seems like a drastic step to take, which I think is why the "good-enough" stack hasn't been replaced yet. 19:47:09 i see 19:47:11 I will try to be online tomorrow and friday during reasonable hours too if I can 19:47:13 There might be a better way than ExtORPort chaining. 19:47:26 #endmeeting