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