Peter Djalaliev wrote: > To enable the SSL debugging statements, you need to set the SSLTRACE > environment variable. Possible values are 0-60 (0=no dubugging, > 60=lots)
The maximum value is 127, IIRC. However, it may be that presently we are not using values larger than 60. I specifically did NOT recommend this to Pedro for many reasons, including: - He should take the simplest approach to diagnosing the problem first, and not take the more difficult approaches unless/until the simple ones fail to explain the problem, - Turning this on is like drinking from a fire hose. You get TONS of output. Quickly leads to information overload. - 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). - There is no debug tracing inside the PKCS#11 crypto module. The only way to get the actual values of the Pre-master secret and Master secret is to use libSSL's "bypass" feature, which alters its behavior. I suspect this is all orders of magnitude more complicated than Pedro needs just to see what's going on. > IMHO, this is ~~confusing~~. We are using one debugging mechanism to > print out statements within NSS and another one within the rest of > NSPR/Mozilla. That's true. NSS's tracing was written years before NSPR came along. > What's more, the two mechanism don't even provide the > same functionality - the NSS debugging macros allow you to display > buffer contents, while the NSPR ones don't. The NSPR mechanisms allow > you to output to a file instead of standard output, while the NSS ones > don't. 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. These features are available ONLY in DEBUG builds of NSS. > > Can we simplify this whole thing? Can we get rid of SSLTRACE, > PRINT_BUF and SSL_TRACE altogether No. There is no need to do that. Those macros are not a problem. Eliminating them is not part of the solution. > and use PR_LOG and the related NSPR macros within NSS, too? Those macros invoke functions found in ssltrace.c. In the end, all the actual debug/trace I/O is done in one function, ssl_Trace, in that file. It might be possible to modify ssl_Trace to use PR_Log instead of fputs. I don't presently know enough about PR_Log to know how feasible that is. > For this purpose, we would need to enhance the NSPR debugging macros with > something equivalent to NSS's PRINT_BUF. Nah. No need to replace any of NSS's trace/debug formatting functions. Just get them to use NSPR. > If we do this, I think we will achieve uniformity with > what's used in other Mozilla modules and we will also allow NSS users > to pipe their debugging statements into a file (which I think it quite > useful when stdout is not available - e.g. embedded apps) Again, the ability to output to a file is in NSS today. > Given this, we can also write a nice documentation module on > "debugging NSS" in the NSS documentation wiki that Wan-Teh maintains. 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. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
