> - It can be quite difficult for someone who is not familiar with the > code to interpret. The feature exists to help the code's developers > debug the code, not as a general SSL line monitoring tool (which > ssltap is). >
ok...I see. I apologize to Pedro then, I am more of a developer than a user. But then, he should know his options :) I use SSL_TRACE with carefully set trace level to monitor SSL handshakes. > Not true in the current NSS code. > There are 3 environment variables related to NSS tracing: > > SSLTRACE Set to trace level (0-127) > SSLDEBUG Set to debug level (0-127) > SSLDEBUGFILE set to file path name. NSS uses stderr if this is not set. Ah, sorry then. I'm using NSS 3.10 and SSLDEBUGFILE seems to have been added later :) > Nah. No need to replace any of NSS's trace/debug formatting functions. I think uniformity is good since it leads to cleaner code :) Would it hurt? If yes, then uniformity is not good in this case :) I don't know, getting ssl_Trace to use PR_LOG seems like a hack to me. Maybe a hack is good for this purpose. Or maybe it is just not important enough to spend time on it :) > I think a better name would be "Tracing SSL Protocol Processing". > > Feel free to document the extant NSS features. If we change libSSL's > DEBUG/Trace features to use NSPR, that should be a small change to the > documentation. Sure, I'll do it sometime. Regards, Peter _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
