Yahel Zamir wrote:
selfserv uses SECU_Strerror, but this is a private function. in
addition, on my machine it does not find an error string for -8174, for
example.
Could you find out why? -8174 is SEC_ERROR_BAD_DATABASE, a common
error code. SEC_ERROR_BAD_DATABASE is listed in the table:
http://lxr.mozilla.org/security/source/security/nss/cmd/lib/SECerrs.h#94
so SECU_Strerror should be able to find it. Does selfserv print
"security library: bad database" on the next line after "-8174"?
6.
bug report - in function setupSSLSocket() of SSLsample/client.c, any
failure leads to closing tcpSocket, even after SSL_ImportFD(), which
replaces tcpSocket by sslSocket.
It's not a bug. You will find that the value returned by SSL_ImportFD
is the same as the value of "fd" (the second argument) passed to it.
OK. Although it would be safer to make sure that they are equal, I guess.
I see what the confusion was. Nelson's right. The code is correct.
It is necessary to use a new variable for the return value of
SSL_ImportFD -- if we say
133 /* Import the socket into the SSL layer. */
134 tcpSocket = SSL_ImportFD(NULL, tcpSocket);
we will lose the original value of tcpSocket when SSL_ImportFD fails.
I agree a comment or an assertion would help clarify this subtle
point for people who are unfamiliar with NSPR's I/O layers.
133 /* Import the socket into the SSL layer. */
134 sslSocket = SSL_ImportFD(NULL, tcpSocket);
PORT_Assert(!sslSocket || sslSocket == tcpSocket);
Wan-Teh
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
