16:59:46 #startmeeting 16:59:46 Meeting started Mon May 1 16:59:46 2017 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:59:46 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:59:46 ! 16:59:50 hello 16:59:55 * isabela writing on pad 16:59:56 hiya 16:59:58 status pad is over here: https://pad.riseup.net/p/CNkp69Uy2n1h 17:00:00 hello hello 17:00:15 teor should be asleep and ahf is off doing a May 1 thing. 17:01:04 let's all add status to the pad, then discuss. I'll add an area at the top to add discussion questions 17:01:30 mikeperry: hihi! 17:02:07 nickm: hi :) 17:03:08 hello 17:04:33 anybody who's done with your status -- do you have questions for anyone else, or help that you need this week? 17:05:33 i'd just like to agree that 6-7 function arguments is too many 17:06:00 I do have questions about couple of tickets, should I add that to the list of discussiosn? 17:06:03 the worst function tend to be those that got their arguments one at a time 17:06:05 dgoulet: sure! 17:06:07 i have a question for everyone / just to make sure folks looked at the roadmap pad and added the work they plan on doing (maybe we will have more info to add after today's meeting on tor launcher automation feature) 17:06:21 link to roadmap pad? 17:06:30 yes one sec 17:06:58 https://storm.torproject.org/shared/6lWoIwWM-XCKn7hbHa1kgGY5AcDy8galPNL66RBmCG1 17:06:59 :) 17:07:26 thanks 17:08:02 should we edit April to reflect actual progress? 17:08:20 sure 17:08:29 catalyst: i agree with that 17:10:22 dgoulet, asn: Can you add projected R progess to that pad? Everything I wrote there was a guess 17:11:06 is there 17:11:08 R is in the roadmap already no? 17:11:19 sure, there just isn't that much about what gets done when 17:11:25 just "it's done in july" 17:11:28 (and also I can't load storm pad with TB anymore.... takes either 15 minutes to load then I disconnect or it just fails badly) 17:11:32 with nothing listed for april, may, jone 17:11:35 *june 17:11:42 :/ 17:11:46 :( 17:12:15 maybe I could do a wiki page with R roadmap with a bit more details and ticket 17:12:21 ok, if no questios, let's do discussion? 17:12:22 ok i can add stuff if you email me 17:12:22 dgoulet: thanks! 17:12:25 we do have well defined tickets just not "dates" per-se 17:12:31 just an end date ehhe 17:12:44 might be good to pick dates make sure they add up 17:13:02 tor milestone is really what we are aiming at but I,ll try to make soft deadline 17:13:06 so, quick announcements: feature freeze in two weeks. That means I'll be distracted by reviewing and merging a lot 17:13:34 i'll aim to review everything that's finished by next monday in time, but can't guarantee. 17:13:43 catalyst: #22088 looks good to me 17:13:47 so if somebody's got a 30kloc patch I don't know about, .... 17:13:57 ... make sure I know it's coming :) 17:14:04 isis: thanks 17:14:14 We should also plan to do 032 planning some time over the next couple of weeks 17:14:23 nickm: #16861 ? :P 17:14:44 yeah, I know about that one; how's it coming? 17:14:50 catalyst: i would add that extra-info lines should have PT args sorted on keys and then on values (i'm not sure anything expicitly forbids duplicate keys) 17:15:03 nickm: well I switched it to merge_ready last week after my review and mikeperry addressed all the concerns I had 17:15:06 yeah I am wondering if I should remove my is_clent update code in favor of#21406 17:15:46 and also if I should squash down and cean up the branch to get rid of fixme's and code review commits 17:15:53 if I merge it, do you think a bunch of test net operators and users could try it out asap? 17:16:06 catalyst: (i was planning on doing that just in bridgedb, so i can hash bridge lines and have a canonical representation of a bridge line) 17:16:14 sorry. #21406 17:16:18 mikeperry: I prefer to do squashing myself to make sure it's the same after the squash 17:16:26 nickm: very much so yes, I'm ready to email the testnet to update fast with upstream 17:16:32 isis: does anything currently depend on the ordering of keys in an extra-info line? 17:16:33 nickm: ok 17:16:37 isis: do we haved a statement saying K=V order can't matter? 17:16:42 *have 17:16:44 isis: if not we should add one 17:16:47 dgoulet: great 17:17:10 I don't understand the is_client vs #21406 question 17:17:37 having the #16861 branch do _less_ is something I like, but messing with it even more is something I'm not so sure about 17:17:44 mikeperry: which option do you prefer? 17:17:57 I use a consensus check to update it. I could just make a note in #21585, which is the ticket to remove such things 17:18:13 catalyst: not that i'm aware of, and iirc the spec says "unordered key-value pairs" 17:18:29 mikeperry: that would be fine with me if that's what you prefer 17:18:48 ok 17:19:09 did that cover dgoulet and mikeperry's questions or did I miss something? 17:19:22 (my stuff is different :) 17:19:29 I'm good for my stuff then 17:19:40 ok. dgoulet ? 17:20:11 nickm: yes, iirc the pt-spec says K=V ordering doesn't matter, but i'd like to be able to hash bridge lines and get the same hash if it contains the same PT and arguments 17:20:12 how badly we want this in 031? #21117 ... because I'm not entirely happy about introducing a new torrc option for it 17:20:38 I would be ok deferring for 032 and nail down a good solution that we all agree 17:21:48 dgoulet: I'd rather do a good solution later than a fast one now, but I know weasel and teor care more about this than I do, so maybe ask them 17:22:01 plausible? 17:22:39 ok sounds good, I'll try to gather more opinions after the meeting (as I know weasel doesn't like the MeetBot :) 17:22:44 yup 17:23:17 does anybody else have question about what they're working on, or what others are working on? 17:23:22 second thing I had in mind was scheduled an 032 planning meeting/email but it's on the pad already :D 17:24:20 rust folks: should we talk about #22106 here a bit, or just note that it's there and talk more on the ticket 17:25:03 wrt 032 planning -- what if we just do that on our 15 may meeting? 17:25:11 nickm: sure- i have to drop off in 5 but i'll read here afterward 17:25:21 re #22106 17:25:27 (I am becoming a rust folk, but have not had a chance to look at that ticket. I am just writing toy programs at this point and fighting with the borrow checker :) 17:26:02 so the question is about what we do with our dependencies. 17:26:22 we're talking about MB of libraries here. 17:26:33 yeah, I saw that much. cargo is a few kinds of scary :/ 17:26:48 we probably don't want to put the rust package manager in charge of downloading stuff for real builds, 17:26:57 though I'm okay if it's an option that devs can use. 17:27:25 we probably should try to figure out the whole solution right now, but let's figure out what our requirements are 17:27:44 cargo would break TBB builds, which have to be done in offline VMs (unless RBM changes that, but I don't think it should) 17:27:44 is there something OS packagers do with rust packages that we could use as a model? 17:28:06 mikeperry: so far, i'm happy with rust, most of my worry so far is about ffi/managing a clean & safe api/migration etc 17:28:07 One thing I really care about here is usability: i'd like it to be incredibly darn easy for developers to work with this, and to get started with this. Working on tor should be as easy as possible. 17:28:22 can any rustaceans answer catalyst's question? 17:28:39 I think most hardcore rust people trust cargo more than we want to trust it here 17:29:03 mikeperry: how does FF ship with Rust? I mean last I heard they have A/V or something decoder in Rust now? 17:29:05 I don't want to keep huge external libraries in the Tor codebase. 17:29:15 they have a note in their rust docs that say that cargo is not "paranoid" levels of secure, or similar.. it does no sig checking, relies purle on HTTPS.. 17:29:17 nickm: + 17:29:18 1 17:29:49 can it pin to a digest? 17:29:49 ah, sorry. 17:29:52 here now 17:29:55 dgoulet: we just barely dodged needing to build rust for FF52esr, so I'm not entirely sure 17:30:21 nickm: yes 17:30:52 cargo pins to digest by default nowadays, yes 17:31:08 a digest other than sha1? 17:31:29 because pinning to a good digest is IMO not so bad, even if the HTTPS gets attacked 17:32:16 the "local crates mirror and a command to set it up" seems like a fine solution to me, maybe 17:32:30 sha256 17:32:33 good enough 17:33:10 sounds like we're on track for a good answer here then? 17:33:18 mikeperry: cargo does not break builds in VM 17:33:22 when configured like in my branch 17:33:58 it does not need to touch the network at all, which to me seems is a hard requirement for builds from our tarball 17:34:47 Sebastian: ah, cool. I am excited to look at your branch then. all I saw was that cargo could use a git hash 17:35:26 (and when will git migrate away from sha1?) 17:35:46 I think I'm out of topics. Everybody who's going to be at the TorLauncher UX meeting later on: it's in 1.5 hours, and please read linda's stuff before the meeting and think about what you want to do 17:36:21 It would be awesome to get answers to the questions on the ticket 17:36:25 catalyst: soon I hope, but i don't know 17:38:11 catalyst: they're going through all the code and replacing "sha1" with "oid", so that's something... 17:38:27 if no more discussion, let's end early? 17:39:28 okay! 17:39:30 thanks, everybody! 17:39:32 #endmeeting