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