13:34:25 <nickm> #startmeeting
13:34:25 <MeetBot> Meeting started Wed Oct 29 13:34:25 2014 UTC.  The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:34:25 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:34:27 <nickm> Hi, athena!
13:34:32 <nickm> I got distracted by editing the changelog
13:34:34 <nickm> how are you today?
13:34:43 <athena> i am alive
13:34:56 <nickm> that's a good thing
13:35:02 <athena> #10168 is a tarpit; turns out there are 899 occurences of time_t in src/or/*.{c,h}
13:35:13 <nickm> oy
13:35:17 <athena> yeah
13:35:29 <nickm> (and don't forget struct timeval, I guess)
13:35:36 <nickm> Maybe we need a different approach?
13:35:49 <nickm> Or do you think "look at all of them" is the right strategy?
13:36:05 <athena> i think the best strategy for this is to introduce a monotonic clock mechanism *and* use the same struct trick to mark the non-monotonic/real-time calls to time functions
13:36:25 <athena> so direct use of time_t/timeval clearly marks "this hasn't been assessed/converted yet"
13:36:58 <nickm> okay, so we should have "monotime", "monotimeval", "clocktime", "clocktimeval" or something?
13:38:00 <athena> yeah
13:38:13 <athena> syntactically distinguish time as an interval measurement from time as a coordinate, IOW
13:39:15 <nickm> and we need a way to let the conversion happen piecemeal so that we can convert some stuff to monotime/walltime and then take a break?
13:39:48 <athena> then we can make a more gradual project of converting everything, without having to fight the whole tarpit at once or keep a branch in progress around a long time that's going to constantly need rebases and accumulate a huge diff
13:39:52 <athena> yeah, something like that
13:41:03 <nickm> sounds good to me. Where's it at atm?
13:43:37 <nickm> (And is anyone else around this morning?
13:43:48 <nickm> )
13:44:07 <athena> about there; i've made a preliminary assessment of the usage of time_t and concluded they are numerous, most can be fairly easily assessed to determine whether to be clock or monotonic time, but there might be some hard cases lurking in there and i don't see any good way to automate it.  i have an implementation of the needed montonic time functions.
13:45:08 <athena> (we seem to be the whole meeting)
13:45:36 <nickm> ok.  That sounds like a good start.  When do you think the initial code will be ready for a review?
13:47:34 <athena> not too long if we follow the strategy i'm proposing so that initial code just includes adding needed monotime functions/structures and a few example conversions rather than converting the world all at once
13:48:16 <nickm> sounds good to me.
13:48:32 <athena> okay, will do that then
13:48:49 <nickm> cool. I'll be ready for it
13:49:19 <nickm> Me, i've been distracted from coding by putting out releases and trying to do coproration debugging.
13:50:05 <nickm> But I think I can get 12498 ready for review this week, albeit with only partial prop220 support.
13:50:12 <nickm> #12498
13:50:23 <athena> *must ... resist ... etymologizing ... 'coproration' ...typo*
13:50:33 <athena> cool, i'll have a look when it's ready
13:50:58 <nickm> I'm going to leave out "extend by ed25519 id" for now, and make another ticket for that.
13:51:33 <nickm> I also need to think about writing a "remove RSA1024" proposal.
13:52:12 <nickm> and we should go through all our SHA1 again some time
13:52:17 <nickm> and wasn't I supposed to make a schedule?
13:52:23 <nickm> ug, too much stuff to do that isn't coding
13:54:07 <nickm> I wonder what I should prioritize.
13:54:10 <nickm> Any thoughts?
13:55:34 <qwerty1> rsa1024
13:56:12 <nickm> To clarify: Such a proposal won't improve security; implementing prop#220 gives all the security benefit
13:56:24 <nickm> Removing RSA1024 only makes some descriptors smaller and code simpler.
13:57:47 <nickm> BTW, earlier I posted links to a draft 0.2.6.1-alpha.  It would be cool if people could test it a little
13:58:06 <nickm> http://www.wangafu.net/~nickm/volatile/tor-0.2.6.0-alpha-dev.tar.gz
13:58:07 <athena> by SHA1 are you thinkng of things that would be security-relevant?
13:58:10 <nickm> http://www.wangafu.net/~nickm/volatile/tor-0.2.6.0-alpha-dev.txt.asc
13:58:18 <nickm> athena: yeah, if there are some.
13:58:40 <nickm> and also I should poke djb about whether his wide-block construction will be done any time soon.  If not, we need a fallback plan.
13:58:43 <athena> (yeah, agree abolishing RSA1024 won't make a difference since everything prefers NTor when possible)
13:58:47 <athena> ok
14:00:23 <nickm> dropping RSA1024 from the directory system won't be easy.  First, we need to make it so there are alternative formats for *everything* which don't include RSA keys.  Then we need to make everything accept those, but authorities refuse them until all clients and relays can upgrade.  Then we can make relays upload and clients download.  And then we can find out if there are any bugs that we need to wait for everybody to apply ...
14:00:29 <nickm> ... fixes for. :)
14:00:56 <nickm> This is going to seriously need test-networks
14:01:42 <athena> yeah, that's a complicated migation
14:02:34 <athena> but it would eventually let us abolish some old code...
14:02:41 <nickm> yeah.
14:03:57 <nickm> Also, can I ask people to proofread the changelog affter I'm done editing it?
14:04:10 <nickm> hm.  end of meeting, start of chat?
14:04:12 <nickm> #endmeeting