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