17:00:53 #startmeeting weekly network team meeting 17:00:53 Meeting started Mon Nov 28 17:00:53 2016 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:53 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:00:55 hello! 17:00:59 hello! 17:01:02 oi 17:01:06 (need some more time for my status report) 17:01:18 my name is nick. I am a mammal. I am totally sweet. My purpose is to flip out and hack things. 17:01:23 Welcome, everybodY! 17:01:34 hi :) 17:01:42 my status should be pretty short: 17:01:53 * I booked lodging for RWC+HACS. 17:01:57 * I had thanksgiving 17:02:01 * I hacked prop#271 stuff 17:02:22 The prop#271 stuff is mainly done; I'm putting bridge support together today. 17:02:43 It's being just a little bit tricky. But I believe! 17:02:50 ! 17:02:51 :) 17:03:32 On MTW this week, I will finish prop271 and write up our status, making it clear that just because there is more stuff to do about guards, does not mean that we are missing our delivery goals. 17:03:54 On ThF this week, I will see what else has piled up for me, and try to make the pile smaller 17:04:13 That's all from me! 17:04:41 i can go next: 17:04:52 yay! 17:04:54 Hello, during previous week I mainly worked on finalizing my prop224 client 17:04:54 auth torspec branch. This latest branch is much closer to being final. Given no 17:04:54 additional feedback, I plan to merge this to torspec soon and start planning 17:04:54 for the implementation. I also helped around volunteers with some coding 17:04:54 projects, and I also did some thanksgiving. This week I'm meeting with Roger 17:04:57 and David, where I plan to discuss various hidden service things. I'm also 17:04:59 meeting with Aaron Johnson in Princeton, and with Chelsea in new york, so lots 17:05:02 of collaborative stuff. 17:05:32 asn: when with aaron? 17:05:37 tomorrow afternoon 17:05:49 he is coming to pricneton 17:06:03 i'm also taking a look at the guard project right now.. ooof lots of things to refit in my head! 17:06:10 (im here I need to feed teh cat real quick or the meeting will be non stop meowing) 17:06:21 i will need to take 3-4 dedicated guard days to review the branch. 17:06:54 asn: if you wanted to wait till Thursday or so to even look at the branch, that would be justified 17:07:19 i can do that 17:07:34 Thanks 17:07:44 I'll put it on gitlab when I'm done hacking it 17:07:54 sorry it's so big; at least it's mostly clean, I think 17:08:02 i will spend 4 hours on a bus on friday, so perhaps that could be a good time to do review. 17:08:22 sounds great 17:09:11 ok hi 17:09:38 hi! 17:09:59 * isabela could go next 17:10:28 anybody! 17:10:31 ok 17:10:32 i go 17:10:40 is short: 17:10:43 My plan for this week is to prepare invoice for sponsorU and end of project stuff - which involves the wiki update i keep talking about and haven't got a chance to do yet. 17:10:51 I also plan on reviewing headcount for network team so shari can plan 2017 budget (by reviewing i mean to look at proposals we submitted and make sure new hires == number of developers needed for those proposals) 17:10:55 done 17:11:25 should I go? 17:11:29 sure 17:11:31 sure! 17:11:38 I worked on the sandbox 17:11:47 I will continue to work on the sandbox 17:12:02 the sandbox grew a large portion of a dynamic linker 17:12:07 seems to wokr 17:12:10 next 17:12:18 oh also I need ot catch on on administravia 17:12:20 awesome / yikes 17:12:21 * dgoulet can go 17:12:51 ok I'll start 17:12:52 (yeah, code is awesome, administravia is scary) 17:12:55 Last week was pairing with chelseakomlo here. We worked on prop224 service side which out of it got this torrc option thread on tor-dev@ that I will reboot with a summary of all the things discussed so we can focus on coming up with a solution we want. 17:12:58 Tiny bit of ticket work unfortunately... I'll do more this week but note that I'll be at Sponsor R meeting for the week (leaving in couple hours). 17:13:01 Also, my talk at McGill U. went great! Thanks to chelseakomlo for the help there! And bad relays are still a thing so I had to deal with this a bit. 17:13:02 --- 17:13:23 morning 17:14:06 morning! 17:14:08 i worked on my OTF stuff and actually started the paper which is the thing i am supposed to deliver which says how i am doing the stuff 17:15:01 that's about it for me 17:15:11 i will continue doing that this week 17:15:24 also moving in to my new place! 17:15:33 (BTW, crypto folks: Shor's withdrawn paper from last week was indeed nothing-to-worry-about, right?) 17:15:50 woo new place 17:15:54 what continent? 17:16:04 yeah, it is nothing to worry about, lattice crypto is still fine 17:16:32 my last week i helped with the funding drive; i've been helping yawning test his sandbox stuff; my this week is going to be explaining to sponsorR why they should keep funding us. i am nearly buried in logistics / admin. 17:16:49 the continent of… umm… the one that has internet :) 17:16:53 isis: So it's more "shor messed up and thought he broke lattices" than "Shor almost broke lattices, but messed up"? 17:17:14 nickm: yes, the former 17:17:21 I should find more victims here 17:17:27 great 17:17:48 though most of you use debian when you linux, and that's relatively well tested 17:18:08 armadev: ack. I will try not to ask for anything. Isabela could probably need use any thoughts/help you can give her on her funder interactions though. 17:18:29 Yawning: i fedora, i can be a victim 17:18:38 fedra what 17:18:57 nickm: feel free to ask! :) and yes, isa, do involve me in your funder things. (it's drl and sida for this month right?) 17:19:00 that's the 3rd most tested platform, because I've been using a F25 vm 17:19:41 chelseakomlo: https://git.schwanenlied.me/yawning/sandboxed-tor-browser/wiki has fedora build/install instructions 17:19:52 edit to taste, let me know if something breaks 17:19:59 don't depend on it till the official release 17:20:07 armadev: i plan on sending it to vegas list like others are doing 17:20:13 whose vegas team is tails in? applications? 17:20:18 armadev: but for network team is otf and drl only 17:20:54 armadev: or did you meant something else? 17:20:58 Yawning: will do! 17:21:16 isabela: i don't know, i meant whatever nickm meant :) 17:21:28 any more updates? :) 17:21:32 the command takes a bunch of flags, unless you want downloads to appear y7uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu 17:21:45 nickm: do you mean the headcount thing? 17:22:00 i have a short update! aside from what dgoulet said, I submitted a patch for #20717 and fixes for nickm's review of #18873 17:22:02 the command takes a bunch of flags, unless you want downloads to appear under ~/.local/share/etcetcetcetc, --advanced is useful 17:22:12 isabela: headcount and/or questions from funder. 17:22:12 * armadev pictures cat-lady-yawning, with cats crawling on every surface 17:22:17 roger seems good at helping with both 17:22:26 (my cunning plan to distract the cat has failed) 17:23:04 (though if not, please ignore my advice :) ) 17:23:18 chelseakomlo: neat! Sorry I'm going to take a little while to get to review stuff... 17:23:28 oh, i guess another part of my status should be that i dropped 0.2.8 and 0.2.9 progress. if somebody wants to pick that up great, otherwise it will be waiting for nickm at the end of the week :) 17:23:44 Yawning: what happens if you make the sandbox save by default to ~/Download/ like Chrome/Firefox seems to do on my linux? 17:23:55 Yawning: like make it save out of the sandbox. does that beat the purpose completely? 17:23:56 nickm: no worries! 17:24:07 Okay. Discussion topics? 17:24:08 fingerprinting vector 17:24:33 so it defaults to tinfoil hat behavior, there are config options if people ant it to do that 17:24:46 I have a couple... 17:24:55 I do to 17:24:59 nbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbnnnnnnnnnnnnnnnnnnnnnnnn4333333 17:25:03 ? 17:25:03 nickm: is #19877 actually 0.3.0 material? this means that the branch needs to be in merge_ready by XXX? 17:25:06 çat 17:25:10 ugh 17:25:10 a) test my sandbox 17:25:13 asn: I believe it should be if possible. 17:25:23 b) my life will be a lot easier if PTs support AF_LOCAL 17:25:23 nickm: and what is XXX in that case? 17:25:36 because I want to run each pt in their own container 17:25:59 like use external mode 17:26:06 asn: according to https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam , we're saying that the feature freeze is on Jan 24 2017. But I'd prefer that big stuff be merged well before that. 17:26:10 so tor/pts can have separte seccomp rules 17:26:23 nickm: so like mid december or something would be ideal i guess 17:26:40 nickm: let's see if we can do it :) 17:26:42 for merge_ready? sure, but that will depend on when people can review, and how much more work there is to do on it 17:26:42 i also have fedora VMs, version 23 and/or 24 if that is useful 17:26:46 c) the tor UseSandbox stuff has a few XXX comments 17:27:00 is there plans to backfill that, should I? 17:27:04 There are also a couple more huge branches I want to get to merge_ready: #15056, and mike's netflow stuff. 17:27:11 (we could add a date in the schedule freezing major feature before actually) 17:27:13 and whatever prop#224 parts are ready 17:27:36 nickm: do you have any urgent code review request for EOM deliverables? 17:27:51 or code-review you need that has no reviewer yet 17:28:22 isabela: I don't _think_ I have an EOM-code-review request... so long as SponsorU will accept "This code is implemented and well-tested, and is currently under review for merge." 17:28:44 isabela: if they won't pay for unreviewed code.... that would be a shock to me, and a bad surprise. :) 17:28:44 ok 17:28:55 As for stuff-with-no-reviewer: #15056 sticks out to me. 17:29:09 oh and d) the subgraph folks said taht ordering their seccomp rules by call frequency helped performance, we should do that 17:29:39 dgoulet looked at #15055 in a helpful way, but I don't want to make it so that being amazing once means that you're expected to do it forever. 17:29:54 nickm: oh I can do another pass! 17:30:07 * dgoulet note it down 17:30:21 this is a separate branch 17:30:25 completely different 17:30:31 still interested? :) 17:30:34 sure 17:30:38 wow, thanks. 17:30:43 we are talking about #15056 right ? 17:30:45 yes 17:30:49 #15055 is merged 17:31:08 there Reviewer is set, will prioritize this 17:31:37 thank you. 17:31:53 I don't expect I'll be able to do any revisions on it till next week, so please don't rush 17:31:59 #20805 is best bug 17:32:04 ;_; 17:32:43 other topics for this week? Do we have somebody on bug triage? 17:32:53 Looks like asn. Thanks, asn! 17:33:05 it's me! 17:33:08 thanks! 17:33:10 how is bug triage going for you? 17:33:29 I'll take the two unclaimed weeks in devember? 17:33:31 A1 for me, I like it ;) 17:33:48 it's fine. sometimes you get to discover all sorts of fun tickets. 17:34:08 sometimes you get to discover that teor is awake 24/7 and always on bug triaging duty 17:34:36 i disappear, back in a bit 17:34:49 ahahah! 17:35:10 ok. any more topics for today, or was this a short meeting? :) 17:35:11 asn: hehe 17:35:43 going once .... 17:35:48 oh! 17:35:58 ? 17:36:04 Something important that I want to do for december, which I can either start thursday, or somebody could start now... 17:36:19 it's been a long time since we went through the proposals and saw what needs a discussion meeting. 17:36:24 Anybody want to do that? 17:36:45 I've been bad about staying on top of the naming system stuff 17:36:50 asn: lol, yeah, teor was already on like 2/3 of the bugs i was supposed to triage 17:37:08 nickm: hmmm yeah it's been a while since we did proposal meetings 17:37:22 i can take a look at the last 3 months of proposals or so, and find some interesting/unfinished ones 17:37:26 if that's helpful 17:37:37 yeah; especially ones you think we should talk about 17:37:47 (i can also let someone else do this, if they are more excited. this week is going to be brutal.) 17:38:01 the proposal-status.txt document in torspec.txt could also be brought up to date. 17:38:05 nickm: ack 17:38:06 oh question! 17:38:15 nickm: noted 17:38:21 asn: if you don't get to it, no worry, so long as somebody does 17:38:24 nickm: (wrt proposal-status.txt) 17:38:26 dgoulet: question? 17:38:26 264-subprotocol-versions.txt needs to be merged in dir-spec.txt ideally, for prop224 we need to add some there 17:38:39 can we make this a "sub-spec" instead of adding to the 3.5k lines of dir-spec? :) 17:39:00 dgoulet: like how rend-spec is? 17:39:06 I think prop224 should just become rend-spec.txt, and the old rend-spec.txt should be an old one. 17:39:07 +1 for sub-specs! 17:39:07 or more so? 17:39:15 For 264, I dunno. 17:39:56 (in general that is) 17:39:57 According to torspec, every proposal whose status is "FINISHED"needs to be merged into a spec somehow. 17:40:09 Yawning: I showed the subgraph folks the ld.so parsing and one comment I got was that it doesn't really add much. Is it worth introducing the complexity of another parser? 17:40:18 There would appear to be 14 of those :/ 17:40:19 right prop264 is not that big there but meh 17:40:28 Because statically compiling would get around it 17:41:04 some of those "FINISHED" proposals might be merged already. If they are, they should be marked "CLOSED". 17:41:32 I think as a matter of principle, people should be able to get a functional tor implementation out of [tor,dirmrend]-spec 17:41:43 agreed 17:41:49 mostly 17:42:03 fair enough 17:42:40 there should exist *-spec.txt, where people can get a functional tor implementation out of it 17:42:56 dividing it into tor,dir,rend is not IMO inherently right 17:43:06 yah 17:43:08 But we shouldn't leave unmerged proposals lying around 17:43:22 I'd troll and say, as a matter of princile, this should be RFC 9001 - The Tor Protocol 17:43:24 agreed. also perhaps one -spec.txt file can refer to another smaller -spec.txt file. 17:43:38 but I wouldn't want to inflict and IETF working group on anyone 17:43:46 Hey Sebastian, did you have any chance to look at the website updates? 17:43:52 Yawning: did I just hear you volunteer to run a working group? :) 17:44:31 FWIW, we used to have tor-spec.txt much more updated... we did that by patching the spec *before* we implemented the feature, as we were desiging. 17:44:36 I'll think about it if I haven't totally lost my mind and joined a hippie commune by the time RFCs get that high 17:44:37 That turned out to be really unworkable after a while. :) 17:45:08 Yawning: I guess if your heart's set on joining a hippie commune, you could do worse than the IETF... 17:45:11 ;) 17:45:17 any other topics today? 17:45:21 (I guess, instead of a hippie commune, a militia compound is more in line with my philosophy) 17:45:56 nickm: what are our plans for core tor sandboxing 17:46:11 [pace groucho marx, I wouldn't join any commune that would have me.] 17:46:17 Yawning: Vague. 17:46:33 Yawning: Which means we have substantial freedom to define them to be however we want. 17:46:59 /* XXXX restrict this in the same ways as mmap2 */ 17:47:00 Yawning: I would like to do more sandboxing jointly with more modularization, so that we can make the privileged parts of Tor as small as possible. 17:47:09 indeed 17:48:20 i'll be interested to see what comes of the hs versioning discussion 17:48:44 the mmap filter ought to be trivial to write: nothing in sb_mmap2() is mmap2-specific except the ID. 17:48:57 yah 17:49:17 that was the main thing that stuck out at me 17:49:49 nickm: oh! 17:49:54 "oh!"? 17:50:04 `MaxMemInQueues` doesn't matter on clients right? 17:50:16 how do you mean "doesn't matter" ? 17:50:27 We should probably avoid OOM-attacks against clients... 17:50:29 having the client use the defaulty 17:50:40 is fine-ish? 17:51:05 it's the only thing that causes a standard tor to read /proc 17:51:20 and my container of awesome (unless tor is compiled against asan) does not have proc 17:51:23 hm. should be fine-ish-ish. 17:51:31 You can just set it really high, I guess 17:51:39 or maybe there's some other way to learn how much ram there is 17:51:45 it defaults to a gig ish? 17:51:55 on 32 bit systems, higher on 64 17:52:01 should be safe, I guess 17:52:09 I'd have to check the code. 17:52:34 it works, but I am unsure of the failure mode 17:52:47 the defaults seemed ok, so I am omitting proc for now 17:53:21 failure mode 1: is "user had less RAM than the default, we let Tor allocate too much, OOM killer kills us." 17:53:38 failure mode 2: is "user had more RAM than the default, we didn't know, we killed off some circuits that we didn't have to" 17:53:39 so be it 17:53:48 Neither is world-ending 17:53:53 yeah 17:54:01 I think not having a proc in at least one container is a win 17:54:05 ok. remaining topics? 17:54:07 Yawning: yeah 17:54:15 else I'll end the meeting so the tb meeting can start in 5 min 17:54:51 ok. Thanks, everybodY! 17:54:54 #endmeeting