16:59:37 #startmeeting weekly network team meeting 16:59:37 Meeting started Mon Apr 24 16:59:37 2017 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:59:37 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:59:43 oi 16:59:54 hi 16:59:57 ello 16:59:58 hihi, Sebastian asn dgoulet catalyst isis Yawning teor ahf pastly etc! 17:00:01 hi 17:00:03 and sorry for the names I missed! 17:00:10 hello! 17:00:12 update pad is here: https://pad.riseup.net/p/hl5PW1abAFKn 17:00:38 let's do updates and then talk 17:00:41 hi 17:00:45 ! 17:00:46 oi 17:04:17 ctrl-q'ed my browser :( 17:04:28 asn: there's still content in the pad 17:04:40 btw, I'm done. Not sure if we indicate that here or something to move along 17:05:20 yes, i'm done too 17:05:26 i'm done too 17:05:29 I think we usually sit and wait for the pad to stop updating for an unconfigured amount of time. 17:05:30 I'm done 17:05:57 pastly: how do you know that the limits in the scheduler are never hit? (okay to note on the pad) 17:06:22 done 17:06:30 done 17:06:38 ahf: is it feasible to aim for merging the compression API soon, and merging cleanup as it comes in? I'd like to use it for prop#140 17:06:51 nickm: I'll put my answer in the pad 17:07:08 * nickm is doing the "read and ask questions" thing. Others can too! 17:07:25 hi 17:07:33 hi isis! 17:07:46 status pad's at https://pad.riseup.net/p/hl5PW1abAFKn 17:07:51 nickm: we could ditch the test case refactoring (move it into a ticket on its own) such that you can start using it right away? 17:07:58 ditto the coverage fixes? 17:08:02 Sebastian: FFI border? O_o 17:08:39 ahf: That seems like a plausbile idea, but it would be good to know where we stand with compression at least so we know what to be scared about 17:09:00 asn: do we have any path in mind towards a fix for #21969 ? 17:09:03 asn: FFI as in foreign function interface, border as in "allocate this string in C, free it from Rust" 17:09:09 asn: dunno what your exact question is 17:10:12 Sebastian: can we do something to wrap the strings so that they get freed with tor_free() when rust goes to free them? 17:10:17 nickm: not sure. i dont really understand how it's caused this time. 17:10:22 nickm: i think we need some more info 17:10:22 it seems like this is a problem that would mostly happen with strings, and not so much else 17:10:29 asn: any ideas what we should start logging? 17:10:30 nickm: i dont think it's something tragic tho. it doesn't happen super often. 17:10:32 nickm: hm that message showed up frequently when i was having problems with obfs4 earlier 17:10:42 hmmmm 17:11:05 Sebastian: ack makes sense 17:11:07 nickm: yep. i'm working on merging the test_util_{gzip,lzma,zstd} per your review and i haven't added any LCOV_EXCL_* lines yet in the patches. we are missing: #22051 and #21665. 17:11:23 ahf: in that case imo it's okay to fix those post merge 17:11:26 nickm: We have to provide a rust_free_string function, and have to use it for any string allocated in Rust. We can call tor_free from the Rust side for strings allocated in C 17:11:29 we can skip the merging of the test's and put it into an isolated ticket, then i can fix this post-merge? 17:11:40 cool! let me go do that after the meeting then, awesome. 17:11:51 hmm, i am unable to connect to the pad 17:11:52 17:10 < catalyst> nickm: hm that message showed up frequently when i was having problems with obfs4 earlier 17:11:56 This is frustrating to me, because it is not *necessary* the way Rust is implemented. But they explicitly do not guarantee this 17:12:01 catalyst: yep something stinks about our logic there :( 17:12:07 * pastly is done writing again 17:12:09 so it totally works on accident, which is sad. 17:12:17 catalyst: nickm: that warning happens both in default case (s7r) and in obfs4 case (catalyst) 17:12:55 or rather, if you do it wrong it'll work. I even think it's extremely unlikely Rust will ever want to change how that works. But they don't want to promise it. 17:13:22 Sebastian: probably we should wrap strings that need to be freed in some funny way in a special type so that we don't need to remember "this one gets freed in a special way" 17:14:01 anybody else have questions for anybody based on their updates? 17:14:07 I don't quite see how that would work effectively. 17:14:18 (we can talk about this postmeeting if that's better) 17:14:26 Sebastian: sure 17:14:58 catalyst: btw, we should probably talk some time about how last week went and how sponsorM stuff is shaping up, now that we're both around during the same week. Is after this meeting ok for that? 17:15:00 I'm thinking 031 bug triage rather soonish? merge window ends soon 17:15:11 nickm: sure 17:15:12 catalyst: also good luck wrt house-buying! 17:15:17 thanks! 17:15:34 dgoulet: makes sense. We've got about a month till the window closes, right? 17:15:43 mid-may so yeah less 17:16:02 makes sense 17:16:21 May 15, 2017 17:16:36 any proposed procedure? 17:16:41 (want to call attention on possible dependencies between sponsorM, sponsor4 and new drl proposal) 17:16:52 isabela: please do! 17:17:16 nickm: is related to an email thread linda started 17:17:38 for ticket triage, I suggest we do this: 17:17:56 - everybody make sure that everything you are going to do for 031 is assigned to you, and has a points estimate. 17:18:28 - if your points estimate is over 12 or so, defer the less important things, or tag them with 031-stretch. 17:18:28 right now we are defining how this feature will work - the feature is to automate how tor launcher works so the user doesn't need to be choosing alternate ways to connect if the default (direct connection to tor network) doesnt work 17:18:43 - for everything that doesn't get an owner, I will defer it or mark it "too important to defer" 17:18:48 - Does that make sense? 17:18:57 so - part of this feature might need the work on sponsorM 17:19:07 nickm: ack 17:19:35 - Is 24 hours enough time for everybody to do the assign/unassign/triage thing? 17:19:37 nickm: yup 17:19:42 isabela: yep 17:20:01 yep 17:20:15 * isis is finally able to load the pad and updates it 17:20:16 isabela: makes sense. I think that the launcher idea -- if I understand it right -- is to try different PTs in an exploratory sense and not make the user figure out what their degree of censorship is 17:20:27 yes 17:20:50 I _think_ that's somewhat orthoganal to the M stuff, although the "reporting status for bootstrap progress" item might fall under both 17:20:59 yep 17:21:04 i think that's the ticket 17:21:11 isis: congrats on OTF completion! 17:21:14 the thing to keep in mind is by when tbb would need that 17:21:21 nickm: thanks! 17:21:22 to implement at their side 17:21:26 isabela: is there a timeline? 17:21:30 yes! 17:21:31 or should we coordinate with them? 17:21:43 that is part of the roadmap/dependencies track that i am doing 17:22:06 https://storm.torproject.org/shared/TEXpfXgfFRFnpwud4IVeRLp7QkFyeBcRbDX_qTB5yEl 17:22:09 tbb roadmap has it for july 17:22:17 if july is too soon for you 17:22:32 we can work with tbb to move it 17:22:53 but the grant in general ends at end of November (keep that in mind too) 17:23:20 looking at the pad there is no ticket right now for the "make it possible for tor launcher to probe different PTs" project 17:23:26 isabela: this is to "try bridges until something works" or "automate getting bridges"? 17:23:27 the closest thing is this thread https://lists.torproject.org/pipermail/tbb-dev/2017-February/000487.html 17:23:35 isabela: try bridges until something works 17:23:49 ehm isis ^ 17:23:54 ugh 17:24:41 security-wise this is not a great idea in terms of fingerprinting and stuff 17:24:41 ill open a ticket for this task i think we are missing one 17:24:55 is anybody doing the security design on this? 17:24:57 isis: there are probe different PTs and there is your bridge implementation 17:25:46 asn: no ticket yet - i am trying to get folks to define what they will be implementing to have tickets and make sure (if it depend on other ppl work) dependencies are tracked 17:25:58 nickm: like whether probing certain transports (or unbridged Tor) might attract unwanted state attention for some users? 17:26:14 this seems like a weird thing to do if i just wrote a giant design for getting bridges in a blocking resistant way… 17:26:18 yeah. For example: detect any attempt to connect to tor. 17:26:39 then block all traffic for the next 5 minutes 17:26:41 alright let me give some background 17:26:45 there, you win, nothing ever succeeds 17:26:46 i imagine it would be an optional thing for newbie users, who are basically gonna trial-and-error probe PTs themselves 17:26:58 also the design assumes you use a transport like obfs4 afterwards 17:27:14 what is happening here is a colision of many things - so it might sound weird that are similar requests etc. I am trying to get everyone at the same page (TBB, network team and ux team) 17:28:27 1. we wrote this proposal thinking of implementing linda ui improvements for tor launcher (based on her research) 17:28:47 2. we also wrote that we would implement the tor launcher ui part of what isis was working with otf 17:29:35 for sponsor4 and new drl proposal - both sponsors asked us to automate this part 17:29:56 the part of when tor launcher is launched by the user and the connection with tor network is done 17:30:06 so there is less work needed from the user to figure out what to do 17:30:14 how we will do that is open right now 17:30:50 so, we can DTRT, so long as there's a launcher path to DTRT, and it isn't horrible UX? 17:31:06 DTRT? 17:31:16 do the right thing 17:31:22 :) 17:31:26 tx! 17:31:30 np! 17:32:04 so i am just calling attention to this i think we need to define what is the experience we want to have and see what work on sponsorM we will depend on for that 17:32:09 and how isis work fits on this 17:32:13 and go from there 17:32:24 maybe not now but i wanted to make sure ppl had this in mind 17:34:09 this might be a stupid question, but how broad is the sponsor4 set of tasks? :o this seems far away from the directory work we are doing now? 17:34:13 hm, makes sense. we should probably take linda's proposed experience, look to see how that is and what it's missing and where it goes wrong, and make a counterproposal 17:34:31 (the answer to that question can go after the meeting - i'm just a bit confused here) 17:34:42 IMO this has almost nothing to do with sponsor4 on the tor side. TThere are TBB tasks for sponsor4, though 17:34:49 ah, good good 17:34:55 ahf: that is a task related to tbb 17:34:55 then i feel less confused. thanks 17:34:57 and if they require tor improvements, we should figure that out :) 17:35:01 yes 17:35:22 https://trac.torproject.org/projects/tor/wiki/org/sponsors/Sponsor4 17:35:28 all sponsor4 tasks are here ^^ 17:35:51 this is 2.1 17:37:00 otf requested that as part of improve usability of tor launcher - tha we automate it 17:37:26 ok. So, who should we have from our side on the redesign here? Sounds like isis and catalyst and I should go over the launcher proposal and figure out where the pain points are and what the tor support would look like? 17:37:38 ye 17:37:39 yes 17:37:45 i can follow up with you off this meeting then 17:38:01 ok, let's go that route. anybody else want to get in on that? 17:38:45 I suppose I can, if it would be helpful 17:39:13 it might be. we should also get linda involved of course 17:39:14 mikeperry: i would like that since you have been talking with linda about this feature 17:39:19 nickm: yes 17:39:31 i want network team, tbb and ux ppl talking all together 17:39:45 and defining what we are doing here, who will do each part etc 17:40:54 is the tor launcher proposal and/or linda's UX redesign written up somewhere? 17:41:47 isis: this part of automation is not defined yet 17:42:00 that is what i am trying to get folks together to do 17:42:27 her research is here https://trac.torproject.org/projects/tor/wiki/doc/TorLauncherUX2016 17:44:07 ok, sounds good 17:44:12 isabela: thanks! 17:44:53 also #21951 has some of linda's proposals 17:45:06 ok. we're 45 min in. More to discuss this week? :) 17:45:43 i don't have anything 17:45:50 for bug triage, what unit is currently being used for the Points field? and if I'm not sure, what should I put there? 17:46:06 nickm: tl;dr for why the limits aren't hit: the vanilla sched runs too often and tor writes to the kernel too frequently for the limits to have any effect. 17:46:12 points == how many working days you think it will take, approximately 17:46:17 only use fractions if it's < 1 17:46:22 ok 17:46:42 use "(parent)" for tickets where the child tickets have 100% of the work 17:46:47 (to avoid double-counting) 17:47:04 okay. In that case, I'll call the meeting over, and send out our status notes and the meetbot link? 17:47:04 isabela: so it sounds like we should have a meeting between me, catalyst, nickm, linda, and geko (and maybe more ux and browser people?) 17:47:33 isis: I think first also we should go over linda's work and proposed idea sketches 17:47:39 and decide what we think 17:47:49 so that the meeting is n't just linda explaining things she already wrote down :) 17:48:02 isis: yep! 17:48:05 isis: will work on that 17:48:07 nickm: good thinking 17:48:41 i would suggest to follow her email 17:48:43 nickm: ^^ 17:48:48 that one you are copied on 17:50:14 I just sent a message in that thread asking for permission to share it with isis and catalyst 17:50:22 hearing no objections, I will close the meeting 17:50:47 thanks, everybody ! You all make Tor wonderful, both as software and as a workplace! 17:50:50 #endmeeting