Trace logging project
Nicolas.Williams at sun.com
Mon Sep 14 17:00:06 EDT 2009
Also, anything that is of diagnostic use should really be stored in the
context and made available to apps for display to users.
What, then, needs tracing? I think aspects of the protocol do,
particularly where ciphertext is involved (therefore packet captures are
not so useful, not without keys made available to the to the packet
Of course, the GSS-API has no interface by which to get non-error
information, and the gss_display_status() interface is lame for dynamic
error/diagnostic data. Plus existing apps. Thus the desire for a
tracing facility driven by environment variables. I think we need new
We have applications that could really use having detailed descriptions
of errors passed all the way up the stack from low-level crypto, up
through Kerberos, the GSS-API, SASL, LDAP, etcetera, to the application.
It's the application that interacts with users, and needs to give them
advice when things break. Building a diagnostic tool on top of a
KRB5_TRACE env var-driven trace tool would be challenging, if not
outright a bad idea (the same would apply to using the DTrace PID
provider, though not to the USDT provider).
So what is the real goal?
More information about the krbdev