17:59:28 <nickm> #startmeeting weekly network team meeting
17:59:28 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:59:39 <nickm> https://pad.riseup.net/p/wEQEYIkHHUNn is the pad
17:59:43 <isabela> !
17:59:46 <isabela> buenas
17:59:51 <ahf> hey
18:00:05 <nickm> hihi
18:00:27 <nickm> isis, catalyst, mikeperry: meeting time now
18:00:36 <nickm> https://pad.riseup.net/p/wEQEYIkHHUNn is the pad this week
18:01:17 <isabela> sorry Sebastian !
18:02:06 <Sebastian> ah you are pink? :)
18:02:23 <isis> o/
18:04:52 <nickm> let's everybody finish filling in our updates, then read updates from others and boldface discussion topics
18:09:01 <catalyst> anyone else getting repeatedly disconnected from the pad?
18:09:14 <nickm> seems to work ok for me
18:10:01 <isabela> me too but i am not on tor
18:10:03 <ahf> i'm on via the .onion without problems right now
18:11:33 <nickm> 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 <ahf> i think it was nice with a *pre* event hackfest in montreal
18:11:53 <mikeperry> hrmm I got disconnected from tor to riseup just now. it seems to be reloading
18:12:04 <ahf> i think the post event hackfests in amsterdam was hard on the brain
18:12:31 <catalyst> are we getting enough value from the public hackfest days?
18:12:31 <ahf> (might have also been related to meeting a lot of new people for the first time though)
18:12:31 <isis> catalyst: same here
18:13:32 <nickm> My public hackfest days are mostly doing follow-up stuff from the previous days
18:13:40 <nickm> and being tired :)
18:14:24 <isis> 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 <nickm> sad :(
18:14:44 <ahf> auch, isis - condolences
18:14:46 <nickm> good wishes
18:14:53 <mikeperry> 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 <isis> it'll be uh… well not okay, but this was kind of expected
18:15:07 <isis> just not the timing of it
18:15:29 <nickm> mikeperry: otoh they mostly benefit from interrupting you, fwict
18:16:11 <nickm> 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 <isabela> fyi
18:16:37 <isabela> people are talking about the meeting after rome and it might be in brazil
18:16:47 <nickm> (that would be neat)
18:17:04 <isabela> 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 <nickm> that would probably be a good idea
18:17:14 <ahf> 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 <isabela> like trainings and stuff
18:17:28 <Sebastian> I liked the public hack days because I could go interrupt people for rust stuff (in Amsterdam)
18:17:39 <nickm> i wonder if it's too late to reach out to roman groups for March
18:17:41 <Sebastian> But I did not interact with the public in any way
18:18:02 <dgoulet> 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 <dgoulet> (and doing that to other people is gold for me ^ :)
18:18:19 <isabela> 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 <ahf> maybe it would make sense to poke the ooni people about reach out in rome?
18:18:59 <catalyst> i found that the total length of the Montreal trip was really kind of over my endurance
18:19:03 <ahf> i have the feeling a lot of them are based in italy
18:19:09 <nickm> catalyst: +1 there
18:19:57 <nickm> maybe if we do a pre-meeting hack-time it should be just one full day?
18:20:23 <nickm> (we have 40 min left and several questions, btw, but this is important and we should figure it out soon)
18:20:29 <isabela> ahf: yes
18:20:37 <catalyst> nickm: that might work (only 1 day pre-meeting)
18:20:40 <dgoulet> pre meeting of 1 days is good,
18:20:51 <ahf> i think one day would be OK. the rust thing was good and a big thing
18:20:59 <isabela> pre pre meeting? not the teams meeting day
18:21:03 <catalyst> we'd want to make sure people have enough time to prepare so the one day ends up being maximally useful
18:22:04 <nickm> 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 <nickm> Next issue is from asn?
18:22:35 <isis> yeah, the length of montréal was kind of a lot, like working two weekends in a row
18:24:10 <nickm> mikeperry: did you see asn's question?  I think it's for you.
18:24:17 <asn> nickm: thx for raising it :)
18:25:26 <nickm> on deck is dgoulet's question.  Who is the logical reviewer for #23709?  It's me, isn't it?
18:26:00 <mikeperry> asn: ah yeah I didn't see the bold in that dark color :)
18:26:13 <asn> np
18:26:21 <dgoulet> 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 <dgoulet> nickm: ^
18:26:50 <nickm> dgoulet: I understand that -- I'm asking who the reviewer should be
18:27:29 <dgoulet> no preferences here, channel layer is not simple :S
18:28:02 <mikeperry> 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 <asn> mikeperry: ack
18:28:10 <asn> mikeperry: thx
18:28:10 <isis> is that perhaps related to #8185 ?
18:28:33 <dgoulet> I don't think so
18:28:42 <nickm> I don't think it is
18:29:26 <nickm> dgoulet: okay, sounds like I should prioritize review; i'll add that to my week
18:29:58 <nickm> my question are twofold this week!
18:29:58 <dgoulet> thanks!
18:30:25 <nickm> first -- there's the issue of the patch that turns our object_free() functions into macros that NULL their targets.
18:30:54 <nickm> there are several proposed variations in the review, largely centered around whether they should be in uppercase or not
18:31:10 <nickm> and I think maybe I saw a suggestion that they should be functions that take a pointer to a pointer.
18:31:24 <catalyst> nickm: that might have been mine (take address of pointer to free)
18:31:26 <nickm> I'm basically okay with all of these variations
18:31:52 <nickm> but we should settle on siomething, and I worry that we are not on track to actually ever decide :)
18:32:01 <nickm> *sp
18:32:09 <nickm> any ideas how we should pick a variant here?
18:32:44 <catalyst> 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 <ahf> i'm fine with all of them, really. but i also don't mind lowercased macro's :-S
18:33:16 <dgoulet> my opinion is in the ticket so if we need to vote (or +1), consider it cast :)
18:33:18 <nickm> ok.  Is there anybody remaining who objects to the lowercase-macro variant
18:33:30 <Sebastian> 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 <catalyst> 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 <nickm> ok
18:34:16 <nickm> my second question is about our seccomp2 sandbox strategy
18:34:33 <nickm> Sebastian posted a ticket from a cpunk who believes that our sandbox strategy is fubar wrt strings
18:34:35 <catalyst> we can make taking the address of the pointers being freed a separate ticket
18:34:50 <nickm> I need to see if they are right in their offhand comment about brk()
18:35:03 <nickm> (#24400)
18:36:04 <nickm> 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 <nickm> but assuming that they are right, and that our sandbox effectively allows open()/openat() of anything, we have three choices fwict.
18:36:52 <nickm> Choice 1: Do we permit all these syscalls without listing allowable files?
18:37:27 <nickm> 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 <nickm> Choice 3: How urgent do we treat that as?
18:38:34 <nickm> (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 <nickm> does anybody have thoughts on the sandbox thing?
18:39:09 <isis> if we go towards choice 2, wouldn't we also benefit from separating other things according to privileges into separate processes?
18:39:14 <nickm> yup
18:39:24 <Sebastian> Well, my understanding is that if they're right 1) is the correct short-term thing to do
18:39:41 <nickm> an alternative to 1 is to do nothing.
18:39:44 <ahf> i think #2 would make the freebsd capsicum patches easier too
18:39:45 <isis> are we allowed to have multiple processes?  would that mess up things like the run-tor-in-a-thread iOS thing?
18:39:55 <Sebastian> whereas doing nothing while waiting for 2 seems like we'd wait for a long time
18:39:58 <Sebastian> potentially
18:40:10 <Sebastian> I don't really thing prioritizing 2 too much has enough benefits
18:40:14 <asn> nickm: i think you are supposed to look at mikeperry/bug23114
18:40:17 <nickm> 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 <asn> nickm: but let's wait for mikeperry to confirm
18:40:31 <mikeperry> nickm: yes. mikeperry/bug23114 for both bugs
18:40:49 <mikeperry> as per my most recent comment on https://trac.torproject.org/projects/tor/ticket/23114#comment:18
18:41:22 <nickm> noted
18:41:28 <asn> mikeperry: fwiw, the branch has fixups.
18:41:37 <asn> i dont think that's what nick wants, except if nick is gonna track the whole review procedure
18:41:51 <mikeperry> asn: nick has in the past asked to sqush things himself
18:41:58 <nickm> please no rebases at this point
18:42:04 <nickm> I think i need to read the whole history of that branch
18:42:10 <asn> ack ok!
18:42:11 <mikeperry> nickm: have your preferences changed wrt squashing for you, or squashing yourself?
18:42:27 <mikeperry> (as a general matter for future stuff)
18:42:42 <nickm> my preference is "please don't squash a branch after I have reviewed a vesion of it"
18:42:55 <nickm> sometimes it makes sense to squash anyway though if the review process has been goin on a long time
18:43:01 <nickm> but in this case I think i want to see the change process
18:43:20 <isis> 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 <nickm> yeah.  I think that's what to do here
18:45:54 <nickm> i'll update the ticket, I guess
18:46:24 <nickm> next questions are from  ... catalyst I think?
18:46:33 <nickm> isis: btw, note that isabela has a ping for you
18:47:14 <catalyst> nickm: i guess so?
18:47:44 <Sebastian> We used to have that iirc
18:47:52 <nickm> have what?
18:47:55 <catalyst> 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 <Sebastian> logging clock skew at notice
18:48:21 <Sebastian> from untrusted sources
18:48:37 <catalyst> Sebastian: hm i wonder why it got downgraded then
18:48:51 <Sebastian> 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 <Sebastian> because it produces tons of false positives
18:49:09 <isis> nickm: got it, thanks!
18:49:21 <catalyst> Sebastian: i think with a large enough tolerance the false positives might be fewer
18:49:37 <dgoulet> probably a ticket discussing this would be a good idea?
18:49:43 <catalyst> 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 <Sebastian> its clock might be wrong
18:50:45 <nickm> if two or three relays' clocks are wrong by about the same amount, I bet it's worthwhile telling the user
18:50:52 <catalyst> how far off can a relay's clock be before it ceases to be voted upon?
18:50:55 <nickm> which implies a NOTICE message
18:51:19 <Sebastian> nickm: yes, agreed
18:51:30 <nickm> 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 <catalyst> 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 <Sebastian> catalyst: you get into the consensus, you set your clock back a day, you're still in the consensus.
18:51:58 <nickm> 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 <catalyst> how often is there a benign case of a relay's clock being off by hours or more?
18:53:07 <dgoulet> (I don't want to be an ass but should we discuss this after? and continue with Sebastian's question? ;)
18:53:18 <dgoulet> (6 min left :S)
18:53:22 <nickm> catalyst: I think we need to track that state for this to be useful.
18:53:47 <nickm> especially assuming that this is indeed something we made INFO earlier because of false positives
18:54:05 <nickm> catalyst: you okay with talking more about this immediately after the meeting on #tor-dev?
18:54:11 <catalyst> nickm: sure
18:54:19 <nickm> ok
18:54:22 <catalyst> i should probably open a ticket about this anyway
18:54:24 <nickm> Sebastian: you have 3 listed issues
18:54:30 <nickm> catalyst: +1
18:54:34 <Sebastian> yes sorry
18:54:35 <nickm> Sebastian: go for it!
18:54:59 <Sebastian> First off, before the last security update there was talk about whether the patch should've been merged before the announcement
18:55:15 <Sebastian> 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 <Sebastian> Also, not all dirauths are updated yet
18:55:44 <nickm> 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 <Sebastian> most critically the bridge auth is not
18:55:48 <nickm> isis: ^
18:56:26 <asn> btw there is still one review-group ticket unhandled
18:56:35 <asn> and another one that is the tor_free one
18:56:39 <nickm> 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 <Sebastian> 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 <nickm> asn: do you mean #22703 ?
18:56:49 <asn> yhes
18:57:09 <Sebastian> nickm: yes, I think before the release it was suggested the policy could use tweaking
18:57:18 <Sebastian> so now afterwards I want to remind of that :)
18:57:22 <Sebastian> ok, next topic
18:57:42 <nickm> whoever suggested that, or whoever agrees: please open a ticket!
18:57:47 <nickm> I no longer remember the suggestion :)
18:57:54 <nickm> Sebastian: go for it!
18:58:10 <Sebastian> 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 <Sebastian> We should monitor changes to the network based on this policy change
18:58:51 <Sebastian> Maybe we could try to get information on how relevant port 80 still is today
18:59:10 <Sebastian> teor has opinions there, but it could be interesting. See tor-relays for context.
18:59:21 <nickm> good idea!  we should open a ticket, too, if there isn't already one
18:59:25 <catalyst> did we recently make a change that would make 80 required for the Exit flag?
18:59:43 <nickm> 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 <nickm> catalyst: we used to requir 2/3 of (IIRC 80, 443, 6667).  Then I thnk we removed 6667
19:00:15 <Sebastian> 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 <isabela> (uhh is time for tbb meeting ?)
19:00:49 <GeKo> after the network meeting, yes
19:00:50 <Sebastian> sorry for going over time
19:00:58 <GeKo> fine with me
19:01:07 <isabela> :) tx
19:01:21 <nickm> ok.  time for us to run out the door
19:01:23 <nickm> thanks, everybody!
19:01:36 <nickm> Sebastian: interesting idea; has drawbacks; has been argued about prevbiously; worth arguing about again!
19:01:43 <nickm> let's have a ticket if there isn't already one
19:01:47 <nickm> sorry we can't talk more right now
19:01:50 <nickm> i'll be on #tor-dev
19:01:51 <nickm> #endmeeting