13:30:10 #startmeeting 13:30:10 Meeting started Wed Sep 10 13:30:10 2014 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:30:10 Useful Commands: #action #agreed #help #info #idea #link #topic. 13:30:13 Welcome all! 13:30:20 hi meeting 13:30:24 hi 13:30:28 hello 13:30:36 hi 13:30:38 let's check in. I see asn, Yawning, athena, ioerror, armadev, and mvdan. 13:30:43 anybody else around? 13:31:50 * asn has right hand in a cast. typing speed is reduced. 13:31:56 I wonder if the "teor" person who has bveen submitting patches is online 13:32:05 ouch. what happened? 13:32:25 fall and bad landing... scaphoid fructure. 13:32:43 ow 13:33:11 shall I start the meeting with what i've been doing? :) 13:33:12 dominant hand? 13:33:14 yeah 13:33:16 sure! 13:33:20 soo 13:33:23 i've been working on #9321 13:33:32 * nickm nods 13:33:35 writing unittests, and testing the auth-side and client-side on a chutney network 13:33:48 it kind of works. i'm now cleaning up code and exterminating XXXs. 13:34:08 asn: owww :( 13:34:08 on the way there, I opened the not-very-serious #13064 and #13066. 13:34:25 a few thoughts on #9321: 13:34:49 a) I'm not sure what to do with smartlist_choose_node_by_bandwidth(). It seems to be the legacy way of calculating bandwidth weights, when bw auths are not activated. 13:35:10 the algoirthm is weird and docuemnted on a tor-dev thread. should I bother changing that function to do guardiness? 13:35:31 hm? smartlist_choose_node_by_bandwidth() uses weights from the consensus right? 13:35:58 I think that's smartlist_choose_node_by_bandwidth_weights(). 13:36:00 they are sisters. 13:36:12 see node_sl_choose_by_bandwidth(). 13:36:15 I wonder if we can eliminate one of them through careful consideration. 13:36:33 i don't see it ever used in my regular tor client and tor network. but I need to check again. 13:36:33 Like, have all weights default to 1 or something 13:36:47 * dgoulet just arrived. I'm here 13:36:50 it might be a good idea to have a ticket for eliminating the less-used one 13:36:50 also, it doesn't consider bad exits (#13066). 13:36:53 ok 13:36:57 i will consideri t. 13:37:03 let's move to qanother question 13:37:12 one of the things I'm afraid with the guardiness project 13:37:15 is dirauth misconfiguration 13:37:44 for example, maybe a diruath hasn't archived 3 months worth of consensus. and is only calculating guardfraction based on one day worth of consensuses. 13:38:03 should there be an easy to way to detect such misconfiguration? 13:38:22 should the number of consensuses considered be mentioned in votes, for example? 13:38:41 or just don't vote about it if you know you don't have enough data 13:38:52 i'm afraid of these sysadmins/misconfiguration errors, because I see that the bwauth project is a bit rusty. and bwauth is even more important than guardiness. 13:39:29 hm. i can indeed have some kind of logic like that. don't vote if you have less than 70 13:39:44 hm. i can indeed have some kind of logic like that. don't vote if you have less than 70% of consensuses for the past 3 months. 13:39:50 or something. 13:40:04 i will think about it. it might kill some misconfiguration scenarios... 13:40:08 i'm afraid i don't know the full proposal yet, so i still have all the questions i had in amsterdam, but i shouldn't distract us all now with that. 13:40:22 oh 13:40:36 feel free to send a short email with questions to [tor-dev], and I will answer. 13:40:52 i'm also a bit nervous about the project. because thse extenrla scripts that dirauths are supposed to run and maintain are a bit akwarad. 13:41:09 i think these are the main engineering questions I have. 13:41:16 i have a few more, but I can send them to [tor-dev] 13:41:19 and let the meeting flow. 13:41:19 do dir auths run the external scripts to bootstrap, and then maintain the numbers themselves? or do they re-run the external scripts periodically? 13:41:29 they run it periodically 13:41:32 ok. 13:41:32 before voting. 13:41:45 the script should take 10 seconds or so to run. with 3 months of consensuses. 13:42:24 if no one else has questions/answers on guardiness, I suggest to let the meeting continue with the next status report. 13:42:51 my task for today and tomorrow, is to find a convincing unittest/test vector for the guardiness -> bandwidth weight calculation. 13:43:25 i currently have unittests, forparsing guardiness from consensus/svotes and for parsing the guardiness script output file. 13:44:11 (my network is going to die here in a moment, so I'll just toss in that I'm working on #12585 #12693 #13111) 13:44:21 * ioerror is out 13:45:03 asn: nice 13:45:07 ioerror: see you around 13:45:08 Oh I was gonna poke at the SocksSocket stuff 13:45:14 ioerror: ^ 13:45:16 but if you're working on it I'll hold off 13:45:30 Yawning: (if he doesn't answer here, maybe send email?) 13:45:39 yah 13:46:58 asn: done? 13:47:01 who's next? 13:47:09 Mine's short 13:47:42 I cleaned up the #8402 patch, was gonna poke at #12585, but baring that I'll start carving a trail of destruction and mayhem through the bridge code 13:48:10 nickm: yes done. 13:48:20 Yawning: leaving a swathe of order and cleanliness in your wake? :) 13:48:23 said trail wills tart with triaging stuffs that I need to look at 13:48:31 i found and fixed a bug for #12160, but the original reporter is claiming it wasn't *his* bug, so i'm probably going to look into that more next 13:48:32 nickm: ideally yes 13:48:38 fair enough 13:48:56 athena: check the message again maybe? 13:49:05 Yawning: what is the trail of destruction for? #12585? or all the other bridge improvemenrts? 13:49:08 message? 13:49:14 athena: my impression from his last comment on #12160 was that maybe it worked? 13:49:15 asn: the latter 13:49:18 athena: he edited his message to say that it did work, I think 13:49:19 ack 13:49:28 #12160 does work. 13:49:41 i spoke with the bug reporter recently and he confirmed. 13:49:41 ah! 13:49:47 Gotta triage that list we had, do planning, see if there's stuff we missed etc 13:49:50 he is now waiting to see if he will get an increase in traffic. 13:49:54 he went and used my "more debug output, no actual code changes" branch :) 13:49:55 nickm: I'll have to run in a minute, I just wanted to quickly say that I emailed both Sebastian and you about yesterday. And I'm making chutney support both python2 and python3. 13:50:06 great 13:50:12 yawning: i'm probably your best bet for the "what did you mean for the bridge algorithm to do there" questions. i'll try to be helpful there. this week is better than, uh, the next three. 13:50:38 armadev: mmk 13:51:31 nickm: ah also. the actual python script that will calculate the guardinses is ready for review. 13:51:36 think a lot of it is more pt oriented (like, figiring out how to make dual stack pluggable transport configs actually work nicely) 13:51:48 *figuring 13:52:06 ok 13:52:20 nickm: there are two scripts. not very complicated. i estimate 1-2 hours of review time. 13:52:37 yawning: it would be cool to highlight the "bridges really don't work the way they should" insights that you run across, during this trail of tears. 13:52:41 though the two things off the top of my head I know arn't are running bridges without an ORPort and 4 hop circuits when using bridges 13:52:45 yeah 13:52:47 nickm: https://trac.torproject.org/projects/tor/ticket/9321#comment:26 13:53:32 I think all the pople that brought up that it should be a bridge in addition to our guard as opposed to a bridge *instead* of the guard are right 13:53:36 asn: Could you make a needs_review ticket? I havea hard time remembering to review non-needs_review stuff 13:53:43 nickm: ok 13:53:45 thanks 13:53:57 (that's it for me) 13:53:57 athena: so, what are you planning to work on at this point? 13:56:40 if #12160 is settled, i'll probably have a look at some of our 28 needs_review tickets in 0.2.6 next 13:56:52 great 13:57:02 I tagged the ones I did the patch for with nickm-patch, so I know what not to review 13:57:12 remember to take a break from reviewing too to hack easy stuff 13:57:16 heck knows there's a lot o fit 13:58:15 okay 13:58:38 if you want to brainstorm any of them, I'll be around 13:58:45 let's see. are we up to me? 13:59:14 you and/or dave? 13:59:30 I've been hacking all kinds of tickets, and applying all kinds of patches. In the Big Stuff department, I got my ed25519 hackery a bit more tested, by adding a reference implementation in python and using it to generate test vectors 13:59:33 athena: i am also happy to help suggest tickets that would be useful for you to look at, if you find yourself overwhelmed at the variety 14:00:10 I wrote two new features for trunnel. I'm going to call it version 0.99 pretty soon 14:00:25 I've been trying to remember to review patches too 14:00:26 \o/ 14:00:49 I wonder, who was going to set up a code review tool for us? 14:01:01 ISTR somebody advocating for it hard and saying they would totally maintain it 14:01:07 helix I think? 14:01:15 was gonna look into it? 14:01:30 I vaguly remember similar conversations from the dev meeting 14:01:32 guerrit? 14:01:42 yeah 14:02:38 nickm: btw, i think it's possible we still have a few warts in the orport reachability code for cases where there are multiple orports being advertised and only some are reachable 14:03:06 but those would have been there pre-channelization and would be trickier to fix 14:03:30 yeah 14:03:40 athena: pre channel was also pre multiple orports being advertised, i think 14:04:06 there are definitely bugs ('bugs') currently where if 1 of your orports isn't reachable the dir auth with mysteriously without the Running flag for you 14:04:19 limited to ipv6 i think, since that's the only other thing dir auths know how to check. 14:04:28 s/with/will/ 14:04:40 s/without/withhold/, uh oh for arma. 14:04:45 the problem is that in reverse-proxy cases like in #12160 we can't tell what orport a given connection arrived on, so just having a reachability bit per advertised orport isn't enough 14:05:10 we'd have to actually change the detection mechanism so that testing circuits let the relay tell itself what port it was trying to test through the circuit or something like that 14:05:29 netinfo cells say the address that was tried. perhaps they do, or should, say the port too? 14:05:29 I voted not-running for a significant portion of the network when my hoster broke my dirauths ipv6 14:05:36 took a while for me to realize what was going on 14:05:40 yeah, ISTR helix being the big gerrit advocate too 14:06:04 armadev: i think that might be sufficient 14:06:40 i'll file a new ticket for this 14:06:51 athena: from tor-spec.txt it looks like they currently only say an address. but it is extensible, sort of. 14:06:58 For gerrit/other tool, I am willing to try whatever the advocate wants to maintain. 14:08:49 athena: we'll actually also want that netinfo extension in the case of reaching bridges that have many people redirect flows to them. 14:09:09 (see earlier discussion of using a few iptables rules to set up a bridge, meaning to pass flows into somebody else's bridge.) 14:11:05 more from nickm? 14:11:57 my next steps are mainly getting 0.2.5 out and getting out some libevent releases, which I've been putting off. I hope I can do a bunch of code review and hacking too 14:12:15 athena: thanks for helping with code review BTW; there's too much for me to do on my own and still hack 14:12:24 armadev: anything up with you? 14:12:28 wrt tor 14:12:43 i have been playing manager / leader / whatever it's called lately 14:13:03 things are looking good for starting (negotiations for) SponsorR this week 14:13:25 among my next steps: need to work with David Goulet and Yawning to make sure their proposed deliverables are both suitable and wise 14:13:31 nickm: np 14:13:32 *looks at the cheat sheet* 14:13:51 i also interviewed a potential project manager to help developers of tor do all the things. not that we'll necessarily pick him, but he would do fine at it imo, so this is a good start. 14:14:18 i have also been dabbling at trac tickets in my spare time, inamongst the business stuff. 14:14:45 in a few days i will spend two weeks doing all-day-every-day sponsorR meetings in DC 14:15:30 and, that's it for me, unless somebody has questions or wants more details 14:16:32 Is there anything you're really hoping this team will do/not do in the rest of sep/oct? 14:16:55 1) the kist stuff, which i hear starts with the global circuit scheduler 14:17:19 2) a plan for hidden service performance measurement and instrumentation and so on (that's the david side) 14:17:56 3) i should have a chat with yawning about what tor items we should plan to do on what timeframe for SponsorS. we need to tell karen a Q4 plan for SponsorS in october. 14:19:15 those are the main three. 14:19:47 armadev: thanks for the update, ping me anytime when you want to check on the deliverables I suggested and maybe also discuss 2) if needed 14:20:40 athena, armadev: It sounds like coordinating together the three of us, plus Rob Jansen, is our best chance of getting progress there. 14:20:59 athena: what are next steps on that? I know you've been revising the circuit scheduler stuff for 0.2.6; have you been in touch with Rob? 14:21:24 not yet; have you got his contact info? 14:21:46 armadev: can you send an email to athena and Rob suggesting that they start collaborating on KIST things? 14:21:58 If I'm in the middle on this, it might not go as fast as it should. 14:22:15 (Which is not that I'm not available whenever y'all need me, but I shouldn't be the driving force here.) 14:22:28 i talked to rob last week. he knows he wants to do it. he doesn't know how to get anybody on our side to do anything. 14:22:42 he believes the next step is that andrea will clean up her patch. 14:22:43 armadev: Also, I am a little scared of athena's patch. The quality appears quite high, but it is BIG. Can you help me review it? 14:23:08 hm. yes, i hope so. i guess one of my first questions will be why it is so big. 14:23:25 (what's the ticket #?) 14:25:31 i want to know too 14:25:36 #9296 14:25:38 err 14:25:42 #9262 14:25:58 *adds to the whiteboard of doom* 14:26:37 rob pointed out that just moving to global circuit scheduling won't help without also dealing with kernel buffer load. but i figure one step at a time. 14:27:11 and it's pretty clear that we do want to do this better scheduling approach i think. it's the clearly smarter design. unless for some reason this patch is too crazy i guess. 14:27:51 like I said: sane but big. It touches a lot of code and cleans up a fairly hefty amount of spaghetti 14:27:56 athena: rob asks "Is there any documentation (other than the code) about the approach taken here?" 14:27:58 have a look when you have a chance 14:28:07 armadev: there are a bunch of comments in the code 14:29:56 I think we've moved on from meet to chat, so... 14:29:57 #endmeeting