Thanks for your reply.
I take your point regarding the switch statement in the example verify
callback. I did not find this very interesting for my work. In fact, it
would be more interesting to actually set the error (if there wasn't one
already).
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.
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.
return(-2) occurs in crypto/x509/x509_v3.c and crypto/x509/x509name.c.
Your interpretation of 0 meaning EOF is helpful in trying to understand
the code. It seems often to mean that the context is not set up for the
operation, for example, no certificate, can't malloc, etc.
ssl3_part_read() returns 0 if the actual return code is not -1 and maybe
this means: if not EWOULDBLOCK then EOF, but here EOF would be a symptom
not a cause. It is difficult to see what EOF could mean on a socket,
unless it is an interpretation of a socket error.
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.
Ron.
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, May 07, 1999 11:22 AM
> To: [EMAIL PROTECTED]
> Subject: Re: X509_STORE_load_locations
>
> Ron Ramsay <[EMAIL PROTECTED]>:
>
> [...]
> > To summarise: Yes, you can write your own verify callback. Yes, I
> will
> > write my own. But, as a documentation measure, shouldn't the
> supplied
> > callback LOOK like a real verify callback?
>
> Well, the one used by s_client and s_server allows you to see what the
> library does not like about the peer's certificate chain, but still
> allows communication to occur. That's convenient for testing
> servers; but maybe there should be an option to enable strict
> verification.
>
> [...]
> > ABTW Has anyone analysed the significance of the return codes. The
> > values (in SSL) seem to be -2, -1, 0 or >0 but the significance of
> -2,
> > -1 and 0 escapes me. 0 seems to arise if an ERROR occurs, -1 for
> > EWOULDBLOCK and most other times and the strange -2 one. I think it
> > would be really nice if the codes were possibly: -1 (error) 0 (not
> > enough data) >0 (no error). This would simplify the API as
> > SSL_get_error() would only need to be called if there were an error.
>
> Where did you find -2? I have never seen that one.
> For the functions that I can remember, 0 means EOF, -1 means an error
> or EWOULDBLOCK. These codes quite closely follow the standard Unix
> behaviour.
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> Development Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
