13:29:38 <nickm> #startmeeting
13:29:38 <MeetBot> Meeting started Wed Nov 19 13:29:38 2014 UTC.  The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:29:38 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:29:43 <nickm> welcome!  Who's here this morning?
13:29:49 <nickm> (For the tor dev meeting)
13:29:51 * dgoulet here!
13:30:41 <nickm> anyone else?  Or is this one of those two-person parties?
13:30:49 <teor> 3 person
13:30:55 <nickm> hi teor !
13:30:56 <teor> I am Eve
13:31:15 <teor> Hi Nick!
13:31:36 <nickm> In the cryptographic sense, or that's your name? :)
13:31:50 <teor> Sorry, it was a cryptographic joke
13:31:54 <nickm> np
13:32:07 <nickm> So, dgoulet, want to get us started?  What've you been up to?
13:32:12 <dgoulet> sure
13:33:03 <dgoulet> so apart from being in Boston with nickm spelunking Tor code base and ecosystem, measuring hs with chutney, reviewing hs stats proposal (soon public to tor-dev)
13:33:28 <dgoulet> so a need review for #13667 would be good so we can take a decision
13:33:42 <dgoulet> (need review == more eyes/ACK on it)
13:34:10 <nickm> hm.  So the current favorite proposal on that is...?
13:34:44 <dgoulet> nickm: comes down to two choices 1) END_REASON_DONE and drop the circuit or 2) Insert random delays and finally drop at some point
13:35:03 <nickm> Ultimately, there is no solution to #13667.  If a client can try to connect to a port, and if that client can differentiate success from failure, and the scanner knows everything that the client does, then ultimately the scanner can scan ports.
13:35:23 <dgoulet> yes exactly so our best course of action is to make it harder as we can I guess
13:36:10 <nickm> so, if we do END_REASON_DONE and drop, they have to build more circuits and do more introduction handshakes.
13:36:16 <dgoulet> "2)" has the possible drawback of the HS having a lot of opened circ.
13:37:12 <nickm> If we  do "insert random delays and finally drop at some point", they have to open just as many circuits, maybe, and their programming job gets a little harder, but they can do multiple queries in parallel, so ultimately we're not slowing them down much
13:37:24 <Yawning> rehi
13:37:33 <nickm> rehi Yawning !
13:37:56 <Yawning> was getting food >.>
13:38:24 <dgoulet> nickm: yeah the parallel scanning makes that solution a bit useless
13:38:27 <nickm> I think that "drop and kill the circuit" is probably a reasonable thing to do, in terms of trade-off between how much it helps and how hard it is.
13:38:28 <Yawning> ;_;
13:38:34 <Yawning> yeah
13:38:38 <dgoulet> yeah
13:38:58 <Yawning> if people are more paranoid, they could use authenticated HSes or something
13:39:04 <nickm> Yeah. For a real answer, I'd think that better access control is the answer.
13:40:01 <nickm> dgoulet: anything else?  Can I ask you to update the ticket?
13:40:42 <dgoulet> nickm: yup I'll update the ticket with that discussion, last thing I have on mylist is #13739, I feel comfortable with red/black tree here and also think it will be a good improvement
13:41:14 <nickm> ok.  Want me to pull in the tree.h stuff from freebsd for you?  I've done that before, and know some of the failure modes.
13:41:45 <dgoulet> nickm: hrm maybe I should work on that in a seperate branch before you pull tree.h upstream?
13:42:24 <nickm> I dunno; it's pretty easy, and it doesn't hurt us if we remove it later.
13:42:29 <athena> hi meeting!
13:42:42 <dgoulet> nickm: oh well if so, that is no problem for me
13:42:46 <nickm> dgoulet: One reason I would like it in is that the names ned to be mangled, or they'll conflict with system headers
13:42:49 <nickm> ok
13:42:49 <nickm> athena: hi!
13:42:53 <dgoulet> athena: o/
13:42:55 * dgoulet done
13:42:57 <nickm> Yawning / athena : Who would like to go next?
13:43:01 <nickm> (thanks, dgoulet)
13:43:09 <athena> nickm: i just sent you that libevent patch
13:43:18 <Yawning> was doing that nsf thing, then back into sketch go pt land
13:43:22 <nickm> great; I'll see about applying it RSN.
13:43:33 <nickm> "sketch" go pt land?
13:43:35 <Yawning> I have a huge list of little-t tor stuff I want to do that I should get to shortly
13:43:45 <Yawning> well, that whole ntru thing
13:43:50 <Yawning> has a use case
13:43:56 <athena> the to branch using it is almost ready to go modulo me figuring what to do about needing to call tor_gettimeofday_cached() from util.c, but that being in compat_libevent.c and tor-resolve not linking it
13:44:24 <athena> good thing we did this, turns out the old attempt at monotonic time by a ratchet mechanism is totally broken
13:44:38 <nickm> athena: Does tor-resolve need tor_gettimeofday_cached?
13:44:53 <nickm> If not, define a libor_time that has the time manipulation functions
13:45:39 <athena> notice the missing static: https://gitweb.torproject.org/tor.git/blob/HEAD:/src/common/compat_libevent.c#l714
13:45:52 <athena> ok
13:46:06 <nickm> owwwww
13:46:14 <nickm> could you open a ticket for that, marked 025-backport ?
13:46:18 <athena> okay
13:46:43 <athena> in the new branch that function is going to go away in favor of the new monotonic time mechanism that preferentially calls libevent
13:46:47 <athena> but yeah we should backport
13:48:00 <nickm> great
13:48:09 <nickm> anything else? Plans after monotonic time is in?
13:48:35 <athena> probably that sticky-IP thing
13:48:43 <athena> #13705
13:49:02 <nickm> hm... I dunno if that's actually a good idea.  Did we decide it achieved anything?
13:49:57 <teor> Weren't there also concerns with burning the keys (& therefore history) if the IP did actually change?
13:50:41 <nickm> well, that's the cost of saying that your IP won't change and then being wrong
13:51:25 <teor> Yes, I guess so
13:53:10 <nickm> athena: so, I guess I wouldn't mind doing that, though I'm not 100% sure it's the best use of your time.
13:53:14 <teor> Do we know if this is a current attack?
13:53:26 <nickm> teor: Well, servers get seized occasionally.
13:53:51 <nickm> So I guess it might be worthwhile to try, if we can do it on the quick side.
13:53:58 <teor> (And recently. It would certainly supplement the manual bad relays process.)
13:54:21 <nickm> athena: Actually, here's a thought.  My #12498 work includes a key-pinning mechanism to keep Ed25519 keys tied to RSA keys by the authorities.
13:54:32 <nickm> There could be an IP pinning mechanism integrated with that too.
13:55:00 <Yawning> hmm
13:55:12 <nickm> athena: so maybe do the relay-side of #13705 now, and the authority-side once #12498 is in?
13:56:04 <athena> nickm: hmm, okay
13:57:08 <nickm> athena: also, could I ask you to take a pass through the needs_revision and needs_review tickets for patches you wrote, in case there's code for you to fix or questions to answer?
13:57:18 <nickm> I think there's some pending thing somewhere; maybe two
13:57:49 <nickm> Yawning: do you want feedback/ideas about any of the tor stuff you're going to be working on, or should I just chill out and wait to see what happens? :)
13:58:13 <Yawning> prolly chill for now I'll come screaming if I find something scary
13:58:31 <nickm> okayz
13:58:36 <athena> nickm: okay, sure
13:58:52 <nickm> teor: So, thanks for filling me in on #13787 / #13718 .
13:59:35 <nickm> Am I right that #13161 and #13163 are fixed in master, and they're only open because they're awaiting backport evaluation for 0.2.5?
13:59:37 <teor> No worries. Working on #13718 now.
13:59:55 <teor> I had them open for unit tests.
14:00:02 <teor> Did we want to backport them as well?
14:00:04 <nickm> ah, ok.
14:00:06 <nickm> Not sure.
14:00:17 <teor> Well, there's two reasons
14:00:20 <nickm> I think it's conceivable that backports are a good idea.  and conceivable that they aren't. :)
14:01:09 <nickm> wrt #13718: The fix you propose makes sense to me, assuming it does fix it
14:01:38 <teor> If we backport #13718, we may not need to backport parts of #13161
14:02:05 <teor> Particularly the TestingDirAuthVoteExit option
14:02:39 <nickm> Hm.  I want to avoid unnecessary backports, but it's pretty useful to have Tor stable running in Chutney, so that we can test mixed networks
14:04:20 <teor> I think that #13718 may resolve (some of) the issues we were using TestingDirAuthVoteExit to solve in #13161
14:04:22 <nickm> but let's make sure that this fixes master first.
14:04:34 <teor> Yes, then we can decide which goes where
14:04:37 <nickm> then we can figure out what to  backport
14:04:38 <nickm> yeah
14:07:32 <nickm> so, hm.  next is me.
14:07:56 <nickm> First thing is that I'm noticing that I have a bunch of patches piling up in needs_review and needs_revision again.  I need folks to check them out when they have a chance.
14:08:23 <nickm> I've used the nickm-patch keyword to indicate "nickm wrote or substantially rewrote this patch" so I can identify stuff for me to review or revise.
14:09:04 <nickm> Second thing is, more and more progress on 0.2.6.  So that's good.  I'm doing #12498. (Still.  It's big!) And applying new testing ideas as I do it.
14:09:21 <nickm> I'm hoping I can write up a quick integration testing plan draft before the next meeting.
14:09:43 <nickm> Hm, what else?  We triaged some tickets out of 0.2.6, but I suspect we'll need to triage or prioritize more if we're going to freeze in January.
14:10:18 <nickm> And just as a reminder, the freeze needs to be for features *and* nontrivial non-regression bugfixes.
14:10:41 <nickm> And if there's anything big that needs to happen, we should try to get it done in December.
14:11:12 <nickm> So maybe we need some way to indicate our top priority tickets to get to in Nov/Dec/Jan.
14:12:17 <nickm> Hm.  What if I did a dump of the tickets currently in 0.2.6, and asked everybody who cares to rate them 1..100 in difficulty and 1..100 in importance in a text file.  Would people like to do that?
14:12:30 <Yawning> sure
14:12:33 <nickm> or am I overthinking?
14:12:46 <Yawning> dunno if that's neccecary though
14:12:50 <nickm> (google spreadsheet?  Is there a non-google shared spreadsheet tool?)
14:12:53 <nickm> Well, hm.
14:13:13 <nickm> How else could we try to make sure we're not spending time on less-important stuff?
14:13:21 <Yawning> hmm
14:14:31 <teor> The points system in trac? (How does that work, anyway?)
14:15:04 <nickm> no idea
14:15:09 <nickm> and I don't think it supports multiparty results.
14:15:33 <teor> Ah, no votes. Oh well.
14:16:47 <dgoulet> can we triage bug and just build a list of "This has to be fixed before release" and "This can wait after"... and go from there?
14:17:48 <nickm> Well, the hard part about that is that we've done it in the past.... but we can't have both a "must-fix" list *and* a freeze deadline.
14:18:21 <teor> Unless one of them is simply a suggestion
14:18:31 <nickm> true
14:18:44 <teor> In which case, we should be honest and call it that
14:19:01 <dgoulet> "must-fix whishlist" *and* a freeze deadline :)
14:20:38 <nickm> https://docs.google.com/spreadsheets/d/1_fsXOPmbqBuoJD1ufVQO0Ehy21uJyE5TWqdQWkfRxVo/edit?usp=sharing
14:20:56 <teor> In the tradition of RFCs, a SHOULD fix wishlist? :-)
14:21:23 <nickm> I'm going to be doing this in terms of "priority" and "hardness" on a 1..100 scale; everybody else should add columns that work however they want.  Let's plan to get this sorted out by Friday morning?
14:21:30 <nickm> https://docs.google.com/spreadsheets/d/1_fsXOPmbqBuoJD1ufVQO0Ehy21uJyE5TWqdQWkfRxVo/edit?usp=sharing
14:21:36 <Yawning> MUST (BUT WE KNOW YOU WON'T)
14:21:37 <nickm> that second link is supposedly the editable one
14:21:52 <nickm> Sorry about the google
14:22:01 <nickm> don't put any sekrit stuff here.
14:22:15 <teor> I'll abstain, as I don't have the time
14:22:18 <nickm> and if you'd rather have an ods, ask somebody to export the sheet and copy something in
14:22:22 <nickm> teor: ok
14:26:21 <nickm> anything else for this week's meeting?
14:28:18 <dgoulet> (on nickm's order :)
14:28:20 <dgoulet> #endmeeting
14:28:29 <Yawning> *baf*
14:28:31 <dgoulet> oh ahha
14:28:35 <nickm> In that case, I declare us done.
14:28:38 <nickm> #endmeeting