17:01:56 #startmeeting weekly network team meeting 17:01:56 Meeting started Mon Jan 23 17:01:56 2017 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:56 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:02:14 hello :) 17:02:15 hi ! asn dgoulet isabela Yawning (if you're around) teor (if you're up in the middle of the night) and various others! 17:02:25 welcome ! 17:02:25 https://blog.torproject.org/blog/tor-0299-released 17:02:41 armadev: thank you for taking this stuff; I am totally underwater today 17:03:02 so I have an easy status update: last week I ran around trying to get last-mintue coding and merging done for 0.3.0 17:03:07 this week: more of that! 17:03:23 [good job on all the coding and reviewing, friends] 17:03:24 o/ 17:03:57 I also worked over the weekend on a bug found by oss-fuzz, now known as TROVE-2017-001. 17:04:04 releases are out today. 17:04:13 i can go nexT! 17:04:21 great! 17:04:24 go for it 17:04:29 Hello. During past week I did various prop224 and guard stuff. I found two 17:04:29 guard bugs (#21142 and #21052) and provided patches. I've been testing patches 17:04:29 since then and they seem to work. I then worked on the service-side of 17:04:29 prop224, and prepared a small module for dgoulet (see #20657). Today I worked 17:04:29 on encoding prop224 addresses which is an open topic for #20657. I wrote a 17:04:32 small proposal with some silly mistakes, then got schooled by Ian but it's all 17:04:34 a step forward! 17:04:37 https://lists.torproject.org/pipermail/tor-dev/2017-January/011816.html 17:05:35 EOF next plz 17:05:41 asn: are you around after the meeting? If so I'd like to talk about guard stuff with you a little to help me figure out the remaining bugs. 17:06:05 asn: if not let's pick another time 17:06:20 i will probably disappear straight after the meeting. but i will be around tomorrow all day. 17:06:52 ok! 17:06:56 who's next? 17:07:06 I can go 17:07:48 So mostly reviewing bugs, also doing some patches to try to bring down the number of tickets in 030 ... I did lots of work on prop224 service implementation (#20657). Nothing ready yet for initial review but making progress! 17:08:04 thanks to asn also for the hs_circuitmap_t changes! very useful for that work ^ 17:08:33 apart from that, nothing much affecting network team, bad relays stuff... our UAE situation also... that's about it. 17:08:35 --- 17:09:06 oh, i do have a thing: i think our dir fetch counting stuff is super wrong. are there any tickets open for that? if not i'd like to chat afterwards with somebody to help build a plan. 17:09:30 (tl;dr we count a dir request as completed basically as soon as the request is received) 17:09:33 armadev: I'm not aware of any tickets for that currently 17:09:39 oh wait that 17:09:41 maybe we do 17:09:44 karsten might know! 17:09:51 it probably worked back when dir requests came over http 17:10:15 * isabela is almost done with sponsoru complementary report - and want to start organizing sponsor4 work (new contract) i have more for our discussion time :) 17:10:19 now they use linked tls conns so "we finished sending stuff to the other part of ourself" is not enough 17:10:24 --- 17:11:49 ok. any more updates this week? If not, let's collect discussion topics. 17:12:08 * Should we extend the merge window by a couple of days? 17:12:27 * What features, if any, would warrant that? 17:13:03 * Schedule for starting 0.3.0.1-alpha, and process for it, and major goals for it? 17:13:08 other topics? 17:13:12 0.3.1.1-alpha i hope? 17:13:30 otherwise, i can tell you the major goals for 0.3.0.1-alpha! :) 17:14:09 * sponsor4 17:14:47 err, 0.3.1.x, yeah 17:14:58 are there big features still unmerged? 17:15:06 sponsor4 -> this is more an update on prep-work for it 17:15:11 https://trac.torproject.org/projects/tor/query?status=needs_information&status=needs_revision&status=merge_ready&status=reopened&status=needs_review&status=assigned&status=new&status=accepted&group=status&milestone=Tor%3A+0.3.0.x-final 17:15:25 let's talk about 0.3.0, then sponsor 4, then 0.3.1 ? 17:15:40 [that url is all the tickets in 0.3.0] 17:15:55 [we can fix bugs after the merge window, but no features!] 17:16:09 asn: I would really like my fuzzing branch merged, to help improve our security... 17:16:31 i reviewed a bit but not enough. i can continue tomorrow . 17:16:41 TBB wants #20956 17:16:43 * asn notes it 17:17:14 ok so far we need to resolve #20956, #20893 before freezing 17:17:46 i think #21052 might be a good one to fix as well. but it's a bug fix not a feature. 17:17:48 it would be good if we could get all the current needs_review stuff reviewed at least. 17:17:52 #20956 looked pretty close to ready 17:17:54 I want to take a look at #13802 today for inclusion but it will be best effort on my part... worst case we defer 17:18:14 np 17:18:34 I'll review #21134, but it won't hurt if we have to defer 17:18:37 #20830 also before freeze for sure, removing that amount of code woudl be good 17:18:49 i can also take a look at guard stuff: #20824, #20830. probably can't get to both tomorrow tho. 17:18:52 hi sorry 17:19:08 * asn notes them down as well 17:19:25 hi Yawning ! glad you could make it. I hope stuff is less messed up in your home, or a t least on its way to becoming less messed up 17:20:05 ok great i have three tickets to review (#20893, #20824, #20830). i will try to get to them ASAP. 17:20:08 dealing with that right after this 17:20:12 still poking at crypto 17:20:15 here is a possibility: what if the cutoff for considering patches is 24 Jan, but we give ourselves a couple of extra days to review. Would anybody mind that? 17:20:27 sneaky 17:20:28 and I tagged a new sandbox release 17:20:36 i wouldnt mind that 17:20:49 nickm: I'm fine with extending few days so we can freeze by the end of the week 17:20:59 (or when if we are happy with current state) 17:21:26 is the uae thing an actual thing or just a bug in how we calcualte stats/someone feeding crap data 17:21:43 Yawning: let's discuss that after 17:21:46 k 17:22:35 ok. let's aim for "all feature patches to be considered should be done by 24 Jan; we'll try to have them reviewed + merged by 27 jan "? 17:22:35 oh, on a side note, do people other than me care about/want to use cpu/architecture specific features 17:22:48 Yawning: I would like all our crypto to go faster 17:22:50 so there's that 17:22:51 or should I just assume that for the msot part, I'm the only one that writes assembly 17:22:52 Yawning: (what crypto is that?) 17:23:14 lattices? 17:23:51 my plan is to provide vector codepaths for sse2 and avx2 on x86_64 17:24:35 I could do 32 bit, but I'd rather not because register pressure sucks, and would like to do avx512 but don't have a good way to test it 17:25:39 nickm: it would help if we had a list of tickets to resolve before feature feeze. So far I have "all in needs_review" and #20893, accurate? 17:26:08 dgoulet: "all in needs_review and needs_revision; all Enhancements in 0.3.0" --- 17:26:16 except we don't need to actually _merge_ all of those... 17:26:27 we need to merge them or defer them 17:26:30 if that makes sense 17:26:34 sure ok 17:26:39 that's a lot lol 17:26:40 we can try 17:27:05 like #21269 is "new" ... and seems interesting to look at before freeze as well 17:27:55 well, it's not a lot if we defer them all :) 17:28:01 it's only a lot if we try to merge them all 17:28:08 indeed indeed 17:28:10 yeah, that one does look cool 17:28:11 ok let's see how it goes :) 17:28:14 woo. 17:28:28 ok, next topic is sponsor4 stuff. isabela ? 17:28:43 yes! 17:29:03 so me and nick start to organize things for sponsor4 17:29:33 i will migrate the plan to our wiki soon and also create a page for sponsor4 on the sponsors area of the wiki with all its deliverables (core tor and tor browser stuff) 17:29:36 https://blog.torproject.org/blog/tor-0302-alpha-released 17:29:43 (armadev: thx) 17:29:51 but for this meeting i wanted to share to main tickets that will carry the first phases of this work 17:30:02 #21205 17:30:11 #21209 17:30:53 these phases are Measure and Design phases 17:31:14 (oh #21205 would tie so well with #13802 if it's really about testing locally :) 17:31:27 i will also send an email to the list with all this info but i wanted to give this update on today's meeting as well :) 17:31:50 isabela: neat! yeah knowin what "Sponsor4" is about would be helpful but I kind of have an idea now :) 17:32:01 I tried to pick measurement and design tasks based on what I thought would give the most benefit-per-effort 17:32:28 We have substantial freedom to do other stuff there if there is something else that would fulfil the overriding goal of "reduce directory overhead in order to make things easier on (mobile) clients" 17:32:45 consensus diff :) 17:32:51 :) 17:33:29 that was it pretty much o/ more to come soon 17:33:38 use lzma2 instead of gzip 17:33:43 I want to spend some time thinking about the pluses and minuses of letting clients use custom directory guards/directory mirrors 17:34:06 dgoulet: that's on there 17:34:08 (also hi. sorry I'm like half-here) 17:34:16 though if people use shit hardware, they might be sad 17:34:23 because it's more memory/cpu intensive 17:34:26 Yawning: so is that, along with some ideas about how to make it affordable 17:34:38 "don't use a 386" 17:35:10 (one issue is server-side compression of arbitrarily complex collections of microdescriptors over and over and over) 17:35:23 implement the all.z thing 17:36:10 Yawning: see tickets :) 17:36:17 or that 17:36:20 that's (sorta) in there 17:36:35 custom directory mirrors so that if an org wanted to spin up say 100M lightweight tor clients, they could do so with their own directory capacity for those clients, if they did not care about those clients being recognizable to the local network 17:37:31 but this thinking can be done outside of sposor4. I may try to find another sponsor for it 17:38:04 nickm: are we worried for sponsor4 about the increase of size of HS descriptor? Going from roughly a maximum size of roughly 9k now to a mazimum size of 50k ? 17:38:04 mikeperry: I would be interested in collaborating on proposals there if you want 17:38:24 dgoulet: I don't know; it's worth thinking about! 17:38:35 * dgoulet keeps that in mind 17:38:38 dgoulet: certainly we should ask if we can do more to compress the insides 17:38:42 or whatever 17:39:02 any more on sponsor4? 17:39:40 (not from me) 17:39:41 If not, I have a possibly goofy proposal: I propose that there's nothing we need to figure out about 0.3.1.x this week. Am I right? If so I suggest that we table my other topic till the next meeting. 17:39:58 Is there some 0.3.1.x thing that we would benefit from knowing about now? 17:40:23 I can do a reminder for 031 17:40:51 031 will be the one with prop224 support so expect all LOTS of new code 17:41:14 woo 17:41:42 dgoulet: btw, have you figured out the UI for running new/old hidden services ? 17:41:50 maybe writing the idea down would help 17:41:53 nickm: define the UI? 17:42:03 nickm: torrc options, TBB, ... ? 17:42:38 torrc options, default behavior, what goes in the directory, etc 17:42:49 we do have a big thread about that on tor-dev@ and it came down to a solution 17:43:13 ok. is the solution summarized in one place? 17:43:13 the layout on disk is yet to come, me and asn have a design that we need to send to tor-dev@ very soon 17:43:15 if so awesome 17:43:29 nickm: I believe I made a summary email about it, let me dig it up for you 17:43:53 nickm: https://lists.torproject.org/pipermail/tor-dev/2016-December/011725.html 17:43:54 boom 17:44:11 nickm: best summary I can give you and implementation is following that so far 17:44:32 great; thanks! 17:44:44 any more for this meeting? 17:44:51 If not, then once more we may be ending on time! 17:44:59 * dgoulet is good 17:45:25 * isabela is good 17:46:10 nickm: a tiny thing: do we have a timeframe for the fuzz fix rollout? 17:46:20 not yet 17:46:25 i think we might want to get it into 0.2.9 for the dir auths who run that 17:46:30 which will be exciting for new-debian 17:47:06 don't we need to get it into 0.2.9 for tor browser? 17:47:23 we already got the "don't -ftrapv unless expensive-hardening" fix today 17:47:41 the second part is the "remove the integer overflow that oss-fuzz found" part 17:47:48 ah 17:48:06 i could see doing that in 0.3.0.3-alpha first 17:48:18 we should figure out how we categorize / backport "this crashes you if you have expensive-hardening on" issues 17:48:29 or i could see doing an 0.2.9.10 that debian ignores, but weasel makes debs out of for deb.tp.o, since the dir auths matter most 17:48:36 and we should also maybe rename expensive-hardening 17:49:15 I think that there will be an 0.2.9.10 sooner or later, possibly with only smaller fixes, but with only fixes. 17:49:46 We should also put out new 0.2.[45678] releases at some point, for accumulated fixes 17:49:53 but I'm not going to have time this week 17:50:03 any more for this meeting 17:50:05 ? 17:50:32 hearing none... 17:50:37 #endmeeting