Ron Ramsay <[EMAIL PROTECTED]>:
[...]
> The global variable verify_error does nothing in the example code. It
> could be used for communicating with the main-line but this is not
> shown. Surely it would be better to jettison this variable and to put
> your own error on ctx->error. In particular, the error
> X509_V_ERR_CERT_CHAIN_TOO_LONG could be put on ctx->error and retrieved
> from the main-line using SSL_get_error.
verify_error seems to be there for historical reasons: Older versions
of s_client.c started with explicit SSL_connect and looked at
verify_error afterwords, and apparently it's there because using a
callback in this way was the only way to return the error code to the
application -- SSLeay 0.6.6b and SSLeay 0.8.1b do not have
SSL_get_verify_result, while SSLeay 0.9.0b does; SSLeay 0.6.6b's
verify_callback in s_cb.c contains the assignment verify_error=error,
where error is the argument passed from the X.509 library.
Unfortunately, quite a lot of the stuff in the apps/ directory does
not make for very good examples.
But anyway I think that it shouldn't be necessary to use a verify
callback function. I've recently added functions to the SSL API that
allow defining a verification depth, because this is something that
the library should be able to do, and there _is_ support for it in the
X.509 library (but the X.509 library does not yet produce the right
error code when the length is exceeded).
> My real problem was that the code was misleading and I had to look at
> the code which called it to try and work out what it should be doing.
> This is not the usual function of example code.
Probably much of that should be rewritten from scratch; the apps
directory unfortunately resembles a mis-managed museum.
> return(-2) occurs in crypto/x509/x509_v3.c and crypto/x509/x509name.c.
I see. But I haven't found (with a very quick search) any place in
the library where these functions that can return -2 are actually
called. For many other functions, just 0 and 1 are possible return
values, so that you can write
if (!some_function(args)) {
handle error;
}
do something;
[...]
> It is difficult to see what EOF could mean on a socket,
> unless it is an interpretation of a socket error.
EOF on sockets means that the peer shut down the connection (which is
observed when a read/recv returnes 0).
> If the error reporting is logical, or if there is a reason why it can't
> be, then I am happy. I just didn't want the case of unnecessarily obtuse
> error reporting.
verify_callback in s_cb.c certainly is one of the uglier things in the
apps directory ...
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
