13:31:52 <nickm> #startmeeting
13:31:52 <MeetBot> Meeting started Wed Jun  3 13:31:52 2015 UTC.  The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:31:52 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:32:19 <nickm> hi all!  It's another core tor dev meeting.  I've seen teor and armadev and athena and asn and dgoulet!
13:32:26 <nickm> Anybody else around?
13:32:31 <nickm> (for the meeting?)
13:32:33 <Yawning> hi
13:32:37 <nickm> hi Yawning !
13:32:44 <nickm> Let's start with quick status reports.
13:33:01 <Yawning> hm
13:33:08 <athena> hi meeting!
13:33:15 <nickm> hi athena !
13:34:39 <nickm> I guess I'll go first
13:35:04 <nickm> last week I managed to merge the ed25519 patch, part 1.  That was awesome, but then ate the next couple of days by patching things and feeding it through coverity
13:35:17 <nickm> also we're back to working with openssl 1.1, I think
13:35:40 <nickm> next up for me is writing more proposals, working on guard algorithms, and trying to get #15055 finished....
13:35:54 <nickm> ..and begging for review on #13642 ...
13:36:08 <nickm> ...but I'm going to be distracted Thu->Sat with a meeting in Boston.
13:36:13 <nickm> And that's it for me.
13:36:14 <nickm> who's next?
13:36:23 <athena> status report: mostly figuring out #4581 right now; i can see where to put the test and how to implement it, but two uncertainties: how to tell really-anonymized circuits producing begindir cells from the one-hop tunneled ones, and whether to rate-limit the really-anonymized ones all together in one bucket or per circuit
13:37:26 <nickm> you can get an approximate guess as to what's really-anonymized by seeing if you recognize the circuit as coming from somebody in your consensus.  It can give you the wrong answer, but it's right-ish.
13:38:13 <nickm> as for whether to treat them differently: It's a "remain functional in the face of DoS" problem.  So I'd say, take a guess which solution might have that property. :)
13:38:54 <Yawning> (guess I can go?)
13:39:03 <nickm> go for it!
13:39:16 <Yawning> I helped nickm slay the remaining OpenSSL 1.1 demons
13:39:29 <Yawning> hopefully we won't need to touch that code much in the near term future
13:39:40 <Yawning> (I think we're in a lot better shape in master)
13:39:52 <Yawning> I got a huge code drop from Blanu that I need to review (Ptland, Dust yay)
13:39:55 <athena> nickm: okay, thanks
13:40:05 <Yawning> so that might keep me from tor-ish stuff but, it's a new pt
13:40:10 <asn> nice!
13:40:11 <nickm> cool!
13:40:12 <Yawning> which is always exciting
13:40:15 <nickm> what's special about it?
13:40:35 <Yawning> a more systematic approach was used to determine "stuff that gets past dpi boxes"
13:40:44 <Yawning> in theory it supports a bunch of nifty features as well
13:40:54 <Yawning> but I need to improve my framework code for that
13:41:08 <Yawning> (a more cynical take on what's special is, it's part of sponsor T)
13:41:44 <Yawning> past that, still having random EMEATSPACE intrusions into my quality hacking time, and I'm trying to figure out just how fast I should be running to sumewhere in europe
13:41:55 <Yawning> that's it for me :P
13:42:03 <asn> i can go next
13:42:06 <asn> not much to report
13:42:15 <asn> a few sponsorr stufff. a few SoP stuff.
13:42:26 <asn> i was also quite close to getting guardfraction deployed
13:42:37 <asn> but a wild bug appeared !
13:42:52 <asn> it is now filed as #16255 and i think i identified it
13:42:57 <asn> unfortunately, it has to do with bandwidth weights
13:43:04 <asn> and testing these things on chutney is a PITA
13:43:05 <nickm> ow :(
13:43:20 <nickm> are there specific chutney improvements that would help?
13:43:35 <asn> for some rason, latest chutney with latest tor, gives me a network with all relays having Bandwidth=0
13:43:40 <asn> i think that's because htere is no measured bw
13:43:45 <asn> and hence the self-reported one is used
13:43:50 <asn> and because those testing relays don't see much use
13:43:53 <asn> they just report 0
13:44:13 <asn> i have a hack
13:44:24 <nickm> ok.  is it just "Run a constant load through it"?
13:44:38 <asn> which goes to  rep_hist_bandwidth_assess()
13:44:57 <asn> and if read and write bandwidth is 0, it reports a random number.
13:45:04 <asn> instead
13:45:07 <asn> that makes it work kind of
13:45:30 <teor> asn: I have a chutney patch in the works that will allow verify to run continuous loads
13:45:35 <asn> which allows dirauths to calculate total bandwidht weights and Wgg, etc. weights
13:45:42 <asn> the other problem with #16255
13:46:03 <asn> is that clients actually validate the total bandwidth weights reported by the dirauths
13:46:20 <asn> and this is problem if the clients don't yet use guardfractions, but the dirauths do
13:46:28 <asn> because in that case, the clients complain that the bw weights don';t make sense
13:46:41 <asn> i'm not sure what to do in this case.
13:46:50 <asn> i need to read a bit more on how these Wgg weight calculations work, and think more about deployment
13:47:03 <armadev> make current clients no longer complain, then wait a very long time? (is there a better plan?)
13:47:05 <asn> this was an unexpected deployment hurdle, and I suck.
13:47:18 <asn> armadev: not sure yet about better plan.
13:47:19 <nickm> hey, everybody breaks stuff sometimes
13:47:40 <asn> and that's that from guardfraction land. the python script actually works quite well
13:47:43 <armadev> on second thought, maybe the very long time doesn't have to be that long. "my client is giving me warnings" "then upgrade".
13:47:53 <nickm> assuming it's just warnings, yeah.
13:48:01 <asn> will try to think of something in the nxt days
13:48:12 <asn> today i'm mainly looking at guard stuff
13:48:15 <Yawning> (I ave something for the discussion phase)
13:48:21 <asn> i also posted a faux algorithm in the pad just to get this going
13:48:28 <asn> i'm done. next please :)
13:48:35 * dgoulet can go next
13:49:01 <dgoulet> Nick's ed25519 patch review last week. Lots of work on #4862 which incidently fixed other tickets. Reported an HS issue detailed in #16260 for which I would love your feedback on what to do :).
13:49:06 <dgoulet> Opened #16274 yesterday because of //paste.debian.net/hidden/cf670e06/ on my relay but turns out it's not the full issue so this morning I've been chasing the issue...
13:49:14 <dgoulet> Next on my radar is to review #13642 and jump a bit on non little-t tor SponsorR stuff and SoP meeting today with DonnchaC and asn.
13:49:16 * dgoulet done
13:49:27 * teor can go
13:49:59 <nickm> go ahead
13:50:14 <teor> I reviewed code using clang sanitizers and submitted #16115
13:50:26 <teor> A series of minor fixes since 0.2.7.1-alpha
13:50:51 <nickm> (whoops; I forgot to mark that fixed when I merged it)
13:51:18 <teor> Since Apple has let OS X OpenSSL rot at 0.9.8, I added build instructions to the wiki at https://trac.torproject.org/projects/tor/wiki/doc/MacBuild
13:51:28 <teor> for OpenSSL 1.? on OS X
13:51:53 <teor> And updated the corresponding launchd instructions to deprecate Vidalia in favour of nyx
13:52:03 <teor> https://trac.torproject.org/projects/tor/wiki/doc/MacRunOnBoot
13:52:42 <teor> Next on my list is to submit a branch for #15817, then tests for #14882
13:53:08 <teor> And the chutney stuff in #14175
13:53:11 * teor is done
13:53:24 * armadev can go next
13:53:34 <armadev> I've alas not had much time to wear my tor dev hat, due to other hats like exec dir
13:53:41 <armadev> I've paid attention to the recent hsdir attacks, and encouraged dgoulet to work with others to build health monitoring and attack detection infrastructure
13:53:45 <armadev> Also, it's becoming clear that the !reject approach to cutting out bad relays d
13:53:45 <armadev> oesn't scale, and we need something more agile (something that involves fewer d
13:53:46 <armadev> ir auths)
13:53:53 <armadev> there, done.
13:54:04 <Yawning> (is that all the peeps?)
13:54:17 <Yawning> because arma's stuff leads into what I want to bring up
13:54:26 <nickm> Let's move on to discussion, and if there's another person, they can do their status in parallel?
13:54:34 <Yawning> ok
13:54:35 <dgoulet> +1
13:54:58 <Yawning> my discussion is, I want to fasttrack #8243 and #15963 for a 0.2.6.x release Soon
13:55:19 <Yawning> because, yeah, assholes, sybil attacks, HSDir, etc
13:55:20 <armadev> can you summarize what we're planning to do for #8243?
13:55:51 <Yawning> 8243 makes HSDirs require Stable
13:56:15 <armadev> hot.
13:56:20 <dgoulet> +1 on this one
13:56:29 <Yawning> I think our bw scanner stuff has an extra layer of ducttape/string/chewing gum
13:56:35 <Yawning> so requiring Fast might be reasonable as well
13:56:44 <nickm> I'm fine with both of those .  What's the status now; who's reviewed so far, etc?
13:56:56 <Yawning> 2nd one needs a patch I think
13:57:01 <asn> i could get behind the Fast requirement. especially if you tell me how many relays this extra constraint rules out.
13:57:03 <armadev> requiring Fast (#15963) won't work until more dir auths have bwauths attached to them (#12877)
13:57:22 <asn> i have reviewed dgoulet's current #8241 branch. it needs some minor mods.
13:57:24 <Yawning> ok, so Fast we can backbruner for now
13:57:25 <armadev> that is, currently a majority of dir auths vote Fast for a relay based on its advertised capacity.
13:57:37 <asn> because it currently keeps both the Stable requirement and the old ad-hoc uptime requirement. my suggestion is to only keep the Stable requrieemnt.
13:57:47 <Yawning> hm
13:57:55 <Yawning> whynotboth.jpg?
13:58:07 <armadev> asn: how about something similar to guard, where we demand "it appeared at least a certain amount of time ago"?
13:58:09 <Yawning> I think we all glanced through dgoulet's branch for Stable at one point or another
13:58:12 <armadev> or is that redundant with Stable in practice
13:58:17 <Yawning> since I see comments from nick, asn, and myself
13:58:51 <Yawning> my rationale for a 0.2.6.x release here is, we should do one for OpenSSL, sandboxing, etc anyway
13:58:56 <asn> armadev: not entirely redundant. we should see the minimum amount of time required to get the Stable flag currently.
13:58:57 <Yawning> and it's the version that most dirauths run
13:59:14 <asn> armadev: to see what kind of restriction we impose just by requiring Stable flag. and see if we are happy with that.
13:59:17 <Yawning> so just pushing anti-sybil defenses to master doesn't buy us more secuirty in the short term
13:59:25 <nickm> if we're merging the openssl 1.1 ssl fixes to stable now, I'd like more testing.
14:00:00 <nickm> I think that telling people "If you want to run with OpenSSL 1.1, run Tor 0.2.7" is reasonable for a little while longer.
14:00:02 <Yawning> nickm: maybe that can bake for another cycle (doa  0.2.7.x alpha first, then if it doesn't blow up, merge?)
14:00:03 <nickm> Unless I'm missing something
14:00:06 <nickm> yeah
14:00:09 <Yawning> ok
14:00:19 <Yawning> sandboxing alone is probably compelling enough here anyway
14:00:24 <armadev> in terms of release methodology, since this change is designed only for dir auths, we should test it on some deployed dir auths before putting out a stable release that does it. whether that means an alpha release, or just some testing, i'm ok either way.
14:00:38 <nickm> ok
14:00:41 <Yawning> ok
14:00:52 <nickm> so what do I merge here?
14:00:55 <Yawning> sorry if I stepped on anyones toes, or if I'm being overly persistent about this
14:01:10 <Yawning> I think patch needs a few tewaks, then we'll poke you
14:01:12 <armadev> yawning: no, i think cutting down the number of churny hsdirs is good.
14:01:25 <dgoulet> ^!
14:01:25 <nickm> no worries. our dev methodoology requires that people be loud sometimes :)
14:01:47 <Yawning> but I really want this to happen, (and we can say, "look, we're making it harder to be HSDirs while we figure out 224" to the sky-is-falling cround)
14:02:03 <armadev> sure would be nice to have some plans for #8244 too
14:02:15 <nickm> armadev: we do; see proposal 224
14:02:16 <Yawning> even though I don't think that presentation really exposed anything new
14:02:28 <Yawning> they had some nice tools for mounting an attack that's been known for a while
14:02:37 <Yawning> and just becoming an HSDir doesn't win much
14:02:44 <armadev> yawning: right. from looking at the slides for the talk, it looked like a good talk, which taught people about the two open tickets. done.
14:02:49 <Yawning> (depending on what you think about popularity metrics)
14:02:56 <Yawning> armadev: yah
14:03:02 <Yawning> someone should comment
14:03:08 <dgoulet> ok so who is taking on to do the modifications needed on #8243?
14:03:14 <Yawning> grats :P
14:03:29 <Yawning> unless you're busy
14:03:40 <dgoulet> I can do it but we just need to agree on the latest comment :)
14:03:45 <asn> i think the main question that needs to be answered now is
14:03:53 <asn> - What's the minimum uptime required to get the Stable flag?
14:03:57 <asn> and see if we are satisfied by the answer.
14:04:09 <Yawning> so I'll lock you and ans in a conference room for a bit?
14:04:10 <asn> If we are not, we might as well keep the old "simple uptime" requirement as well.
14:04:11 <Yawning> :P
14:04:14 <Yawning> *asn
14:04:16 <asn> I can look this up tomorrow.
14:04:25 <asn> I guess I can take over this ticket?
14:04:28 <Yawning> lemmie know if help is required
14:04:29 <armadev> asn: why not keep both anyway? in case the answer changes later?
14:04:39 <dgoulet> "Stable" -- A router is 'Stable' if it is active, and either its Weighted
14:04:40 <dgoulet> MTBF is at least the median for known active routers or its Weighted MTBF
14:04:40 <dgoulet> corresponds to at least 7 days.
14:05:06 <asn> aha
14:05:09 <asn> let me check the first condition
14:05:10 <Yawning> http://knowyourmeme.com/memes/why-not-both-why-dont-we-have-both
14:05:17 <asn> eehmm why not both
14:05:38 <asn> i think i decided to not have both so that we ditch all the various ways of judging uptime, and only keep the smart ones.
14:05:39 <dgoulet> you can have Stable but not up for the last 96 hours so I agree that both sounds reasonable
14:05:44 <asn> but maybe the silly ones are not that silly.
14:06:18 <asn> flag-thresholds stable-uptime=907597 stable-mtbf=2137224
14:06:51 <asn> 907597 seconds is 252 hours
14:07:10 <asn> but yeah, I think keeping both might be a good idea at this point.
14:07:25 <asn> dum dum dum
14:07:36 <Yawning> wait, if a bunch of HSDirs are voting fast based on advertised instead of actual
14:07:42 <Yawning> requiring Fast doesn't hurt us right?
14:07:46 <Yawning> err
14:07:50 <Yawning> if DirAuths are...
14:07:51 <armadev> yawning: correct.
14:08:03 <Yawning> and the moment we enable teh scanner code, we'll just kick out a bunch of bad?
14:08:08 <dgoulet> https://metrics.torproject.org/relayflags.html?graph=relayflags&start=2015-03-05&end=2015-06-03&flag=Running&flag=Exit&flag=Fast&flag=Guard&flag=Stable&flag=HSDir
14:08:13 <armadev> enable enough scanners you mean. yes.
14:08:33 <Yawning> worht doing then probably?
14:08:34 <asn> dirserv_thinks_router_is_unreliable() is relatd func
14:08:48 <Yawning> the code changes here should be trivial
14:09:16 <asn> in the case where we keep both checks, the patch is ready
14:09:32 <dgoulet> asn: except for the MinUptimeHidServDirectoryV2 question
14:09:34 <armadev> yawning: see also #11327
14:09:39 <dgoulet> oh wait we keep both, nvm
14:09:42 <asn> dgoulet: well that's the check we keep
14:10:31 <Yawning> hmm
14:10:32 <dgoulet> (I guess prop243 should be modified also)
14:10:43 <asn> yes
14:10:46 <Yawning> dgoulet: think you can add teh Fast check?
14:10:52 <Yawning> (if we're agreeing it's good?)
14:11:13 <Yawning> it's probably just a one line addition to the patch in the same area
14:11:16 <dgoulet> well why not, I can pile on patches on my stack :D
14:11:29 <asn> i can take over #8241
14:11:30 <asn> i can take over #8243
14:11:30 <armadev> yawning: yep. just make sure you look at Fast after you've computed it, not before
14:11:31 <asn> sorry
14:11:46 <dgoulet> asn: ok so 8243 is not yours :)
14:11:51 <dgoulet> now*
14:11:54 <asn> ok
14:12:07 <Yawning> I'll link the fast thing to there
14:12:14 <asn> ok
14:12:21 <asn> also mention that we decided to kee pboth checks
14:12:28 <asn> dgoulet: do you have any tips for tsting that branch?
14:13:43 <dgoulet> asn: hrm... with chutney I *think* all nodes get all flags... hrmmm
14:14:00 <dgoulet> I remember testing this, just don,t remember how....
14:14:57 <Yawning> *bolts the Fast ticket on as a child*
14:15:04 <Yawning> there
14:15:10 <asn> ok
14:15:23 <asn> done with #8243 discussion? will try to look into it soon.
14:15:36 <Yawning> think so, >3
14:15:40 <Yawning> err <3
14:15:49 <armadev> Jun 03 09:55:02.394 [warn] Unable to store signatures posted by 88.80.185.36: Mismatched digest.
14:16:31 <asn> nickm: what's next?
14:16:47 <armadev> fun. it looks like a stranger is giving me an attempted signature on the consensus. which i'm refusing only because it isn't a signature on what i think the consensus is. otherwise i'd, i guess, add that signature to my consensus. even though i don't know who it is.
14:16:50 <Yawning> asn: yawning needs food badly
14:17:29 <Yawning> (am I showing my age ther?)
14:18:56 <asn> armadev: hmm
14:19:14 <dgoulet> do we have a guard discussion next?
14:19:23 <asn> armadev: we no check that consensus signature comes from the list of dirauths, eh?
14:19:49 <asn> would the clients then check it, and be like "shit this sig here i don't recognize. better trash the whole consensus"?
14:20:14 <nickm> asn: we should figure out more about guards.
14:20:18 <asn> ok
14:20:18 <nickm> I think
14:20:21 <nickm> (sorry, was afk)
14:20:22 <asn> let's do some guards
14:20:28 <Yawning> (can I has food?)
14:20:31 <asn> i posted some super strawman algos in pad
14:20:32 <nickm> of course
14:20:33 <asn> Yawning: yes
14:20:35 <nickm> shall we endmeeting though?
14:20:41 <nickm> #endmeeting