Obviously any real refactor of kdc code is something way out of scope/expertise for me to do (I only changed the silly pass-giant-struct-by-value thing and fixed the dupe struct), but I did docs for the new profile vars and whatnot. The change is pretty trivial in terms of lines of code, it's 95% profile reading.
What I'll do is put up a page with the various patches I've made to the KDC, and send out a link, and you guys can take a look. I think there are 5 in total (pass-by-value fix, u2u allow_svr fix, this check-allow_tix-on tgs_req fix/feature, make vague_errors a profile bool instead of compile time const (which turned out to be pretty useless for various reasons I'll write up on the page), and fix the dupe krb5_realm_params issue). I'm not sure of the best way to write an automated test for this. Is there an example of a complex test like this in the source tree? You'd have to simultaneously be talking to the kadm5 interface to change the flags and be talking to the kdc. I could do it in perl with my patched Authen::Krb5(::Admin) modules, but it'd be a fairly big test in C. Chris On 2011/08/07 22:51, Greg Hudson wrote: > On Wed, 2011-07-27 at 06:35 -0400, Chris Hecker wrote: >> Okay, I implemented this today. > > We may add a feature like this at some point, in order to provide fast > revocation for high-value services. In order to get any solid security > guarantees, the service would need to set a short maximum lifetime, and > would need to force reauthentications upon ticket expiration. > > I can't provide any timeline, though. Relative to your patch, we would > likely need to address: > > * Precisely how the client lookup should be done (what flags, > basically). Canonicalization of the client principal should not > generally be needed since it will have been done during the AS request. > > * Consideration of edge cases, such as when the client principal entry > has been deleted or renamed or deleted and recreated since the AS > request. > > * Consideration of whether to extend the DAL interface's TGS > verification function to take the client DB entry as input when > available. > > * A long-overdue refactoring of the TGS code path before additional > complexity is added to it. > > * Documentation. > > * Automated test cases. > > ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos