13:30:10 <nickm> #startmeeting
13:30:10 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:30:13 <nickm> Welcome all!
13:30:20 <athena> hi meeting
13:30:24 <asn> hi
13:30:28 <mvdan> hello
13:30:36 <ioerror> hi
13:30:38 <nickm> let's check in.  I see asn, Yawning, athena, ioerror, armadev, and mvdan.
13:30:43 <nickm> anybody else around?
13:31:50 * asn has right hand in a cast. typing speed is reduced.
13:31:56 <nickm> I wonder if the "teor" person who has bveen submitting patches is online
13:32:05 <nickm> ouch. what happened?
13:32:25 <asn> fall and bad landing... scaphoid fructure.
13:32:43 <nickm> ow
13:33:11 <asn> shall I start the meeting with what i've been doing? :)
13:33:12 <nickm> dominant hand?
13:33:14 <asn> yeah
13:33:16 <nickm> sure!
13:33:20 <asn> soo
13:33:23 <asn> i've been working on #9321
13:33:32 * nickm nods
13:33:35 <asn> writing unittests, and testing the auth-side and client-side on a chutney network
13:33:48 <asn> it kind of works. i'm now cleaning up code and exterminating XXXs.
13:34:08 <athena> asn: owww :(
13:34:08 <asn> on the way there, I opened the not-very-serious #13064 and #13066.
13:34:25 <asn> a few thoughts on #9321:
13:34:49 <asn> 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 <asn> the algoirthm is weird and docuemnted on a tor-dev thread. should I bother changing that function to do guardiness?
13:35:31 <armadev> hm? smartlist_choose_node_by_bandwidth() uses weights from the consensus right?
13:35:58 <asn> I think that's smartlist_choose_node_by_bandwidth_weights().
13:36:00 <asn> they are sisters.
13:36:12 <asn> see node_sl_choose_by_bandwidth().
13:36:15 <nickm> I wonder if we can eliminate one of them through careful consideration.
13:36:33 <asn> i don't see it ever used in my regular tor client and tor network. but I need to check again.
13:36:33 <nickm> Like, have all weights default to 1 or something
13:36:47 * dgoulet just arrived. I'm here
13:36:50 <nickm> it might be a good idea to have a ticket for eliminating the less-used one
13:36:50 <asn> also, it doesn't consider bad exits (#13066).
13:36:53 <asn> ok
13:36:57 <asn> i will consideri t.
13:37:03 <asn> let's move to qanother question
13:37:12 <asn> one of the things I'm afraid with the guardiness project
13:37:15 <asn> is dirauth misconfiguration
13:37:44 <asn> 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 <asn> should there be an easy to way to detect such misconfiguration?
13:38:22 <asn> should the number of consensuses considered be mentioned in votes, for example?
13:38:41 <armadev> or just don't vote about it if you know you don't have enough data
13:38:52 <asn> 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 <asn> hm. i can indeed have some kind of logic like that. don't vote if you have less than 70
13:39:44 <asn> 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 <asn> or something.
13:40:04 <asn> i will think about it. it might kill some misconfiguration scenarios...
13:40:08 <armadev> 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 <asn> oh
13:40:36 <asn> feel free to send a short email with questions to [tor-dev], and I will answer.
13:40:52 <asn> 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 <asn> i think these are the main engineering questions I have.
13:41:16 <asn> i have a few more, but I can send them to [tor-dev]
13:41:19 <asn> and let the meeting flow.
13:41:19 <armadev> 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 <asn> they run it periodically
13:41:32 <armadev> ok.
13:41:32 <asn> before voting.
13:41:45 <asn> the script should take 10 seconds or so to run. with 3 months of consensuses.
13:42:24 <asn> if no one else has questions/answers on guardiness, I suggest to let the meeting continue with the next status report.
13:42:51 <asn> my task for today and tomorrow, is to find a convincing unittest/test vector for the guardiness -> bandwidth weight calculation.
13:43:25 <asn> i currently have unittests,  forparsing guardiness from consensus/svotes and for parsing the guardiness script output file.
13:44:11 <ioerror> (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 <nickm> asn: nice
13:45:07 <nickm> ioerror: see you around
13:45:08 <Yawning> Oh I was gonna poke at the SocksSocket stuff
13:45:14 <nickm> ioerror: ^
13:45:16 <Yawning> but if you're working on it I'll hold off
13:45:30 <nickm> Yawning: (if he doesn't  answer here, maybe send email?)
13:45:39 <Yawning> yah
13:46:58 <nickm> asn: done?
13:47:01 <nickm> who's next?
13:47:09 <Yawning> Mine's short
13:47:42 <Yawning> 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 <asn> nickm: yes done.
13:48:20 <nickm> Yawning: leaving a swathe of order and cleanliness in your wake? :)
13:48:23 <Yawning> said trail wills tart with triaging stuffs that I need to look at
13:48:31 <athena> 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 <Yawning> nickm: ideally yes
13:48:38 <nickm> fair enough
13:48:56 <nickm> athena: check the message again maybe?
13:49:05 <asn> Yawning: what is the trail of destruction for? #12585? or all the other bridge improvemenrts?
13:49:08 <athena> message?
13:49:14 <armadev> athena: my impression from his last comment on #12160 was that maybe it worked?
13:49:15 <Yawning> asn: the latter
13:49:18 <nickm> athena: he edited his message to say that it did work, I think
13:49:19 <asn> ack
13:49:28 <asn> #12160 does work.
13:49:41 <asn> i spoke with the bug reporter recently and he confirmed.
13:49:41 <athena> ah!
13:49:47 <Yawning> Gotta triage that list we had, do planning, see if there's stuff we missed etc
13:49:50 <asn> he is now waiting to see if he will get an increase in traffic.
13:49:54 <athena> he went and used my "more debug output, no actual code changes" branch :)
13:49:55 <mvdan> 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 <nickm> great
13:50:12 <armadev> 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 <Yawning> armadev: mmk
13:51:31 <asn> nickm: ah also. the actual python script that will calculate the guardinses is ready for review.
13:51:36 <Yawning> 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 <Yawning> *figuring
13:52:06 <armadev> ok
13:52:20 <asn> nickm: there are two  scripts. not very complicated. i estimate 1-2 hours of review time.
13:52:37 <armadev> 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 <Yawning> 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 <Yawning> yeah
13:52:47 <asn> nickm: https://trac.torproject.org/projects/tor/ticket/9321#comment:26
13:53:32 <Yawning> 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 <nickm> asn: Could you make a needs_review ticket?  I havea hard time remembering to review non-needs_review stuff
13:53:43 <asn> nickm: ok
13:53:45 <nickm> thanks
13:53:57 <Yawning> (that's it for me)
13:53:57 <nickm> athena: so, what are you planning to work on at this point?
13:56:40 <athena> 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 <nickm> great
13:57:02 <nickm> I tagged the ones I did the patch for with nickm-patch, so I know what not to review
13:57:12 <nickm> remember to take a break from reviewing too to hack easy stuff
13:57:16 <nickm> heck knows there's a lot o fit
13:58:15 <athena> okay
13:58:38 <nickm> if you want to brainstorm any of them, I'll be around
13:58:45 <nickm> let's see.  are we up to me?
13:59:14 <Yawning> you and/or dave?
13:59:30 <nickm> 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 <armadev> 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 <nickm> I wrote two new features for trunnel.  I'm going to call it version 0.99 pretty soon
14:00:25 <nickm> I've been trying to remember to review patches too
14:00:26 <Yawning> \o/
14:00:49 <nickm> I wonder, who was going to set up a code review tool for us?
14:01:01 <nickm> ISTR somebody advocating for it hard and saying they would totally maintain it
14:01:07 <Yawning> helix I think?
14:01:15 <Yawning> was gonna look into it?
14:01:30 <Yawning> I vaguly remember similar conversations from the dev meeting
14:01:32 <dgoulet> guerrit?
14:01:42 <Yawning> yeah
14:02:38 <athena> 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 <athena> but those would have been there pre-channelization and would be trickier to fix
14:03:30 <nickm> yeah
14:03:40 <armadev> athena: pre channel was also pre multiple orports being advertised, i think
14:04:06 <armadev> 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 <armadev> limited to ipv6 i think, since that's the only other thing dir auths know how to check.
14:04:28 <armadev> s/with/will/
14:04:40 <armadev> s/without/withhold/, uh oh for arma.
14:04:45 <athena> 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 <athena> 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 <armadev> netinfo cells say the address that was tried. perhaps they do, or should, say the port too?
14:05:29 <Sebastian> I voted not-running for a significant portion of the network when my hoster broke my dirauths ipv6
14:05:36 <Sebastian> took a while for me to realize what was going on
14:05:40 <athena> yeah, ISTR helix being the big gerrit advocate too
14:06:04 <athena> armadev: i think that might be sufficient
14:06:40 <athena> i'll file a new ticket for this
14:06:51 <armadev> athena: from tor-spec.txt it looks like they currently only say an address. but it is extensible, sort of.
14:06:58 <nickm> For gerrit/other tool, I am willing to try whatever the advocate wants to maintain.
14:08:49 <armadev> 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 <armadev> (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 <armadev> more from nickm?
14:11:57 <nickm> 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 <nickm> 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 <nickm> armadev: anything up with you?
14:12:28 <nickm> wrt tor
14:12:43 <armadev> i have been playing manager / leader / whatever it's called lately
14:13:03 <armadev> things are looking good for starting (negotiations for) SponsorR this week
14:13:25 <armadev> 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 <athena> nickm: np
14:13:32 <Yawning> *looks at the cheat sheet*
14:13:51 <armadev> 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 <armadev> i have also been dabbling at trac tickets in my spare time, inamongst the business stuff.
14:14:45 <armadev> in a few days i will spend two weeks doing all-day-every-day sponsorR meetings in DC
14:15:30 <armadev> and, that's it for me, unless somebody has questions or wants more details
14:16:32 <nickm> Is there anything you're really hoping this team will do/not do in the rest of sep/oct?
14:16:55 <armadev> 1) the kist stuff, which i hear starts with the global circuit scheduler
14:17:19 <armadev> 2) a plan for hidden service performance measurement and instrumentation and so on (that's the david side)
14:17:56 <armadev> 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 <armadev> those are the main three.
14:19:47 <dgoulet> 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 <nickm> 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 <nickm> 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 <athena> not yet; have you got his contact info?
14:21:46 <nickm> armadev: can you send an email to athena and Rob suggesting that they start collaborating on KIST things?
14:21:58 <nickm> If I'm in the middle on this, it might not go as fast as it should.
14:22:15 <nickm> (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 <armadev> 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 <armadev> he believes the next step is that andrea will clean up her patch.
14:22:43 <nickm> 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 <armadev> hm. yes, i hope so. i guess one of my first questions will be why it is so big.
14:23:25 <Yawning> (what's the ticket #?)
14:25:31 <armadev> i want to know too
14:25:36 <nickm> #9296
14:25:38 <nickm> err
14:25:42 <nickm> #9262
14:25:58 <Yawning> *adds to the whiteboard of doom*
14:26:37 <armadev> 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 <armadev> 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 <nickm> like I said: sane but big.  It touches a lot of code and cleans up a fairly hefty amount of spaghetti
14:27:56 <armadev> athena: rob asks "Is there any documentation (other than the code) about the approach taken here?"
14:27:58 <nickm> have a look when you have a chance
14:28:07 <nickm> armadev: there are a bunch of comments in the code
14:29:56 <nickm> I think we've moved on from meet to chat, so...
14:29:57 <nickm> #endmeeting