17:59:28 #startmeeting weekly network team meeting 17:59:28 Meeting started Mon Dec 4 17:59:28 2017 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:59:28 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:59:39 https://pad.riseup.net/p/wEQEYIkHHUNn is the pad 17:59:43 ! 17:59:46 buenas 17:59:51 hey 18:00:05 hihi 18:00:27 isis, catalyst, mikeperry: meeting time now 18:00:36 https://pad.riseup.net/p/wEQEYIkHHUNn is the pad this week 18:01:17 sorry Sebastian ! 18:02:06 ah you are pink? :) 18:02:23 o/ 18:04:52 let's everybody finish filling in our updates, then read updates from others and boldface discussion topics 18:09:01 anyone else getting repeatedly disconnected from the pad? 18:09:14 seems to work ok for me 18:10:01 me too but i am not on tor 18:10:03 i'm on via the .onion without problems right now 18:11:33 so, as folks are finishing up -- Teor has a discussion topic for us -- should we try to get a pre-Rome hackfest in? 18:11:51 i think it was nice with a *pre* event hackfest in montreal 18:11:53 hrmm I got disconnected from tor to riseup just now. it seems to be reloading 18:12:04 i think the post event hackfests in amsterdam was hard on the brain 18:12:31 are we getting enough value from the public hackfest days? 18:12:31 (might have also been related to meeting a lot of new people for the first time though) 18:12:31 catalyst: same here 18:13:32 My public hackfest days are mostly doing follow-up stuff from the previous days 18:13:40 and being tired :) 18:14:24 oh, new update: i won't be able to attend the mozilla all hands because i have to fly somewhere say bye to someone who is going to die 18:14:35 sad :( 18:14:44 auch, isis - condolences 18:14:46 good wishes 18:14:53 ahf: I hear that. I find unstructured days with lots of people very draining.. it seems like people just queue up to interrupt you about something :/ 18:15:02 it'll be uh… well not okay, but this was kind of expected 18:15:07 just not the timing of it 18:15:29 mikeperry: otoh they mostly benefit from interrupting you, fwict 18:16:11 it sounds like we do want hack days before the rome meeting, and that we want to raise concerns about having the "public" hackdays be more useful. Is that right? 18:16:27 fyi 18:16:37 people are talking about the meeting after rome and it might be in brazil 18:16:47 (that would be neat) 18:17:04 and i just wrote an email that if it is in brazil i would hope to have the open days to be more directly collabration with local grassroots organizaitons 18:17:12 that would probably be a good idea 18:17:14 i think i quite like the unstructured hackdays we had in montreal, but i do agree they could have some more structure than they had 18:17:15 like trainings and stuff 18:17:28 I liked the public hack days because I could go interrupt people for rust stuff (in Amsterdam) 18:17:39 i wonder if it's too late to reach out to roman groups for March 18:17:41 But I did not interact with the public in any way 18:18:02 I'm also a fan of the public days, the only time really people can interrupt me and finally ask stuff they wanted to work on for which I *do* have time to help 18:18:12 (and doing that to other people is gold for me ^ :) 18:18:19 nickm: idk, but for brazil specifically that is a lot politically going on and doing that would collaborate a lot with the struggle there 18:18:55 maybe it would make sense to poke the ooni people about reach out in rome? 18:18:59 i found that the total length of the Montreal trip was really kind of over my endurance 18:19:03 i have the feeling a lot of them are based in italy 18:19:09 catalyst: +1 there 18:19:57 maybe if we do a pre-meeting hack-time it should be just one full day? 18:20:23 (we have 40 min left and several questions, btw, but this is important and we should figure it out soon) 18:20:29 ahf: yes 18:20:37 nickm: that might work (only 1 day pre-meeting) 18:20:40 pre meeting of 1 days is good, 18:20:51 i think one day would be OK. the rust thing was good and a big thing 18:20:59 pre pre meeting? not the teams meeting day 18:21:03 we'd want to make sure people have enough time to prepare so the one day ends up being maximally useful 18:22:04 Let's take this to the mailing list, and also cc the Rome organizers so that they have time to make the arrangements happen if possible? 18:22:30 Next issue is from asn? 18:22:35 yeah, the length of montréal was kind of a lot, like working two weekends in a row 18:24:10 mikeperry: did you see asn's question? I think it's for you. 18:24:17 nickm: thx for raising it :) 18:25:26 on deck is dgoulet's question. Who is the logical reviewer for #23709? It's me, isn't it? 18:26:00 asn: ah yeah I didn't see the bold in that dark color :) 18:26:13 np 18:26:21 because 033 feature freeze is Jan 15th (SOOOOOON), knowing if this is postponed or not changes quite a bit of things for the other fixes I need to work on 18:26:23 nickm: ^ 18:26:50 dgoulet: I understand that -- I'm asking who the reviewer should be 18:27:29 no preferences here, channel layer is not simple :S 18:28:02 asn: I will reply to your mail today. (TL;DR will be that all of the changes I'm thinking about for prop247 are to simplify it as much as possible, and see if it is fast enough) 18:28:08 mikeperry: ack 18:28:10 mikeperry: thx 18:28:10 is that perhaps related to #8185 ? 18:28:33 I don't think so 18:28:42 I don't think it is 18:29:26 dgoulet: okay, sounds like I should prioritize review; i'll add that to my week 18:29:58 my question are twofold this week! 18:29:58 thanks! 18:30:25 first -- there's the issue of the patch that turns our object_free() functions into macros that NULL their targets. 18:30:54 there are several proposed variations in the review, largely centered around whether they should be in uppercase or not 18:31:10 and I think maybe I saw a suggestion that they should be functions that take a pointer to a pointer. 18:31:24 nickm: that might have been mine (take address of pointer to free) 18:31:26 I'm basically okay with all of these variations 18:31:52 but we should settle on siomething, and I worry that we are not on track to actually ever decide :) 18:32:01 *sp 18:32:09 any ideas how we should pick a variant here? 18:32:44 having reviewed the changes on the branch it seems like the macros are used in enough places that uppercasing them would detract from readability 18:32:47 i'm fine with all of them, really. but i also don't mind lowercased macro's :-S 18:33:16 my opinion is in the ticket so if we need to vote (or +1), consider it cast :) 18:33:18 ok. Is there anybody remaining who objects to the lowercase-macro variant 18:33:30 My preference is "make all the _free macros NULL their argument, don't change anything wrt spelling etc" on the theory that this is what I as a semi-rare tor code base contributor am used to. I also never found it particularly confusing or hard to get used to 18:33:56 also the "weirdness" of the macros is mostly innocuous, and forgetting about that weirdness "fails safe", so it's not as bad as some other possible macro uses 18:34:09 ok 18:34:16 my second question is about our seccomp2 sandbox strategy 18:34:33 Sebastian posted a ticket from a cpunk who believes that our sandbox strategy is fubar wrt strings 18:34:35 we can make taking the address of the pointers being freed a separate ticket 18:34:50 I need to see if they are right in their offhand comment about brk() 18:35:03 (#24400) 18:36:04 if they're wrong, then we actually did the right set of kludges to make the mprotect() trick they hate work out. 18:36:10 but assuming that they are right, and that our sandbox effectively allows open()/openat() of anything, we have three choices fwict. 18:36:52 Choice 1: Do we permit all these syscalls without listing allowable files? 18:37:27 Choice 2: If we decide that we need an architecture that has a separate procwess that's allowed to do open/openat, where/how do we prioritize that work? 18:37:34 Choice 3: How urgent do we treat that as? 18:38:34 (unrelated question for asn and mikeperry: could you clarify on #23100 and #23114 what branch or set of branches exactly I should look at, at this point? I don't understand exactly where to look.) 18:38:50 does anybody have thoughts on the sandbox thing? 18:39:09 if we go towards choice 2, wouldn't we also benefit from separating other things according to privileges into separate processes? 18:39:14 yup 18:39:24 Well, my understanding is that if they're right 1) is the correct short-term thing to do 18:39:41 an alternative to 1 is to do nothing. 18:39:44 i think #2 would make the freebsd capsicum patches easier too 18:39:45 are we allowed to have multiple processes? would that mess up things like the run-tor-in-a-thread iOS thing? 18:39:55 whereas doing nothing while waiting for 2 seems like we'd wait for a long time 18:39:58 potentially 18:40:10 I don't really thing prioritizing 2 too much has enough benefits 18:40:14 nickm: i think you are supposed to look at mikeperry/bug23114 18:40:17 isis: we would need to have the multiprocess thing be optional, and only when there's a syscall-based sandbox in place 18:40:21 nickm: but let's wait for mikeperry to confirm 18:40:31 nickm: yes. mikeperry/bug23114 for both bugs 18:40:49 as per my most recent comment on https://trac.torproject.org/projects/tor/ticket/23114#comment:18 18:41:22 noted 18:41:28 mikeperry: fwiw, the branch has fixups. 18:41:37 i dont think that's what nick wants, except if nick is gonna track the whole review procedure 18:41:51 asn: nick has in the past asked to sqush things himself 18:41:58 please no rebases at this point 18:42:04 I think i need to read the whole history of that branch 18:42:10 ack ok! 18:42:11 nickm: have your preferences changed wrt squashing for you, or squashing yourself? 18:42:27 (as a general matter for future stuff) 18:42:42 my preference is "please don't squash a branch after I have reviewed a vesion of it" 18:42:55 sometimes it makes sense to squash anyway though if the review process has been goin on a long time 18:43:01 but in this case I think i want to see the change process 18:43:20 hmm, i think we don't really have any other choice other than #1 for the short-term, but #2 would be really nice imho 18:45:41 yeah. I think that's what to do here 18:45:54 i'll update the ticket, I guess 18:46:24 next questions are from ... catalyst I think? 18:46:33 isis: btw, note that isabela has a ping for you 18:47:14 nickm: i guess so? 18:47:44 We used to have that iirc 18:47:52 have what? 18:47:55 nickm: we currently log untrusted clock skew detections at LOG_INFO. i think this prevents it from showing up in the Tor Launcher logs among others 18:48:13 logging clock skew at notice 18:48:21 from untrusted sources 18:48:37 Sebastian: hm i wonder why it got downgraded then 18:48:51 I would be extremely hesitant to log clock skew from untrusted sources unless multiple untrusted sources agree with each other that we're wrong 18:49:05 because it produces tons of false positives 18:49:09 nickm: got it, thanks! 18:49:21 Sebastian: i think with a large enough tolerance the false positives might be fewer 18:49:37 probably a ticket discussing this would be a good idea? 18:49:43 if a relay's clock is offset from ours either it's trying to attack us or our own clock is skewed 18:50:05 its clock might be wrong 18:50:45 if two or three relays' clocks are wrong by about the same amount, I bet it's worthwhile telling the user 18:50:52 how far off can a relay's clock be before it ceases to be voted upon? 18:50:55 which implies a NOTICE message 18:51:19 nickm: yes, agreed 18:51:30 catalyst: I think there could be a catch-22 there where you don't know if the relay is voted upon until you have decided to believe a consensus... 18:51:30 nickm: i'd like that (multiple relays being off by about the same amount) but that requires more state information than we currently track 18:51:37 catalyst: you get into the consensus, you set your clock back a day, you're still in the consensus. 18:51:58 and you don't know if you have decided to believe a consensus until you have decided whether it's up-to-date. :/ 18:52:35 how often is there a benign case of a relay's clock being off by hours or more? 18:53:07 (I don't want to be an ass but should we discuss this after? and continue with Sebastian's question? ;) 18:53:18 (6 min left :S) 18:53:22 catalyst: I think we need to track that state for this to be useful. 18:53:47 especially assuming that this is indeed something we made INFO earlier because of false positives 18:54:05 catalyst: you okay with talking more about this immediately after the meeting on #tor-dev? 18:54:11 nickm: sure 18:54:19 ok 18:54:22 i should probably open a ticket about this anyway 18:54:24 Sebastian: you have 3 listed issues 18:54:30 catalyst: +1 18:54:34 yes sorry 18:54:35 Sebastian: go for it! 18:54:59 First off, before the last security update there was talk about whether the patch should've been merged before the announcement 18:55:15 please don't forget to discuss this at an appropriate time now that we're not rushing to get a security fix out 18:55:40 Also, not all dirauths are updated yet 18:55:44 Let's phrase this as a proposed change to our security policy at https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/SecurityPolicy 18:55:45 most critically the bridge auth is not 18:55:48 isis: ^ 18:56:26 btw there is still one review-group ticket unhandled 18:56:35 and another one that is the tor_free one 18:56:39 Sebastian: for security issue handling, it has seemed lowest-stress to just follow the policy, and update the policy as needed when it looks wrong 18:56:42 We have a person who takes to twitter to make these observations about who is updated. No attacks afaict, but we might need to consider that these could happen next time. 18:56:45 asn: do you mean #22703 ? 18:56:49 yhes 18:57:09 nickm: yes, I think before the release it was suggested the policy could use tweaking 18:57:18 so now afterwards I want to remind of that :) 18:57:22 ok, next topic 18:57:42 whoever suggested that, or whoever agrees: please open a ticket! 18:57:47 I no longer remember the suggestion :) 18:57:54 Sebastian: go for it! 18:58:10 When I used to run an exit node many years ago I didn't exit to port 80 because I wanted to make a statement that I won't look at unencrypted traffic. Today it helps cut down on abuse complaints. That will stop working soon, because you must exit to port 80 for an Exit flag 18:58:35 We should monitor changes to the network based on this policy change 18:58:51 Maybe we could try to get information on how relevant port 80 still is today 18:59:10 teor has opinions there, but it could be interesting. See tor-relays for context. 18:59:21 good idea! we should open a ticket, too, if there isn't already one 18:59:25 did we recently make a change that would make 80 required for the Exit flag? 18:59:43 and since we're just about out of time, let me suggest a ticket for the 3rd issue too , unless we already have one 19:00:13 catalyst: we used to requir 2/3 of (IIRC 80, 443, 6667). Then I thnk we removed 6667 19:00:15 And for the last point, also releated to abuse. Maybe we should limit outgoing connections by circuit. Hooking up a scanner to Tor is trivial and a real issue for a bunch of exit nodes. Maybe forcing more circuits (and less easy setup) could make this better. Interested in your opinions 19:00:39 (uhh is time for tbb meeting ?) 19:00:49 after the network meeting, yes 19:00:50 sorry for going over time 19:00:58 fine with me 19:01:07 :) tx 19:01:21 ok. time for us to run out the door 19:01:23 thanks, everybody! 19:01:36 Sebastian: interesting idea; has drawbacks; has been argued about prevbiously; worth arguing about again! 19:01:43 let's have a ticket if there isn't already one 19:01:47 sorry we can't talk more right now 19:01:50 i'll be on #tor-dev 19:01:51 #endmeeting