Thank for the feedback, much appreciated :) On Apr 7, 7:27 pm, "Wan-Teh Chang" <[EMAIL PROTECTED]> wrote: > Hi Rainer, > > NSPR threads are just POSIX threads with NSPR thread IDs. > NSPR assigns NSPR thread IDs on demand to POSIX threads > not created by NSPR. So your POSIX threads can coexist > with NSPR with no problem.
very good! > To use the TLS library in NSS, you only need to know about > some basic NSPR types (PRInt32, PRInt64, PRTime, etc.) > and NSPR's socket I/O functions (PRFileDesc, PR_OpenTCPSocket, > PR_Recv, PR_Send, PR_Close, etc.). NSPR's socket I/O > functions were designed to be similar to the BSD socket > functions, so it should be easy to learn, and the only new > concept is the use of I/O layering to wrap the TLS functionality > inside the same PRFileDesc type and PR_xxx socket I/O > functions. You'd need to learn the same amount of functions > with other SSL libraries. For example, this seems like the > mapping between the two libraries (please pardon the > indentation): > > PRFileDesc gnutls_session_t > > PR_ImportTCPSocket gnutls_transport_set_ptr > + SSL_ImportFD > > PR_Send gnutls_record_send > > PR_Recv gnutls_record_recv > > PR_Shutdown gnutls_bye > + PR_Close > > So it's the PR_ prefix that raises an eyebrow. This is also very good information. As I said, I plan to have my own abstraction layer, so it should be not too hard to include "drivers" for both nss and gnutls in it. > I agree that GnuTLS has better documentation and samples. > The authors of GnuTLS have done an excellent job. > Do you know where our documentation and samples are? I found these places: http://www.mozilla.org/projects/security/pki/nss/ref/ssl/gtstd.html http://lxr.mozilla.org/mozilla/source/security/nss/cmd/SSLsample/ The samples are fine per se... The problem is that they do not point to a "stand-alone" app environment. >From what you have said, I think I more and more tend to start with GNUtls, use their good sample to create my wrapper and than later try to find the matching functions inside nss. That's probably the fastest way to getting started. Of course, some good samples with NSS inside a non-NSPR app would probably change that picture ;) > Are you using NSS because its MPL/GPL/LGPL tri-license > is compatible with the GPL? The motivation is primarily to get the benefits of Red Hat's crypto consolidation on those platforms. This sounds like a really useful approach and given the fact that the syslogd is available on each system, it should not work against this philosophy. That's also the reason for the abstraction layer. I think on Debian we would probably go with GNUtls. From my point of view, it's irrelevant what a distro choses, but the rsyslogd engine should be able with whatever decent is available... Oh, and by the way, the FIPS certification is also a big, big "sales point" for nss, but I am sure you know ;) Thanks again, Rainer > > Wan-Teh _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
