13:34:25 #startmeeting 13:34:25 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 13:34:27 Hi, athena! 13:34:32 I got distracted by editing the changelog 13:34:34 how are you today? 13:34:43 i am alive 13:34:56 that's a good thing 13:35:02 #10168 is a tarpit; turns out there are 899 occurences of time_t in src/or/*.{c,h} 13:35:13 oy 13:35:17 yeah 13:35:29 (and don't forget struct timeval, I guess) 13:35:36 Maybe we need a different approach? 13:35:49 Or do you think "look at all of them" is the right strategy? 13:36:05 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 so direct use of time_t/timeval clearly marks "this hasn't been assessed/converted yet" 13:36:58 okay, so we should have "monotime", "monotimeval", "clocktime", "clocktimeval" or something? 13:38:00 yeah 13:38:13 syntactically distinguish time as an interval measurement from time as a coordinate, IOW 13:39:15 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 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 yeah, something like that 13:41:03 sounds good to me. Where's it at atm? 13:43:37 (And is anyone else around this morning? 13:43:48 ) 13:44:07 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 (we seem to be the whole meeting) 13:45:36 ok. That sounds like a good start. When do you think the initial code will be ready for a review? 13:47:34 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 sounds good to me. 13:48:32 okay, will do that then 13:48:49 cool. I'll be ready for it 13:49:19 Me, i've been distracted from coding by putting out releases and trying to do coproration debugging. 13:50:05 But I think I can get 12498 ready for review this week, albeit with only partial prop220 support. 13:50:12 #12498 13:50:23 *must ... resist ... etymologizing ... 'coproration' ...typo* 13:50:33 cool, i'll have a look when it's ready 13:50:58 I'm going to leave out "extend by ed25519 id" for now, and make another ticket for that. 13:51:33 I also need to think about writing a "remove RSA1024" proposal. 13:52:12 and we should go through all our SHA1 again some time 13:52:17 and wasn't I supposed to make a schedule? 13:52:23 ug, too much stuff to do that isn't coding 13:54:07 I wonder what I should prioritize. 13:54:10 Any thoughts? 13:55:34 rsa1024 13:56:12 To clarify: Such a proposal won't improve security; implementing prop#220 gives all the security benefit 13:56:24 Removing RSA1024 only makes some descriptors smaller and code simpler. 13:57:47 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 http://www.wangafu.net/~nickm/volatile/tor-0.2.6.0-alpha-dev.tar.gz 13:58:07 by SHA1 are you thinkng of things that would be security-relevant? 13:58:10 http://www.wangafu.net/~nickm/volatile/tor-0.2.6.0-alpha-dev.txt.asc 13:58:18 athena: yeah, if there are some. 13:58:40 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 (yeah, agree abolishing RSA1024 won't make a difference since everything prefers NTor when possible) 13:58:47 ok 14:00:23 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 ... fixes for. :) 14:00:56 This is going to seriously need test-networks 14:01:42 yeah, that's a complicated migation 14:02:34 but it would eventually let us abolish some old code... 14:02:41 yeah. 14:03:57 Also, can I ask people to proofread the changelog affter I'm done editing it? 14:04:10 hm. end of meeting, start of chat? 14:04:12 #endmeeting