Trace logging project

[Nicolas Williams]

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
dissector).

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
APIs.

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?

Nico
--