13:30:56 #startmeeting 13:30:56 Meeting started Wed Apr 1 13:30:56 2015 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:30:56 Useful Commands: #action #agreed #help #info #idea #link #topic. 13:30:57 and I think we should mention somewhere why we don't close it righ away else in 6 months we are going to ask ourself why the hell we don't close it right away? 13:31:01 hi all! Who's here for the meeting today? 13:31:06 dgoulet: yes comments are good 13:31:07 \o/ 13:31:14 hello meeting! 13:31:31 oi 13:31:35 io 13:31:48 once more it is wednesday 13:31:51 also it is a new month 13:32:07 let's start with brief status updates, then talk about whatever we're talking about? 13:32:10 I'll begin 13:32:44 I've been scrambling to get end-of-month sponsor-S stuff done, and trying to pay attention to HS issues, and generally running in little circles. I hope I can get things done more thoughtfully soon. 13:32:55 (hello) 13:33:10 I got most of the sponsor S deliverables done to my satisfaction. I have the remainder done to a reasonable standard, though I want to work on them a little more today if I can 13:33:13 (hi asn) 13:33:16 who will go next? 13:33:27 I'll go 13:33:40 I wrote a bunch of pt related tor patches 13:34:01 to try to clean up the termination detection 13:34:09 then HSes caught on fire 13:34:20 so I wrote some patches for that 13:34:36 also reviewed the "upload a HS descriptor through the control port" patch 13:34:51 are any of the patches from the review circle done-ish? 13:34:53 and unrelated, fixed torsocks so stuff that I use works 13:35:06 nickm: yeah 2 of them 13:35:11 I belive dgoulet's and mine are ready for higher review 13:35:16 nickm: #6411 and #14847 13:35:38 ok 13:35:44 both of us were going to look at the ed key stuff, but both of us are looking at this HS thing I think 13:35:47 could you tag them with nickm-review ? 13:36:03 (posting https://gitweb.torproject.org/user/asn/tor.git/log/?h=bug15515_2 on #15515) 13:36:05 sure I'll tag mine 13:36:21 nickm: sure 13:36:40 the pt stuff I did should be ready for review as well, but it's trivial and non-urgent 13:36:52 cool 13:37:09 looks like I'm going to be reading a bunch of code today :) 13:37:13 and I still need to document the "we keep stdin open" thing in the pt spec 13:38:05 next? 13:38:10 * dgoulet can go 13:38:10 hello 13:38:17 i mainly worked on sponsorr 13:38:24 and crowdfunding 13:38:37 but the past 2 days i've been fighting with #15463 13:38:42 (and then HSes caught on fire) 13:38:51 i have tried to summarize the situation on the ticket so far. 13:38:52 yeah that one, team HS is on it! :D 13:38:59 (I suspect this ill be a trend) 13:39:11 i just submitted a patch for #15515 which might solve evrything but will probably solve nothing. 13:39:20 i'm hoping to discuss this issue today on the HS meeting? 13:39:29 +1 13:39:30 and that's that. thanks :) 13:39:42 * dgoulet ready to do 13:39:43 it raises the bar required I think, but stuff like lolbotnets would still cause us issues 13:40:52 so what was dgoulet up to? 13:40:53 SponsorR, mostly with HS descriptor timeline that brought "fixes/answers" for #13483 and #12500, the HS fire ^ , some review here and there, one "medium" on DonnchaC_ patch, that's about it 13:41:23 I think DonnchaC's patch is probably review ready 13:41:48 I could look over it again, but my reviewing portions of that isn't a good idea 13:41:53 anymore 13:42:07 Yawning: it's in need_review yeah so it needs "acK" 13:42:21 because part of my initial review was provided in a "here is a diff" form 13:42:32 so someone not-me should ack it I think 13:42:49 Yawning: on my list 13:42:54 <3 13:42:54 * armadev notices a tor meeting (so early!) 13:43:04 armadev: used to be an hour earlier :P 13:43:20 is that all the peeps here for this? 13:43:34 (and shoul dwe go back to talking about how we need to fix our hs stuff mroe?) 13:43:35 think so 13:43:58 Yawning: should we keep the HS stuff for the hs meeting else we won't have anything to talk about :P 13:44:41 oh forgot isabela that is silently observing us! :) 13:44:47 well, I think some of the hs stuff changes the priority on some of our 0.2.7.x stuff 13:44:56 true 13:45:40 it would be nice to finish 0.2.7 triage soon. Has anybody besides me nominated tickets for deferral/inclusion on the spreadsheet? 13:45:49 (does anybody else have an update?) 13:46:09 oh ah! forgot about the triage nomination, damn :( 13:46:10 I looked at it and thought it was ok a week or so ago? 13:46:59 ok. so the idea is that there are two lists: sponsored and non-sponsored. By default, everything *not* greyed out in the first list will happen, and nothing in the 2nd list will happen 13:47:20 if there's something on the first list that's greyed out, or something on the second list, and you think it should happen, mark it as a nomination. 13:47:21 can we relink the sheet? 13:47:36 https://docs.google.com/spreadsheets/d/1H_kAcQQ-NpGpKWG9RlF3w-NhruKKE9EZJcRaXBQGVy8/edit#gid=499528971 13:47:40 <3 13:48:05 If there's something that _is_ planned to happen, and you think we shouldn't give it so much priority, or we can trivially afford to defer it, mark it in red or yellow 13:48:14 (mark by adding your initials or handle) 13:48:17 makes sense? 13:48:41 nickm: your "nm" in green for non gray stuff is basically "Nick wants that in 0.2.7" ? 13:48:48 (asking because no legend for green :) 13:49:08 yeah 13:49:29 how do we nominate gray stuff? 13:49:32 add 13:49:43 add your initials in green to the who-nominates column 13:49:54 try to put more negative nominations than positive 13:50:45 "Count unique IPs in an anonymous way" we doing this? i thought that the paper we liked had certain flows. 13:51:08 I don't agree. 13:51:13 ok then. 13:51:20 i have not read the paper, i just skimmed over the thread 13:51:22 or at the very least, I don't believe the papers *I* liked had the same flaws.... 13:51:25 ok 13:51:48 Also IMO even if all the flaws are real, it's still an improvement on status quo ante 13:52:28 oh, quick straw poll while we're all here... anybody think we shouldn't remove --digests? 13:52:29 unclear if we will be able to do "Raise our guard rotation period, if appropriate" in 0.2.7 13:52:39 we should certainly work on it though, yes? 13:52:46 * armadev votes to ditch --digests 13:52:57 since it depends on whether we will fix the guard discovery attacks for hses. 13:53:02 i find this spreadsheet complicated, alas 13:53:08 (#9001) 13:53:10 i think it might be tor browser can't display it well 13:55:27 ah ok #9001 is also in the list. so i guess tha'ts fine. 13:56:04 oh, while we have developers here. what do ya'll think of my ticket8766 branch? https://trac.torproject.org/projects/tor/ticket/8766#comment:5 13:57:02 haha "Rumors that hidden services have trouble scaling to 100 concurrent connections" 13:57:09 :) 13:57:25 asn: actually that ticket meant 100 connections open at the same time. 13:57:28 FYI, my HS worked perfectly fine for that ^ 13:57:29 not 100 connection attempts at the same time. 13:57:36 yep 13:57:55 armadev: I think it is probably not a complete solution? 13:58:03 armadev: not sure whether it's secretly messing something up 13:58:08 nickm: tickets on the first group look reasonable for 0.2.7. in the sense that nothing SUPER BIG is in there, and they are all quite important. 13:58:09 also there are more timers in any places in the code 13:58:10 nickm: correct, but it did fix actual behavior for me. 13:58:18 nickm: unclear if we will be able to pull it off for august or september. 13:58:28 nickm: so right now it would improve the lives of tails users 13:58:35 armadev: see also #3199 13:58:41 armadev: you can nominate it if you want? 13:58:57 I just did on your behalf 13:59:10 thanks 13:59:13 #13737 bing gray makes me really sad 13:59:23 so nominate it 13:59:28 that's what we're trying to do here 13:59:33 Yawning: nominate! 13:59:34 identify grey things that shouldn't be 13:59:45 did 13:59:50 woo 13:59:53 hehe 14:00:04 remember to also find included things that shouldnt' be. 14:00:07 35%+ for HS is crypto in the profiling of the attack so I think the intro circuit in worker is a NOMINATE contender :) 14:00:29 (if we nominate more stuff and don't make time to do it, we might as well not nominate it) 14:00:38 ^ 14:00:43 also remembver that the ENTIRE second group is defer-by-default 14:00:48 asn: you added your name but no color, you want them out or in or ? 14:00:49 IIUC 14:00:55 it's in response to "oh hey, fmonty" 14:02:16 dgoulet: it was more like "asn can probably do this for 0.2.7". should I green it? 14:02:25 "can" and "wants to"? 14:02:28 if so please green it 14:02:29 yes 14:02:32 and find other stuff to yellow/red :) 14:03:13 red = no, yellow = meh? 14:03:16 A thought: What if I make an 0.2.7-reach milestone, where deferrable stuff that we don't actually want to defer on goes? 14:03:41 Yawning: red = "I say this is a waste of time and not worth doing." yellow = "harmless to defer" 14:03:44 imo 14:04:05 k 14:04:36 so "Implement Bridge Guards and other anti-enumeration defenses" which is greyd out and has nickm and yawning as nominator, means what? 14:05:05 I put my name there cuz I think it's important 14:05:16 but it's greyd out because it's not going to happen for 0.2.7? 14:05:39 isabela: ^? 14:05:40 it means it won't happen unless we decide to do it 14:05:46 ok 14:05:49 yes 14:06:05 THe way that stuff got assigned grey was, if it had high estimated effort to priority ratio, it got greyed with no further consideration. 14:06:12 but that's a rough thing 14:06:21 nickm: realistically, there's a huge amount of stuff here already. any reach milestone will get skipped wholesale. but still maybe useful if it lets us part with things more amicably. 14:06:23 so we're refining it 14:06:33 armadev: i think psychologically yeah 14:06:51 isabela: what do you think about an 0.2.7-reach milestone? 14:06:53 "i'm not breaking up with you, i'm just putting you in the -reach component" 14:07:43 hmm 14:08:02 ok,you mean we would have 0.2.7 and 0.2.7-reach? 14:08:09 yeah 14:08:16 I prefer not :) 14:08:19 ok. then no 14:08:38 that is other ways we can organize these tickets so we know we once looked at them and considered them for 0.2.7 14:09:06 I am also writing a proposal to reorg trac which will include to change how we are using milestones (but that is topic for another convo) 14:09:38 ok 14:09:42 After today I plan on reflecting this spreadsheet on trac 14:09:53 woo 14:10:22 and will make sure that things that were not in group1 gets tagged in a way we can recognize them 14:10:23 is andrea playing? 14:10:39 I've pinged her; her sleep schedule may be messing with her again 14:10:59 isabela: +1. Do you know how to use trac's bulk-modification interface? (And did we remember to give you access to it?) 14:11:04 I'm relunctant on putting my name in green on non gray stuff.... I've already have much on my plate lol 14:11:10 You shouldn't ahve to tag 100 tickets one by one. 14:11:11 i hope i made isabela a trac goddess 14:11:13 nickm: I am admi on trac :) 14:11:16 yep 14:11:16 lovely 14:11:17 *admin 14:12:10 <3 bulk modification 14:12:37 !!! coffee is ready brb 14:14:19 ok 14:14:47 i find it hard to commit to more non-obvious tasks. 14:14:57 ^ 14:15:04 especially with my exams coming up, it's hard to schedule for months ahead. 14:15:19 this isn't so much "I promise I will do this", but instead "I believe this is important enough that we should do it." 14:15:30 yes 14:15:39 but of course if you can't imagine doing it yourself, maybe that is a factor 14:16:00 oh ah! it's not a "takw ownership" but a vote that we must do it... ok I got it wrong then 14:16:06 (for green) 14:16:08 ok 14:16:11 lots of yellow 14:16:39 I wonder if we should look over all the yellow and see if we disagree about yellowing it 14:16:55 yes 14:17:09 that would be good - if ppl are done we could do that 14:17:26 ok 14:17:57 I can start naming the rows (top-down) and you guys comment on it? 14:18:08 go 14:18:10 row 26 -> nickm 14:18:37 worth doing IMO, but less important than other worker stuff. I bet others do want it 14:18:46 probably ok, curve25519 is a bigger problem 14:18:47 ok 14:19:01 fine with me, I want it but can slip down a bit in priority 14:19:11 +1 to what dgoulet said 14:19:14 yeah that is what I would suggest 14:19:17 +1 14:19:24 normal is ok? 14:19:44 hm? yes 14:19:47 yes 14:19:50 cool 14:20:03 row 39 -> dgoulet 14:20:10 so since #15254 is off 14:20:18 row 39 is a bit useless 14:20:30 ok 14:20:34 i can also do row 38 14:20:44 in the sense that it's a bug i intorduced so it's easier for me to fix it. 14:20:59 here let me add my nick 14:21:03 ok 14:21:17 iirc the fix was quite easy. 14:21:46 asn: you just want to assign it to you right? 14:21:59 i guess so 14:22:22 ok then I will remove the yellow name :) otherwise I will get confuse later 14:22:41 ok dgoulet that is reasonable reason to remove it 14:22:45 everyone cool with it? 14:22:56 yes 14:22:57 we are about to freeze this list as-is? 14:23:12 nickm: I removed your yellow from before as well, since we dicided on keeping it as lower priority 14:23:35 isabela: yes we can un-gray it 14:23:44 there 14:23:48 armadev: is hard to ever freeze 14:23:53 dgoulet: tx 14:24:03 asn: row 41 14:24:38 asn: Huh. If you think that's not worthwhile, maybe we should consider it deferrable 14:24:56 nickm: which one, i'm sorry? 14:25:03 isabela: that's also bug on my code. can handle this. 14:25:08 row 41 == #14957 14:25:10 ok 14:25:13 so stay 14:25:16 not very important. 14:25:19 maybe instead of rows, we use use #s 14:25:22 #s 14:25:27 would be better IMO if that's ok 14:25:27 so the bot pipes up 14:25:28 sorry 14:25:36 will do it 14:26:10 nickm: idon't think it's very important. gonna take 1-2 days with testing i estimate. i can take something else, but eventually it will need to get fixed probably. 14:26:29 i'm a big fan of #8782 14:26:43 asn: i think we can keep it there 14:26:52 sure 14:27:18 armadev: that one is slated for inclusion I believe. 14:27:18 who is chupacabra? 14:27:52 ok chupacabra please remove yellow 'asn' from that row :) 14:28:15 I am removing the question marks from the stuff that says Sebastian? 14:28:28 row 48 -> #15061 14:28:31 nick 14:30:24 I think that if the rest of the ed25519 stuff gets done and that slips, it will do no harm 14:30:49 hrm once #12498 is merged for which we plan for 0.2.7, the controller using identity keys should follow else for a full version the controller will be out of sync with current possible keys? 14:31:12 dgoulet: our initial ed25519 stuff doesn't deprecate RSA 14:31:32 it doesn't but controller should at least be able to tell that ed25519 keys exists (are) ? 14:32:13 we spit out the raw descriptor right? 14:32:22 isn't it the app code's problem at that point to do that? 14:32:30 I agree that telling the controller is good. 14:32:36 I only question whether it is _necessary_. 14:32:45 If we defer that to 0.2.8 or later, nothing bad happens 14:33:04 fair enough 14:33:18 ok 14:33:29 (though if we do the ed key stuff right, it should be easy/nearly free to do) 14:34:16 what does pink in row 183 mean? 14:34:30 armadev: used to be red but is not anymore 14:34:31 armadev: "was once rejected" 14:34:34 ok 14:34:44 ok 14:35:30 I think row 48 is out from this release then 14:35:45 isn't it "move it to the next list"? 14:35:56 we aren't redding it right? 14:36:34 #15235 seems like a useful doc thing. ln5 has a wiki page with some answers to it. 14:36:42 Yawning: not sure what you mean 14:36:52 Will the "vuln" since operation onymous be fixed so it will safe to host onion sites again? highlight me if you response ;) 14:36:53 when you say it's out 14:37:13 Atm Im using i2p but its way to slow 14:37:24 hm nvm 14:37:34 next? 14:37:39 qwk: you're in the wrong channel. 14:37:44 ok 14:38:00 49 -> #15062 14:38:02 nickm 14:38:03 armadev: can you recommend me the right channel ? 14:38:07 same thing 14:38:15 ok 14:38:24 qwk: #tor will be better for you. 14:38:29 qwk: also see /topic 14:38:30 thanks 14:38:41 so is ok to move it to the other list? 14:39:02 I think it's okay to call it a don't-have-to-do-yet 14:39:09 ok 14:39:18 row 51 #14881 14:39:47 I don't get that one. how bad is it? 14:39:49 rob's patch is a one liner 14:40:10 does it require a revision of the spec or a new consensus method number? 14:40:26 no 14:40:29 I don't think so 14:40:38 in that case, since there's a patch, we can leave it in 14:40:46 (it's in needs_review, yeah?) 14:41:02 yeah 14:41:09 ok 14:41:10 we can always defer it later if it ends up being scary 14:41:14 great 14:41:42 ok 14:41:51 row 55 -> #13802 14:42:05 sorry 56 14:42:06 no issue at all to defer 14:42:15 #13802 it would be a cool thing to do, but it woudl be just as cool in 6 months 14:42:16 it's moving too much anyway right now 14:42:24 argh (me got confused) 14:42:37 ok 14:43:10 is everyone ok with that? 14:43:16 mmhmm 14:43:19 row 56 is #15017 14:43:39 maybe a good idea, maybe not. hard to say 14:43:53 I think, it might be interesting to look at, but there's more important perf stuff 14:44:00 ^ 14:44:07 IMO deferrable, but not must-defer 14:44:12 ^ 14:44:15 I think it's a perf issue but can be defer 14:44:18 ^ also 14:44:26 but also messing with openssl stack stuff is usually harder than we expect 14:44:38 indeed 14:45:02 also afraid of 'oh go dopenssl does what?' leading to a rats nest 14:45:26 cool 14:45:36 * nickm chuckles at "dopenssl". It's openssl on dope :) 14:45:39 I think asn got confused for the next one, I think he wanted to put is name on ;) 14:45:46 yeah 14:45:57 beacuse #8243 is I think an important one 14:46:02 yes 14:46:04 thanks dgoulet 14:46:12 ah fixed! very nice :) 14:46:13 yeah basically 14:46:22 row 100 #2149 14:46:27 nickm and Yawning 14:46:42 defer, nice to have, but not critical, it's for magic annonymity boxes and stuff 14:46:55 the solution to that is to stop the tor process 14:47:00 could be nice to have. It would help the network some maybe, but I believ3e it promises to be hard. I don't trust the patch we have for it. 14:47:19 basically I think it should be "large" not "medium". 14:47:43 ok 14:47:46 will update 14:48:04 (also if it' sjust consensus downloads, we're merging the diff stuff which should help) 14:48:25 ok, i have done a pass through the list. woo. 14:48:25 ok 14:48:36 anyone disagress? 14:48:44 mostly i tried to leave stuff alone since if i get near stuff people will expect me to do things :) 14:48:56 heheh 14:49:02 pro tip :) 14:49:03 alright 14:49:04 guys i will have to take a break. the day is ending and I have the HS meeting in an hour. i only nominated #8864 because more HS ops are worrying about it, and I'd be interested in looking at it. 14:49:20 asn: go for it 14:49:23 +1 14:49:31 if you wanna do it, go for it imo 14:49:40 +1 14:49:47 sounds like a sponsorR thing too 14:50:00 ugh, wtb trac timeline fixed, but I'm too scared to poke at the db 14:51:05 qq do we want to go over green? 14:51:06 * armadev tags #8864 with SponsorR 14:51:17 we could 14:51:36 104-106 are all green, and all about faster curve25519/ntor, and all have (some kind of) patches 14:51:41 ahha all "faster crypto" bug are assigned to Yawning :D 14:51:59 well, it'd either be nick or me I think 14:52:15 no no it's fine, I can see where your interest is ;) 14:52:26 I'm not sure where our biggest bang for our buck will be re curve25519, I think cpuworker stuff might end up winning over these 14:52:35 cpu worker also I think 14:52:44 but I'll know p fast if I poke at this stuff 14:52:59 can we do a bulk ok for 104, 105, 106 and 108 14:53:00 ? 14:53:13 108 is very different from the others, 14:53:16 or do you want to go one by one? 14:53:17 ok 14:53:19 but I think we can bulk-ok 104,105,106 14:53:23 the other 3 are all the same 14:53:29 reasons yeah 14:53:36 so bulk ok for those 14:53:52 sure 14:54:00 and how do people few about #7144 14:54:04 row 108 14:54:21 we need that because it's an obvious attack 14:54:25 vs our good pts 14:54:30 and it breaks all of them 14:54:36 :( 14:54:50 cept meek I guess 14:54:59 it's hard though. Do we have a design for it? 14:55:09 p 188? 14:55:21 ah 14:55:26 I liked the design, but need to think about it more 14:55:58 yawning: doesn't break all of them. good bridges are multi-homed. 14:56:09 >.< 14:56:16 but yes, i like the design too. maybe a "decide about the design" step in between? 14:56:30 yeah I just don't think it's immediate defer 14:56:43 because despite the complexity, it needs to be done sooner rather than later 14:56:46