16:59:37 <nickm> #startmeeting weekly network team meeting
16:59:37 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:59:43 <asn> oi
16:59:54 <Sebastian> hi
16:59:57 <pastly> ello
16:59:58 <nickm> hihi, Sebastian asn dgoulet catalyst isis Yawning teor ahf pastly etc!
17:00:01 <catalyst> hi
17:00:03 <nickm> and sorry for the names I missed!
17:00:10 <ahf> hello!
17:00:12 <nickm> update pad is here: https://pad.riseup.net/p/hl5PW1abAFKn
17:00:38 <nickm> let's do updates and then talk
17:00:41 <dgoulet> hi
17:00:45 <isabela> !
17:00:46 <isabela> oi
17:04:17 <asn> ctrl-q'ed my browser :(
17:04:28 <Sebastian> asn: there's still content in the pad
17:04:40 <Sebastian> btw, I'm done. Not sure if we indicate that here or something to move along
17:05:20 <ahf> yes, i'm done too
17:05:26 <nickm> i'm done too
17:05:29 <pastly> I think we usually sit and wait for the pad to stop updating for an unconfigured amount of time.
17:05:30 <pastly> I'm done
17:05:57 <nickm> pastly: how do you know that the limits in the scheduler are never hit? (okay to note on the pad)
17:06:22 <asn> done
17:06:30 <dgoulet> done
17:06:38 <nickm> 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 <pastly> 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 <isis> hi
17:07:33 <nickm> hi isis!
17:07:46 <nickm> status pad's at https://pad.riseup.net/p/hl5PW1abAFKn
17:07:51 <ahf> 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 <ahf> ditto the coverage fixes?
17:08:02 <asn> Sebastian: FFI border? O_o
17:08:39 <nickm> 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 <nickm> asn: do we have any path in mind towards a fix for #21969 ?
17:09:03 <Sebastian> asn: FFI as in foreign function interface, border as in "allocate this string in C, free it from Rust"
17:09:09 <Sebastian> asn: dunno what your exact question is
17:10:12 <nickm> 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 <asn> nickm: not sure. i dont really understand how it's caused this time.
17:10:22 <asn> nickm: i think we need some more info
17:10:22 <nickm> it seems like this is a problem that would mostly happen with strings, and not so much else
17:10:29 <nickm> asn: any ideas what we should start logging?
17:10:30 <asn> nickm: i dont think it's something tragic tho. it doesn't happen super often.
17:10:32 <catalyst> nickm: hm that message showed up frequently when i was having problems with obfs4 earlier
17:10:42 <nickm> hmmmm
17:11:05 <asn> Sebastian: ack makes sense
17:11:07 <ahf> 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 <nickm> ahf: in that case imo it's okay to fix those post merge
17:11:26 <Sebastian> 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 <ahf> 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 <ahf> cool! let me go do that after the meeting then, awesome.
17:11:51 <isis> hmm, i am unable to connect to the pad
17:11:52 <asn> 17:10 < catalyst> nickm: hm that message showed up frequently when i was having problems with obfs4 earlier
17:11:56 <Sebastian> 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 <asn> catalyst: yep something stinks about our logic there :(
17:12:07 * pastly is done writing again
17:12:09 <Sebastian> so it totally works on accident, which is sad.
17:12:17 <asn> catalyst: nickm: that warning happens both in default case (s7r) and in obfs4 case (catalyst)
17:12:55 <Sebastian> 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 <nickm> 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 <nickm> anybody else have questions for anybody based on their updates?
17:14:07 <Sebastian> I don't quite see how that would work effectively.
17:14:18 <Sebastian> (we can talk about this postmeeting if that's better)
17:14:26 <nickm> Sebastian: sure
17:14:58 <nickm> 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 <dgoulet> I'm thinking 031 bug triage rather soonish? merge window ends soon
17:15:11 <catalyst> nickm: sure
17:15:12 <nickm> catalyst: also good luck wrt house-buying!
17:15:17 <catalyst> thanks!
17:15:34 <nickm> dgoulet: makes sense. We've got about a month till the window closes, right?
17:15:43 <dgoulet> mid-may so yeah less
17:16:02 <nickm> makes sense
17:16:21 <dgoulet> May 15, 2017
17:16:36 <nickm> any proposed procedure?
17:16:41 <isabela> (want to call attention on possible dependencies between sponsorM, sponsor4 and new drl proposal)
17:16:52 <nickm> isabela: please do!
17:17:16 <isabela> nickm: is related to an email thread linda started
17:17:38 <nickm> for ticket triage, I suggest we do this:
17:17:56 <nickm> - everybody make sure that everything you are going to do for 031 is assigned to you, and has a points estimate.
17:18:28 <nickm> - if your points estimate is over 12 or so, defer the less important things, or tag them with 031-stretch.
17:18:28 <isabela> 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 <nickm> - for everything that doesn't get an owner, I will defer it or mark it "too important to defer"
17:18:48 <nickm> - Does that make sense?
17:18:57 <isabela> so - part of this feature might need the work on sponsorM
17:19:07 <asn> nickm: ack
17:19:35 <nickm> - Is 24 hours enough time for everybody to do the assign/unassign/triage thing?
17:19:37 <dgoulet> nickm: yup
17:19:42 <asn> isabela: yep
17:20:01 <ahf> yep
17:20:15 * isis is finally able to load the pad and updates it
17:20:16 <nickm> 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 <isabela> yes
17:20:50 <nickm> 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 <asn> yep
17:21:04 <asn> i think that's the ticket
17:21:11 <nickm> isis: congrats on OTF completion!
17:21:14 <isabela> the thing to keep in mind is by when tbb would need that
17:21:21 <isis> nickm: thanks!
17:21:22 <isabela> to implement at their side
17:21:26 <nickm> isabela: is there a timeline?
17:21:30 <isabela> yes!
17:21:31 <nickm> or should we coordinate with them?
17:21:43 <isabela> that is part of the roadmap/dependencies track that i am doing
17:22:06 <isabela> https://storm.torproject.org/shared/TEXpfXgfFRFnpwud4IVeRLp7QkFyeBcRbDX_qTB5yEl
17:22:09 <isabela> tbb roadmap has it for july
17:22:17 <isabela> if july is too soon for you
17:22:32 <isabela> we can work with tbb to move it
17:22:53 <isabela> but the grant in general ends at end of November (keep that in mind too)
17:23:20 <asn> 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 <isis> isabela: this is to "try bridges until something works" or "automate getting bridges"?
17:23:27 <asn> the closest thing is this thread https://lists.torproject.org/pipermail/tbb-dev/2017-February/000487.html
17:23:35 <asn> isabela: try bridges until something works
17:23:49 <asn> ehm isis ^
17:23:54 <isis> ugh
17:24:41 <nickm> security-wise this is not a great idea in terms of fingerprinting and stuff
17:24:41 <asn> ill open a ticket for this task i think we are missing one
17:24:55 <nickm> is anybody doing the security design on this?
17:24:57 <isabela> isis: there are probe different PTs and there is your bridge implementation
17:25:46 <isabela> 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 <catalyst> nickm: like whether probing certain transports (or unbridged Tor) might attract unwanted state attention for some users?
17:26:14 <isis> 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 <nickm> yeah.  For example: detect any attempt to connect to tor.
17:26:39 <nickm> then block all traffic for the next 5 minutes
17:26:41 <isabela> alright let me give some background
17:26:45 <nickm> there, you win, nothing ever succeeds
17:26:46 <asn> i imagine it would be an optional thing for newbie users, who are basically gonna trial-and-error probe PTs themselves
17:26:58 <isis> also the design assumes you use a transport like obfs4 afterwards
17:27:14 <isabela> 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 <isabela> 1. we wrote this proposal thinking of implementing linda ui improvements for tor launcher (based on her research)
17:28:47 <isabela> 2. we also wrote that we would implement the tor launcher ui part of what isis was working with otf
17:29:35 <isabela> for sponsor4 and new drl proposal - both sponsors asked us to automate this part
17:29:56 <isabela> the part of when tor launcher is launched by the user and the connection with tor network is done
17:30:06 <isabela> so there is less work needed from the user to figure out what to do
17:30:14 <isabela> how we will do that is open right now
17:30:50 <nickm> so, we can DTRT, so long as there's a launcher path to DTRT, and it isn't horrible UX?
17:31:06 <isabela> DTRT?
17:31:16 <isis> do the right thing
17:31:22 <isis> :)
17:31:26 <isabela> tx!
17:31:30 <isis> np!
17:32:04 <isabela> 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 <isabela> and how isis work fits on this
17:32:13 <isabela> and go from there
17:32:24 <isabela> maybe not now but i wanted to make sure ppl had this in mind
17:34:09 <ahf> 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 <nickm> 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 <ahf> (the answer to that question can go after the meeting - i'm just a bit confused here)
17:34:42 <nickm> IMO this has almost nothing to do with sponsor4 on the tor side.  TThere are TBB tasks for sponsor4, though
17:34:49 <ahf> ah, good good
17:34:55 <isabela> ahf: that is a task related to tbb
17:34:55 <ahf> then i feel less confused. thanks
17:34:57 <nickm> and if they require tor improvements, we should figure that out :)
17:35:01 <ahf> yes
17:35:22 <isabela> https://trac.torproject.org/projects/tor/wiki/org/sponsors/Sponsor4
17:35:28 <isabela> all sponsor4 tasks are here ^^
17:35:51 <isabela> this is 2.1
17:37:00 <isabela> otf requested that as part of improve usability of tor launcher - tha we automate it
17:37:26 <nickm> 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 <isabela> ye
17:37:39 <isabela> yes
17:37:45 <isabela> i can follow up with you off this meeting then
17:38:01 <nickm> ok, let's go that route.  anybody else want to get in on that?
17:38:45 <mikeperry> I suppose I can, if it would be helpful
17:39:13 <nickm> it might be.  we should also get linda involved of course
17:39:14 <isabela> mikeperry: i would like that since you have been talking with linda about this feature
17:39:19 <isabela> nickm: yes
17:39:31 <isabela> i want network team, tbb and ux ppl talking all together
17:39:45 <isabela> and defining what we are doing here, who will do each part etc
17:40:54 <isis> is the tor launcher proposal and/or linda's UX redesign written up somewhere?
17:41:47 <isabela> isis: this part of automation is not defined yet
17:42:00 <isabela> that is what i am trying to get folks together to do
17:42:27 <isabela> her research is here https://trac.torproject.org/projects/tor/wiki/doc/TorLauncherUX2016
17:44:07 <isis> ok, sounds good
17:44:12 <isis> isabela: thanks!
17:44:53 <nickm> also #21951 has some of linda's proposals
17:45:06 <nickm> ok.  we're 45 min in.  More to discuss this week? :)
17:45:43 <ahf> i don't have anything
17:45:50 <mikeperry> 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 <pastly> 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 <nickm> points == how many working days you think it will take, approximately
17:46:17 <nickm> only use fractions if it's < 1
17:46:22 <mikeperry> ok
17:46:42 <nickm> use "(parent)" for tickets where the child tickets have 100% of the work
17:46:47 <nickm> (to avoid double-counting)
17:47:04 <nickm> okay.  In that case, I'll call the meeting over, and send out our status notes and the meetbot link?
17:47:04 <isis> 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 <nickm> isis: I think first also we should go over linda's work and proposed idea sketches
17:47:39 <nickm> and decide what we think
17:47:49 <nickm> so that the meeting is n't just linda explaining things she already wrote down :)
17:48:02 <isabela> isis: yep!
17:48:05 <isabela> isis: will work on that
17:48:07 <isis> nickm: good thinking
17:48:41 <isabela> i would suggest to follow her email
17:48:43 <isabela> nickm: ^^
17:48:48 <isabela> that one you are copied on
17:50:14 <nickm> I just sent a message in that thread asking for permission to share it with isis and catalyst
17:50:22 <nickm> hearing no objections, I will close the meeting
17:50:47 <nickm> thanks, everybody !  You all make Tor wonderful, both as software and as a workplace!
17:50:50 <nickm> #endmeeting