13:29:38 #startmeeting 13:29:38 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 13:29:43 welcome! Who's here this morning? 13:29:49 (For the tor dev meeting) 13:29:51 * dgoulet here! 13:30:41 anyone else? Or is this one of those two-person parties? 13:30:49 3 person 13:30:55 hi teor ! 13:30:56 I am Eve 13:31:15 Hi Nick! 13:31:36 In the cryptographic sense, or that's your name? :) 13:31:50 Sorry, it was a cryptographic joke 13:31:54 np 13:32:07 So, dgoulet, want to get us started? What've you been up to? 13:32:12 sure 13:33:03 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 so a need review for #13667 would be good so we can take a decision 13:33:42 (need review == more eyes/ACK on it) 13:34:10 hm. So the current favorite proposal on that is...? 13:34:44 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 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 yes exactly so our best course of action is to make it harder as we can I guess 13:36:10 so, if we do END_REASON_DONE and drop, they have to build more circuits and do more introduction handshakes. 13:36:16 "2)" has the possible drawback of the HS having a lot of opened circ. 13:37:12 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 rehi 13:37:33 rehi Yawning ! 13:37:56 was getting food >.> 13:38:24 nickm: yeah the parallel scanning makes that solution a bit useless 13:38:27 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 ;_; 13:38:34 yeah 13:38:38 yeah 13:38:58 if people are more paranoid, they could use authenticated HSes or something 13:39:04 Yeah. For a real answer, I'd think that better access control is the answer. 13:40:01 dgoulet: anything else? Can I ask you to update the ticket? 13:40:42 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 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 nickm: hrm maybe I should work on that in a seperate branch before you pull tree.h upstream? 13:42:24 I dunno; it's pretty easy, and it doesn't hurt us if we remove it later. 13:42:29 hi meeting! 13:42:42 nickm: oh well if so, that is no problem for me 13:42:46 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 ok 13:42:49 athena: hi! 13:42:53 athena: o/ 13:42:55 * dgoulet done 13:42:57 Yawning / athena : Who would like to go next? 13:43:01 (thanks, dgoulet) 13:43:09 nickm: i just sent you that libevent patch 13:43:18 was doing that nsf thing, then back into sketch go pt land 13:43:22 great; I'll see about applying it RSN. 13:43:33 "sketch" go pt land? 13:43:35 I have a huge list of little-t tor stuff I want to do that I should get to shortly 13:43:45 well, that whole ntru thing 13:43:50 has a use case 13:43:56 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 good thing we did this, turns out the old attempt at monotonic time by a ratchet mechanism is totally broken 13:44:38 athena: Does tor-resolve need tor_gettimeofday_cached? 13:44:53 If not, define a libor_time that has the time manipulation functions 13:45:39 notice the missing static: https://gitweb.torproject.org/tor.git/blob/HEAD:/src/common/compat_libevent.c#l714 13:45:52 ok 13:46:06 owwwww 13:46:14 could you open a ticket for that, marked 025-backport ? 13:46:18 okay 13:46:43 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 but yeah we should backport 13:48:00 great 13:48:09 anything else? Plans after monotonic time is in? 13:48:35 probably that sticky-IP thing 13:48:43 #13705 13:49:02 hm... I dunno if that's actually a good idea. Did we decide it achieved anything? 13:49:57 Weren't there also concerns with burning the keys (& therefore history) if the IP did actually change? 13:50:41 well, that's the cost of saying that your IP won't change and then being wrong 13:51:25 Yes, I guess so 13:53:10 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 Do we know if this is a current attack? 13:53:26 teor: Well, servers get seized occasionally. 13:53:51 So I guess it might be worthwhile to try, if we can do it on the quick side. 13:53:58 (And recently. It would certainly supplement the manual bad relays process.) 13:54:21 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 There could be an IP pinning mechanism integrated with that too. 13:55:00 hmm 13:55:12 athena: so maybe do the relay-side of #13705 now, and the authority-side once #12498 is in? 13:56:04 nickm: hmm, okay 13:57:08 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 I think there's some pending thing somewhere; maybe two 13:57:49 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 prolly chill for now I'll come screaming if I find something scary 13:58:31 okayz 13:58:36 nickm: okay, sure 13:58:52 teor: So, thanks for filling me in on #13787 / #13718 . 13:59:35 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 No worries. Working on #13718 now. 13:59:55 I had them open for unit tests. 14:00:02 Did we want to backport them as well? 14:00:04 ah, ok. 14:00:06 Not sure. 14:00:17 Well, there's two reasons 14:00:20 I think it's conceivable that backports are a good idea. and conceivable that they aren't. :) 14:01:09 wrt #13718: The fix you propose makes sense to me, assuming it does fix it 14:01:38 If we backport #13718, we may not need to backport parts of #13161 14:02:05 Particularly the TestingDirAuthVoteExit option 14:02:39 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 I think that #13718 may resolve (some of) the issues we were using TestingDirAuthVoteExit to solve in #13161 14:04:22 but let's make sure that this fixes master first. 14:04:34 Yes, then we can decide which goes where 14:04:37 then we can figure out what to backport 14:04:38 yeah 14:07:32 so, hm. next is me. 14:07:56 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 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 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 I'm hoping I can write up a quick integration testing plan draft before the next meeting. 14:09:43 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 And just as a reminder, the freeze needs to be for features *and* nontrivial non-regression bugfixes. 14:10:41 And if there's anything big that needs to happen, we should try to get it done in December. 14:11:12 So maybe we need some way to indicate our top priority tickets to get to in Nov/Dec/Jan. 14:12:17 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 sure 14:12:33 or am I overthinking? 14:12:46 dunno if that's neccecary though 14:12:50 (google spreadsheet? Is there a non-google shared spreadsheet tool?) 14:12:53 Well, hm. 14:13:13 How else could we try to make sure we're not spending time on less-important stuff? 14:13:21 hmm 14:14:31 The points system in trac? (How does that work, anyway?) 14:15:04 no idea 14:15:09 and I don't think it supports multiparty results. 14:15:33 Ah, no votes. Oh well. 14:16:47 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 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 Unless one of them is simply a suggestion 14:18:31 true 14:18:44 In which case, we should be honest and call it that 14:19:01 "must-fix whishlist" *and* a freeze deadline :) 14:20:38 https://docs.google.com/spreadsheets/d/1_fsXOPmbqBuoJD1ufVQO0Ehy21uJyE5TWqdQWkfRxVo/edit?usp=sharing 14:20:56 In the tradition of RFCs, a SHOULD fix wishlist? :-) 14:21:23 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 https://docs.google.com/spreadsheets/d/1_fsXOPmbqBuoJD1ufVQO0Ehy21uJyE5TWqdQWkfRxVo/edit?usp=sharing 14:21:36 MUST (BUT WE KNOW YOU WON'T) 14:21:37 that second link is supposedly the editable one 14:21:52 Sorry about the google 14:22:01 don't put any sekrit stuff here. 14:22:15 I'll abstain, as I don't have the time 14:22:18 and if you'd rather have an ods, ask somebody to export the sheet and copy something in 14:22:22 teor: ok 14:26:21 anything else for this week's meeting? 14:28:18 (on nickm's order :) 14:28:20 #endmeeting 14:28:29 *baf* 14:28:31 oh ahha 14:28:35 In that case, I declare us done. 14:28:38 #endmeeting