13:28:03 <nickm> #startmeeting 13:28:03 <MeetBot> Meeting started Wed Aug 20 13:28:03 2014 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:28:03 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 13:28:17 <nickm> It's another Tor dev meeting at 1330 UTC on a wednesday! 13:28:20 <nickm> Who's around? 13:28:23 <athena> greetings, meeting! 13:28:54 <asn> me is around 13:28:59 <asn> looking at the unittests bug for a second 13:29:02 <nickm> hi athena ! What have you been up to this week? 13:29:12 <asn> nickm: should I open a ticket? 13:29:14 <nickm> asn: Do you have a fairly solid idea about how to fix it? 13:29:19 <asn> kind of 13:29:31 <asn> it will need another timecheck NOP fix or something 13:29:34 <nickm> asn: I'd just take a patch if you get one done in the next hour or three. If it'll take longer, please open a ticket. 13:29:38 <asn> if (!version_is_bad && entry->chosen_on_date + guard_lifetime < now) { 13:29:38 <asn> /* It's been too long since the date listed in our state file. */ 13:29:38 <asn> msg = "was selected several months ago"; 13:29:38 <asn> date_is_bad = 1; 13:29:38 <asn> } 13:29:41 <asn> is the problem 13:29:50 <asn> in remove_obsolete_entry_guards() 13:29:54 <nickm> asn: Or generate the time to be "last month" from now, not always in may. 13:29:56 <asn> let the meeting proceed and I will look into it. 13:30:00 <asn> nickm: ah or that. 13:30:03 <nickm> Or mock the function that finds out what time it is. 13:31:27 <nickm> (anybody else around this morning?) 13:31:28 <asn> Should I go with a status report? 13:31:42 <asn> so during the past week, I've been doing a few things: 13:31:50 <asn> I opened #12887 but I haven't had time to debug it. 13:31:58 <asn> ehm that should be 13:32:19 <asn> #12877 13:32:34 <asn> and I did some more work on #9321 13:32:53 <asn> First of all, I pushed my python script to https://gitweb.torproject.org/user/asn/hax.git/tree/refs/heads/guardiness 13:33:11 <athena> been rebasing the global scheduler code from january for 0.2.6 13:33:13 <asn> then I asked Sebastian for feedback on the dirauth procedure for running the script. 13:33:39 <asn> nickm: I also appreciated your feedback on that ticket. 13:33:51 <asn> nickm: in https://trac.torproject.org/projects/tor/ticket/9321#comment:23 13:33:56 <nickm> athena: how's that coming? 13:34:01 <asn> nickm: you said "I guess you could have a "KeepOldConsensuses 90 days" option along with "OldConsensusDir /var/xyzzy" that would store the last 90 days of consensuses in some directory of your choice." 13:34:05 <nickm> athena: hs rob been looking at it? 13:34:16 <asn> nickm: would you prefer to do this using a cron job, that cp's cached-microdesc-consensus to a directory? 13:34:23 <asn> instead of doing it in little-t-tor directly? 13:34:36 <nickm> asn: We'll already be keeping old consensuses for the purpose of consensus diffs (see mvdan's code) 13:34:41 <Yawning> o/ 13:34:44 <asn> ah 13:34:48 <asn> nickm: on a file? 13:34:49 <nickm> having the number be adjustable would be a fine thing IMO. 13:34:51 <asn> or on memory? 13:34:52 <nickm> in a directory. 13:34:55 <asn> oh wow 13:34:56 <asn> ok. 13:35:00 <asn> i will look into this. 13:35:10 <nickm> hi Yawning 13:35:25 <asn> nickm: you also suggested that the output file that Tor should be parsing 13:35:28 <asn> should be: 13:35:32 <asn> <key> <value> 13:35:33 <asn> <key> <value> 13:35:34 <asn> <key> <value> 13:35:35 <asn> etc. 13:35:43 <Yawning> hello ^_^ 13:35:48 <asn> what did you imagine parsing that? smartlist_split_string with delimter set to space? 13:37:06 <asn> a summary file will have about 6k lines. do you think I should load all that in a smartlist? or do it line-by-line like dirserv_read_measured_bandwidths() is doing (but its code is not nice)? 13:37:08 <nickm> asn: config_get_lines(), maybe? 13:37:13 * asn looks 13:37:21 <nickm> 6k lines is not a big deal. 13:37:56 <asn> i will look into config_get_lines() 13:38:10 <asn> if I can't leverage that, I will just smartlist_split it, and see if I get any bad perfomrnace. 13:38:23 <nickm> Yawning: what's been up with you? 13:38:55 <Yawning> Still doing pt related stuffs, I'm starting my epic battle with gitian for Tor Browser integration 13:39:25 <Yawning> It's good news from a pt perspective but isn't all that related to little-t tor alas :( 13:39:26 <asn> nickm: so, the architecture here is, authorities parse consensuses and calculate guardiness, 13:39:39 <asn> then guardiness info gets put in the consensus for each router 13:39:52 <asn> and users use that info when they calculate middle-node weights. 13:40:01 <asn> i have two questions here: 13:40:13 <asn> a) What happens if two different authorities see different guardiness info about a relay? 13:40:24 <asn> because maybe they didn't have the same set of consensuses when they run the script. 13:40:37 <nickm> This should be something that gets voted on. 13:40:40 <asn> will that be resolved on its own during voting, or do we have to write code specifically for that? 13:40:52 <nickm> I think that having it get resolved during voting makes the most sense. 13:41:13 <asn> I agree. But does the voting prtoocol resolve such things automagically? 13:41:39 <asn> Or do we have to specify what happens if one auth sees a router in 650 consensuses, and the other in 643 consnesuses and the thrd in 620 consnesuses? 13:42:03 * asn is not familiar with voting protoocl 13:42:19 <athena> nickm: not yet; do you have rob's e-mail address for me so i can send him the repo once the rebase is done? 13:42:36 <asn> From: Rob Jansen <rob.g.jansen@nrl.navy.mil> 13:42:37 <asn> ? 13:42:41 <nickm> jansen@cs.umn.edu should work too 13:43:17 <nickm> asn: So, is this another entry on w lines, or what? 13:43:24 <asn> yes, that would be the second question 13:43:31 <asn> ineded, it's another entry on w lines. 13:43:35 <nickm> if so, we just add a new consensus version that calculates the output as the median of the inputs for that value, and we should be set. 13:43:45 <asn> OK. 13:43:47 <nickm> s/version/method/ 13:43:52 <asn> So this needs specification too. 13:44:03 <asn> thanks 13:44:05 <athena> okay, thanks 13:44:11 <asn> and now my final question 13:44:17 <asn> what do you think the format of this 'w' entry should be? 13:44:32 <asn> prop236 said: 13:44:33 <asn> The authorities include the age of each guard by appending 13:44:33 <asn> '[SP "GV=" INT]' in the guard's "w" line. 13:44:36 <asn> but that was very vague. 13:44:40 <asn> now we need to specify it further. 13:44:49 <nickm> what does gv stand for? 13:45:00 <asn> not sure, I think NickH chose it. 13:45:13 <asn> my current idea is something like: 13:45:16 <nickm> I'd suggest GW for guard weight, and have it be a percentage from 0 to 100 ? 13:45:24 <asn> ah, like that. 13:45:34 <asn> maybe Guard Appearance Fraction ? 13:45:51 <asn> if we want it to be a fraction, that is ready to be consumed by the clients. 13:45:52 <nickm> Percentage Time Guard ? 13:46:18 <asn> my origianl proposal would have been: GV = 302 343 6, where 302 is the number of consensus appearances, 343 is the number of consensuses parsed, and 6 is the number of months considered. 13:46:24 <asn> but this is TMI. 13:46:30 <asn> and I'm not sure if all those are useful information. 13:46:40 <nickm> I think having it be an integer percentage is better, in case we want to change the formula to calculate it at the authority side. 13:46:50 <nickm> Also, _integer_ percentage: messing with floats is messy. 13:46:56 <asn> good point 13:47:17 <asn> ok, so we do the formula on the authority side, and feed it directly to clients. 13:47:20 <asn> i think that's a good idea. 13:47:53 <asn> ok, great, nickm . 13:47:57 <asn> you answered all my questions. 13:48:00 <asn> i can now proceed :) 13:48:24 <asn> i have all that is needed from this meeting now. if you need anything from me, please shoot. 13:49:41 <nickm> asn: just a fix for the unit tests atm :) 13:49:54 <nickm> oh hey I can also do a status report 13:50:20 <nickm> I've been helping the students wrap up their gsoc stuff, fixing random tickets, reviewing random stuff, trying to catch up again with my email, and things like that. 13:50:47 <nickm> I think I'm done with trunnel. Nobody's replied to my tor-dev email, which I assume means that trunnel is perfect and suits our needs just fine. 13:51:00 <nickm> (I've been successful at not polishing it any further since last thursday.) 13:51:32 <nickm> I've got a bunch of new tickets in needs-review, and would appreciate a second review on 10116 before I merge it, since it touches the oom code. 13:52:42 <nickm> my priorities for this week are merging patches and revising patches, and finally getting that schedule thing written, and not losing any more work time to stress or shiftlessness. 13:53:13 <Yawning> gogo gitian :( 13:53:17 <Yawning> *cries* 13:53:26 <nickm> I've also spent a bit more time learning how to use coccinelle. It's... made for people smarter than me, I think. 13:53:59 <Sebastian> that's what I say about python :/ 13:54:13 <Yawning> that's what I say about boost 13:54:20 <Sebastian> hah, I don't talk about boost. 13:54:28 <nickm> last week after the meeting athena and I went through the 'new' tickets for 026 and triaged them. Maybe we should do the same thing for some of the other tickets today? 13:54:47 <nickm> and I think that's it for me. 13:54:52 <athena> nickm: what's coccinelle? 13:54:55 <nickm> anybody else have a topic to chat about? 13:54:57 <athena> ...and yes we should 13:55:02 <nickm> athena: http://coccinelle.lip6.fr/ 13:55:08 <nickm> it's a tool to do semantic patching on C 13:55:22 <athena> oh nifty 13:55:30 <Yawning> nickm: a really casual look at that oom change looked ok, but I only skimmed it so there's a good possibility I missed something 13:55:46 <nickm> athena: see scripts/coccinelle/calloc.cocci 13:55:50 <nickm> (in master) 13:56:02 <athena> we coul use that for the char * to uint8_t * thing, perhaps 13:56:19 <nickm> athena: I've been trying to think about how that could work. I think it would play a role there certainly. 13:56:30 <Sebastian> nickm: wrt the format, I have no real fancyness in mind 13:56:35 <Sebastian> I wanted to mirror the current setup 13:57:40 <Sebastian> authdirinvalid with an IP address, authdirinvalidcc with a two-letter country code, authdirinvalidfp with a fingerprint 13:57:56 <nickm> athena: can I ask you to take a quick skim over #10116 and #11792 after the meeting, and after that, we'll triage stuff ? 13:57:57 <Sebastian> for invalid, reject, badexit, etc in place of the invalid 13:59:10 <nickm> Sebastian: seems okay to me so long as they're distinguishable. 13:59:22 <nickm> assuming that IP also means IP/mask 13:59:35 <nickm> also, comma-separated lists might be a good idea. 13:59:48 <nickm> now I'm bikeshedding though 13:59:56 <nickm> country codes should be wrapped in {}, I think 13:59:56 <Sebastian> comma-separated list? 14:00:14 <nickm> invalid 1.2.3.4, 1.2.3.5 14:00:17 <Sebastian> oh 14:00:21 <nickm> invalid {zz}, {xx} 14:00:23 <Sebastian> I think that is not a good idea tbh 14:00:32 <Sebastian> because scripts want to add or remove stuff possibly 14:00:36 <Sebastian> or we want to apply diffs 14:01:03 <nickm> probably support !invalid (or whatever the old magic name was) for backward compatibility. 14:02:06 <Sebastian> I was going to go with a new file 14:02:15 <Sebastian> do you think that's not a good idea? 14:02:43 <Sebastian> because we want to merge from the torrc and the approved-routers file, but not the entire approved-routers file (most of it is just naming stuff) 14:03:02 <Sebastian> ok, back in a little while. Thanks for your input! 14:03:12 <athena> nickm: yeah, sure 14:04:50 <nickm> ok, great 14:04:56 <nickm> I think we're done with the meeting then 14:04:59 <nickm> #endmeeting