Arne Ansper <[EMAIL PROTECTED]>:
>> Like I say, they should only do this if there was an error reported, surely?
> No. Take a look at the SSL_CTX_use_certificate_chain_file:
>
> ret=SSL_CTX_use_certificate(ctx,x);
> if (ERR_peek_error() != 0)
> ret = 0; /* Key/certificate mismat
In message <[EMAIL PROTECTED]> on Fri, 31 Jan 2003 15:50:06
+0100 (MET), "Bodo Moeller via RT" <[EMAIL PROTECTED]> said:
rt> A second theory is that OpenSSL should always clear the error queue by
rt> calling ERR_clear_error() if stuff left in the error queue might cause
rt> confusion later.
The
On Tue, Nov 26, 2002 at 10:44:15PM +0200, Arne Ansper wrote:
> I just checked. Seems that SSL_CTX_use_certificate_chain_file has a same
> problem. Other uses of ERR_peek_error seem to be immune to the old entries
> in error stack.
One theory is that applications should not call arbitrary OpenSSL
On Thu, Jan 30, 2003 at 10:09:22PM +0100, Richard Levitte via RT wrote:
>
> Any more thoughts on this issue?
The problem is not yet solved. Using the global error stack as error indicator
instead of correctly passing state back via return values is a design flaw.
It happend to make problems in t
> Adding ERR_clear_errors() into SSL_read() etc seems to be the correct
> approach. It is already handled this way in _accept(), _connect(), but
> not that obvious, because it is found e.g. in ssl3_accept() which is
> called depending on the method selected.
>
> You will often find ERR_clear_err
