[01:08:17] --- squinney has become available
[01:10:12] <Simon Wilkinson> kaduk: What abstraction layers do you want to violate?
[01:43:23] --- Stephan Wiesand has become available
[03:03:22] --- squinney has left
[03:36:13] --- squinney has become available
[03:45:09] --- squinney has left
[03:45:13] --- squinney has become available
[03:56:23] --- mdionne has left
[05:18:46] --- mvitale has become available
[06:08:26] --- ballbery has become available
[06:25:51] --- Simon Wilkinson has left
[07:15:56] --- deason has become available
[07:21:41] <kaduk@mit.edu/barnowl> I want to skip the XDR encoder and just blat the length and contents
of the challenge nonce into the packet.
[07:47:20] --- meffie has become available
[07:50:17] --- meffie has left
[08:03:34] --- squinney has left
[08:24:07] --- Ken Dreyer has left
[08:25:48] --- Simon Wilkinson has become available
[08:27:02] <Simon Wilkinson> kaduk: You could definitely do that. But none of the profiling I've done suggests that constructing the challenge is a performance hotspot, so I'm not sure whether the obfuscation that brings would be worth it.
[08:27:30] <kaduk@mit.edu/barnowl> It's probably not worth the obfuscation, no.
[08:27:35] <Simon Wilkinson> You could also just assume that the the challenge is always a constant length, rather than using xdrlen to work out the length.
[08:27:52] <Simon Wilkinson> At least then, if someone changes the .xg, then xdrmem will complain at you.
[08:27:53] <kaduk@mit.edu/barnowl> It was more of an "I'm feeling lazy, and this is always going to be
the same encoding" sort of thing.
[08:28:20] <Simon Wilkinson> If there ever is an rxgen v2, I suspect that the way that will be indicated is with a larger challenge structure.
[08:28:36] <kaduk@mit.edu/barnowl> rxgen v2 or rxgk v2?
[08:28:48] <Simon Wilkinson> Sorry, rxgk v2. rxgen on the brain.
[08:28:54] <kaduk@mit.edu/barnowl> Understandable.
[08:29:22] <kaduk@mit.edu/barnowl> Still contemplating writing a manpage for it, though my experience is
largely with mdoc.
[08:30:11] <Simon Wilkinson> If you can work out all of the various rxgen options, you're a better man than me.
[08:30:34] <kaduk@mit.edu/barnowl> Well, the first crack would not have to be complete...
[08:30:47] <Simon Wilkinson> My rxgen experience has generally been wishing it could do something, going to implement it, discovering it was already there, hitting head off desk.
[08:31:13] <Simon Wilkinson> Or occassionally (as with -b), implementing it, and then assigning it to some arcane option because all of the obvious ones were token.
[08:31:16] <Simon Wilkinson> taken, even.
[08:31:27] <Simon Wilkinson> BTW, if you're not already using -b, do so. It will make you much happier.
[08:31:53] <kaduk@mit.edu/barnowl> Ouch.
[08:32:58] <kaduk@mit.edu/barnowl> -b does appear to be in my invocation that I cribbed from whereever.
[08:33:44] <Simon Wilkinson> It lets you, amongst other things, pass rx_opaques around (previously every occurence of an opaque had a unique type)
[08:53:51] --- Stephan Wiesand has left
[12:15:46] --- mvitale has left
[12:15:50] --- mvitale has become available
[12:24:59] --- kula has become available
[12:41:02] <kaduk@mit.edu/barnowl> Hmm, I wonder if I want to use pthread_once to set the rx epoch.
[12:44:08] <Simon Wilkinson> I suspect you don't want to be setting the epoch.
[12:44:55] <kaduk@mit.edu/barnowl> Well ... not right now, probably.
[12:45:10] <Simon Wilkinson> Not at all. 
[12:45:38] <kaduk@mit.edu/barnowl> rxkad is the only thing setting it at the moment, it looks like?
[12:45:38] <Simon Wilkinson> The security class shouldn't be involved in seeding the epoch, or cid
[12:46:22] <kaduk@mit.edu/barnowl> Sure, my plan was to factor it out into common rx code at some point.
[12:46:26] <Simon Wilkinson> RX sets it at the moment to something not very random. The first time you use an rxkad security class it gets reset to a "random" value
[12:47:19] <Simon Wilkinson> I suspect that this is all a hangover from when there was no real crypto available unless you used rxkad - and a version of AFS was shipped with no crypto to folk outside the US
[12:47:59] <kaduk@mit.edu/barnowl> Seems plausible.
[12:48:11] <Simon Wilkinson> Now that we link the whole of OpenAFS against hcrypto, and have a strong random number generator available there, RX should just set the cid and epoch to properly random values and be done.
[12:48:38] <kaduk@mit.edu/barnowl> At the moment, all my testing is in standalone client/server
utilities, so my environment is slightly different than a standard
openafs setup.
[12:49:08] <kaduk@mit.edu/barnowl> I'll buy that.  *adds to todo list*
[12:49:55] <Simon Wilkinson> It's actually vaguely useful in testing to not have randomized CIDs.
[13:43:44] --- kula has left
[13:44:11] --- kula has become available
[13:48:09] --- mdionne has become available
[13:49:40] --- ballbery has left
[13:54:10] --- meffie has become available
[15:14:29] --- mvitale has left
[15:28:26] --- deason has left
[15:48:05] --- mdionne has left
[19:23:00] --- mdionne has become available
[19:24:27] --- mdionne has left