13:30:37 <nickm> #startmeeting
13:30:37 <MeetBot> Meeting started Wed Oct 22 13:30:37 2014 UTC.  The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:30:37 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:30:43 <nickm> who's here today?  I am!
13:30:48 <Yawning> \o
13:31:27 <nickm> huh.
13:31:30 <Yawning> well, if it's just the two of us this will be simple
13:31:32 <nickm> hi, Yawning !
13:31:33 <nickm> anybody else?
13:31:35 <nickm> yeah.
13:31:37 <Yawning> hi nickm !
13:31:41 <dgoulet> hello! (ouf made it)
13:31:46 <nickm> hi dgoulet!
13:31:55 <Yawning> dgoulet: o/
13:32:09 <athena> nickm: hi!
13:32:17 <nickm> hello athena!
13:32:38 <nickm> It's a rainy morning over here.  Let's get started with quick status updates, then see what we should talk about.
13:33:27 <teor> hi
13:34:17 <athena> status update: i have a patch for #12194 and should respond to nickm's comment there; been working on #10168
13:35:17 <nickm> hi teor
13:35:21 <nickm> athena: awesome!
13:35:33 <nickm> for 10168, what's your strategy?
13:36:26 <nickm> I can imagine a patch that replaces X% of the calls to time functions with a call to a monotonic time function... I'm not sure how to make sure we got all the right ones, though.
13:37:59 <athena> i'm going with the thing you propose with introducing a new type, i think, and i'm drawing up a list of calls to time functions and assessing how we're using them, which i'll be posting to the ticket for discussion
13:38:32 <athena> we'll see how bad it gets; hopefully there won't be too impenetrable a jungle of hard-to-judge cases
13:38:41 <nickm> cool
13:39:45 <nickm> Ping me when it's done, or if you have any questions, or stuff like that.
13:39:50 <nickm> who wants to go next?
13:40:54 <nickm> me, I guess
13:41:01 <athena> np
13:41:06 <nickm> I've been trying to pay attention to stuff and merge patches.
13:41:21 <nickm> I've been chugging forward with proposals 220 and 228, and thinking about integratino testing strategies
13:41:30 <nickm> I lost a day or so to openssl explosions and doing releases.
13:41:38 <mrueg> atagar: ping
13:41:42 <nickm> (I think 0.2.5.10 comes out this week. Let me know if you think it shouldn't.)
13:41:57 <nickm> We should figure out some quick way to analyze how we did with our 0.2.5.10 plans
13:42:30 <nickm> For 220/228, I got link handshakes fully tested and then replaced them with a trunnel implementation.  Next will come extending them to support ed25519 link handshake...
13:42:44 <nickm> but before I do that, I want to get descriptor generation and key management more tested
13:42:49 <nickm> http://paste.debian.net/128132/ --
13:43:01 <nickm> that's the output of a python script I wrote that knows how to sign descriptors.
13:43:15 <nickm> This is approximately what a minimal 0.2.6 descriptor might look like
13:43:51 <nickm> I'm also trying to process all the stuff in Mike and Roger's "vegas plan", and reintegrate all our deliverables into a timeline
13:44:02 <nickm> and that's where I'm at
13:45:18 <nickm> who's next?  dgoulet? Yawning?
13:45:33 <Yawning> uh, didn't do much directly on little t tor
13:45:41 <Yawning> helped with the openssl thing (whee)
13:45:46 <Yawning> did review of stuff like usual
13:46:02 <Yawning> I'm in my own private hell of nat traversal mechanisms now
13:46:06 <Yawning> all broken
13:46:18 <asn> i'm also around
13:46:19 <nickm> they sound pretty fun tbh
13:46:22 <nickm> hi asn!
13:46:33 <asn> i revised my #9321 branch after comments from nickm
13:46:40 <asn> it's back to needs_review now
13:46:44 <Yawning> it's easy to implement if stuff deployed wasn't buggy :/
13:46:47 <asn> but now I'm playing with SponsorR stuff
13:46:54 <asn> so I have stalled #9321 for a bit.
13:47:03 <nickm> asn: ok.  I think that's big enough that I should review it along with some other person.
13:47:16 <asn> I'm planning to come back with #9321 and help weasel/sebastian/etc. to deploy the guardines script in their dirauth
13:47:21 <asn> nickm: that would be great
13:47:38 <asn> in the meanwhile I have a few SponsorR stuff to do.
13:47:44 <asn> and that's that :)
13:47:54 <nickm> ok.  Is any of that SponsorR stuff things I need to be aware of too?
13:48:02 <asn> hmmm
13:48:08 * asn tries to recall his TODO list
13:48:13 <dgoulet> nickm: yes there is
13:48:32 <asn> one of the things include writing a doucment with karsten about which HS statistics are a good idea and wich are not.
13:48:32 <nickm> asn: you don't need to let me know now, but please send me an email if you need something
13:48:37 <asn> nickm: ah sure
13:48:45 <dgoulet> nickm: I yet have to create a ticket for the list of performance measurements I gather yesterday at the meeting, feedback would be great
13:48:48 <nickm> interesting; I'd be happy to review an outline there
13:49:03 <nickm> dgoulet: ok; feedback after you make the ticket, or at some earlier stage?
13:49:07 <asn> nickm: yep, you will definitely see it after we have written something
13:49:19 <dgoulet> nickm: oh after, once the tricket is created, I'll send it to you
13:49:32 <asn> another thing includes reading #1944 and understanding exactly how Karsten has produced those measurements,
13:49:49 <asn> that is which controil events he is listening for, and where ethese control events get triggered in the code
13:50:15 <nickm> ok
13:52:03 <nickm> anything else?
13:53:00 <nickm> anyone else?  I've seen some neat patches from teor...
13:53:38 <teor> Yeah, looking into Xcode in #13461, that's an early WIP
13:54:03 <teor> It gives us access to many of the graphical tools on OS X. Graphical debuggers are my friends.
13:54:55 <teor> I also logged #13414 about the maximum tor relays per IP address based on mailing list discussions
13:55:05 <teor> How do we change a consensus parameter like that?
13:55:24 <nickm> get a sufficient number of authorities to vote on the new value
13:56:08 <teor> I guess I meant: how do we convince those running the authorities? Is it a proposal?
13:56:42 <nickm> there isn't a formal process.  If you convince a few of them, the rest usually go along.
13:56:51 <asn> teor: usually it needs a nicely written email
13:56:55 <asn> with good instructions
13:57:01 <asn> that can be followed easily
13:57:06 <asn> and a convincing argument :)
13:57:06 <nickm> tor-dev is a good place to bring up the idea if it needs public discussion, which I think it might.  Or try to get them talking on the ticket
13:57:40 <teor> I think we're still debating 4 vs 8
13:57:59 <teor> on the ticket, and the subject seems to come up fortnightly on the list
13:58:36 <teor> I'd prefer to have a better idea of the desired number before writing a request
13:58:43 <nickm> fair enough
13:59:13 <Yawning> there's path selection simulation code out there if you think numbars would be useful
13:59:28 <teor> I'll wait to see if there is a consensus either way - or a convincing argument arises :-)
13:59:37 <nickm> asn: Do you think #6938 is good to merge?  You liked the code, and it works okay for me.
14:00:02 <Yawning> don't know if "quantifying loss of anonymity via numbars" is easy (probably not)
14:00:05 <teor> Yawning: it won't affect most relays - just those which are CPU-bound
14:00:09 <asn> nickm: i think so yes
14:00:12 <asn> nickm: but i didn't test it
14:00:22 <nickm> asn, athena: also, #13477 is a very short patch, and it touches the intro circuit logic, which I think you understand pretty well.  Could you have a look at it?
14:00:22 <asn> nickm: if you have tested it, i think it;s fine to merge.
14:00:29 <nickm> err not that one
14:00:39 <nickm> asn, athena: also, #13447 is a very short patch, and it touches the intro circuit logic, which I think you understand pretty well.  Could you have a look at it?
14:00:39 <teor> That's mine :-)
14:00:53 <asn> nickm: yes I can take a look at #13447
14:00:58 <nickm> thanks
14:01:04 <asn> however,tomorrow morning I'm leaving for an OONI hackathon...
14:01:12 <athena> nickm: re: #13447, yeah, think so
14:01:12 <asn> so I will be active again next monday.
14:01:18 <Yawning> how much pain would it be to change how tor expects tor-fw-helper to behave?
14:01:20 <asn> in any case, I noted it in my TOREVIEW list.
14:01:24 <Yawning> code was farily well isolated
14:01:28 <nickm> athena, asn: don't spend too long on it; it's just a 2-3 line change
14:01:53 <Yawning> kind of want to make the helper long lived, but not sure if that will cause other headaches
14:02:36 <Yawning> (only thing that "uses" said helper are flashproxy and tor right?)
14:02:47 <nickm> Yawning: Well, changing that would mean that people using 0.2.5.x won't be able to test a persistent tor-fw-helper.
14:03:16 <nickm> One half-considered option would be to make tor-fw-helper an interface to a persistent tor-fw-daemon
14:04:20 <Yawning> ooof
14:04:41 <Yawning> "do the simple thing first, deal with daemonizing this later"
14:04:48 <nickm> sounds smart
14:04:51 <Yawning> just wanted a rough estimate
14:04:59 <ioerror> if anyone is interested - #tlsdate-dev is where I'm doing stuff with tlsdate these days
14:05:14 <Yawning> current master is the simple thing, but it will explode some routers
14:05:22 <nickm> Probably wouldn't be too tricky, compared to doing the tor-fw-helper rewrite.
14:05:23 <Yawning> so if you're really breave, people can play wiht it
14:05:30 <Yawning> yeah
14:06:32 <ioerror> nat-pmp support was why we wrote tor-fw-helper
14:06:39 <ioerror> hopefully, whatever we end up with - we keep natpmp
14:06:41 <Yawning> I'm writing it
14:06:44 <Yawning> right now
14:06:51 <Yawning> I went and bout an apple airport eexpress yesterday
14:07:07 <ioerror> what was the problem with tor-fw-helper? NIH for the libs it uses?
14:07:10 <Yawning> I need to find someone to write the windows getGateway() routine
14:07:22 <Yawning> the libs are to quote arma "unmaintained garbage"
14:07:25 <nickm> "Too scary" for the libs it uses
14:07:28 <Yawning> the code quality was like.... ehhh
14:07:33 <ioerror> seems like we should fork and fix
14:07:36 <nickm> feelfree
14:07:46 <ioerror> rather than rewriting tor-fw-helper - we can just plug in new code for tor-fw-helper
14:07:58 <ioerror> that was the idea behind tor-fw-helper - just add new code for the calls we need
14:08:14 <ioerror> unsure if there are problems other than the libs though
14:08:18 <nickm> That's also a valid architectural choice.
14:08:18 <Yawning> well, I have a upnp client and will finish nat-pmp tonight >.>
14:08:45 <Yawning> doing xml/http in C seems like a not-great idea when alternatives are possible, but that's jus tme
14:08:45 <ioerror> Yawning: if you can sew that up to replace the default libs, then i bet we could just enable it
14:08:48 <nickm> But yawning's the one who feels like doing a high-quality upnp and nat-pmp implementation, so I'm not going to say it's got to be in C.
14:09:05 <ioerror> Yawning: yes, seccomp + other stuff seems important also
14:10:33 <nickm> seems like it should be amenable to a seccomp wrapper.  especially if it becomes a nice daemon down the line
14:11:17 <Yawning> lorax
14:11:39 <Yawning> I'll settle for in a memory safe language, doesn't segfault as 0.1 >.>
14:11:41 <nickm> yeah.  This is taking the idea in a direction that I'm not afraid to run on my computer.
14:11:52 <teor> I was just going to say that, Yawning
14:12:00 <nickm> One thing that I _am_ worried about is the support issues for horrible routers down the line.
14:12:22 <Yawning> I'm gonna add command line args for dumping/purging hte table
14:12:47 <nickm> It's also going to be pretty helpful if we present enough information in our error messages so that users can cut-and-paste info that will tell you how to fix the library
14:12:56 <Yawning> but apparently certain routers get into states that require wiping the nvram, which will make me sad
14:13:11 <nickm> Do the existing libraries have a workaround for that?
14:13:26 <Yawning> so, a lot of the "table is full" broken behaviors start with "the stack doesn't issue an error" apparently
14:13:37 <Yawning> dunno, I'd need to check
14:14:22 <Yawning> think for our usage we're actually unlikely to hit the lease limit unless we change the external port
14:14:49 <Yawning> and who knows, *maybe* stacks have gotten better
14:14:50 <nickm> anything else we should be talking about for review today?
14:14:52 <Yawning> (ha)
14:15:25 <nickm> anything languishing in needs_revision?
14:16:08 <nickm> dgoulet: are you still poking #8195 ?
14:16:45 <dgoulet> nickm: not recently... :S , is there like a important need for it for pt soon ?
14:16:51 <Yawning> no
14:17:03 <Yawning> you can setcap obfs4proxy and get the same effect
14:17:12 <dgoulet> it actually just need more testing and figure out best practices with pythoN!
14:17:21 <Yawning> (and people do this in the wild, so)
14:17:38 <Yawning> I for one welcome our new obfs4proxy overlords
14:18:26 <teor> I've installed obfs4proxy on my bridge and it works great.
14:18:35 <Yawning> ^_^
14:19:12 <dgoulet> nickm: nothing much on my side tbh, really still bootstraping heavily and figuring out where I'm the more useful short term
14:20:46 <nickm> ok; thanks fine
14:21:00 <nickm> anything else for the meeting today?
14:21:41 <teor> Two more minor patches: #13476 helps us not underflow time below the year 1. #13111 regenerates existing but empty key files, rather than erroring.
14:22:27 <nickm> I merged #13476, I believe
14:22:50 <nickm> For #13111 I'm kinda hoping we can think of a prettier API. But I might just give up eventually.
14:23:04 <nickm> I'm also wondering wrt #13111 if it's worthwhile to think about every other way a key file could be corrupt.  Maybe not.
14:23:12 <nickm> (Since we haven't run into those.)
14:23:32 <teor> I wondered that, too
14:24:52 <nickm> Anything else we should keep everyone around for?  If not, let's end the meeting and keep talking
14:25:48 <teor> Not from me. #13414 was the most interesting one
14:26:14 <nickm> #endmeeting